Confused about interfaces in D

[Christopher Wright]

Ary Borenszweig wrote:
> Bill Baxter escribió:
>> On Thu, Oct 2, 2008 at 5:59 AM, Thomas Leonard <talex5+d at gmail.com> 
>> wrote:
>>> Hi,
>>>
>>> I'm used to interfaces in Java, and I'm wondering why this doesn't work
>>> in D:
>>>
>>>  interface Clock {}
>>>
>>>  class SystemClock : Clock {}
>>>
>>>  void main(string[] args) {
>>>        Clock c = new SystemClock();
>>>        c.toString();
>>>  }
>>>
>>> It says:
>>>
>>>  $ dmd clock.d
>>>  clock.d(7): Error: no property 'toString' for type 'clock.Clock'
>>>
>>> This compiles, though:
>>>
>>>        Clock c = new SystemClock();
>>>        (cast(Object) c).toString();
>>>
>>> When is a "Clock" not an "Object"?
>>
>> When it's derived from IUnknown, a special case put in to support COM
>> interfaces on Win32.
>> I've not heard anyone voice support for this particular design decision.
>> I suppose it's very convenient if you happen to be a COM programmer,
>> but I'm not sure why a vendor-specific technology like COM should get
>> such special treatment in a language spec.
>>
>> --bb
> 
> Better support a mostly unused specific case, than the broader general 
> case, right?
> 
> :-(

I've seen a number of issues relating to this -- for instance, tango's 
Variant had issues with inserting something as an interface and 
retrieving it as the class:

interface IFoo {}
class Foo : IFoo {}

Variant v = cast(IFoo)new Foo;
variant.get!(Foo); // throws VariantTypeMismatchException

This was resolved, fortunately, but people will encounter problems 
relating to this indefinitely.