typeid() broken for interfaces?

[Jonathan M Davis]

On Wednesday, December 05, 2012 15:11:55 foobar wrote:
> On Tuesday, 4 December 2012 at 18:41:14 UTC, Jonathan M Davis
> 
> wrote:
> > On Tuesday, December 04, 2012 17:35:23 foobar wrote:
> >> That's a lot of duplication considering D already provides this
> >> in Object.
> > 
> > Though per the last major discussion on const-correctness and
> > Object, it's
> > likely that toString, toHash, opCmp, and opEquals will be
> > removed from Object,
> > in which case you'd need a derived class which implemented them
> > to use any of
> > them.
> > 
> > - Jonathan m Davis
> 
> In other words, the plan is to pretty much deprecate Object? I
> hope there would be appropriate replacement before this happens.
> Users should be able to have a standardized API and a default
> implementation for these methods.
> Is phobos going to introduce interface such as Printable,
> Comparable, etc.. ? (names tentative, I'm more worried about the
> semantics).

No. The plan is not to deprecate Object. The reality is that those functions 
don't need to be on Object in D, because all of the runtime stuff that relies 
on them can (and really should) be templatized, whereas in Java or C#, they 
have to put them on Object and operate through Object. What we have currently 
have with Object in D is a case of having copied too much from Java and C# 
(and templates weren't as good in D1, possibly making those functions 
necessary there). And having those functions on Object has created a lot of 
problems with regards to stuff like const. If they're there, they have to be 
const so that you can compare const objects, but given how D's const works, 
that then make certain idioms impossible in classes (e.g. lazy loading member 
variables and caching). const needs to work, but we can't force it on people, 
and putting it on Object forces it on people. Rather, it's perfectly possible 
for only derived classes to have those functions. They can then use the 
function attributes that match what they need, and stuff like druntime's 
opEquals or AAs will just be appropriately tempatized and work with the 
derived classes without needing to have any of that on Object. There's really 
no need to have any of that on Object.

I'd have to go digging through the archives to find the last discussion on 
const-correctness where this was discussed in some detail, but that's the gist 
of it. Putting those functions on Object causes a lot of problems with regards 
to function attributes, and templates make actually putting those functions on 
Object unnecessary.

- Jonathan M Davis