Since 2.037, this function will always pass:
checkClass(Object o)
{
assert(typeid(o) is o.classinfo);
}
Isn't it about time .classinfo was deprecated? It's still in the docs, and still compiles. It isn't mentioned in TDPL.
Is there a reason to keep it?
Comment #1 by schveiguy — 2012-05-07T04:38:39Z
See also issue 3346
Comment #2 by alex — 2012-05-07T04:40:25Z
I think the intention has always been to deprecate it. It's about time we actually do so.
Comment #3 by Marco.Leise — 2012-05-10T12:03:05Z
typeid(x) doesn't work in all cases where x.classinfo works (on 2.057/2.059). Something along the line of:
TypeInfo_Class[string] lookup;
class Foo
{
mixin Register!("foo");
}
template Register(string Trigger)
{
static this()
{
lookup[Trigger] = this.classinfo; // ok
// lookup[Trigger] = typeid(this); <- 'this' is only defined in non-static member functions, not _staticCtor13
}
}
Comment #4 by schveiguy — 2012-05-10T14:02:39Z
(In reply to comment #3)
> // lookup[Trigger] = typeid(this); <- 'this' is only defined in
> non-static member functions, not _staticCtor13
typeid(typeof(this))
Comment #5 by schveiguy — 2012-05-10T14:05:00Z
Also see above referenced bug 3346 that specifically identifies classinfo as behaving abnormally. Looks like you found another case!
Comment #6 by Marco.Leise — 2012-05-10T14:09:07Z
Ah, thank you for that hint. So my code would survive the deprecation, if just by chance.
@Geod24 created dlang/dmd pull request #11033 "Fix issue 8059 - Deprecate `.classinfo` in favor of `typeid`" fixing this issue:
- Fix issue 8059 - Deprecate `.classinfo` in favor of `typeid`
As explained in the changelog entry, `.classinfo` is redundant with `typeid`.
However, the later better expresses the idea of a "runtime `typeof`",
and free up an identifier in the pool of reserved properties.
https://github.com/dlang/dmd/pull/11033
Comment #9 by robert.schadek — 2024-12-13T17:59:54Z