Is it time to deprecate COM compatibility through D interfaces?

[Steven Schveighoffer]

On Wed, 14 Apr 2010 08:22:59 -0400, Jason House  
<jason.james.house at gmail.com> wrote:

> Steven Schveighoffer Wrote:
>
>> Given that structs have become extremely powerful, and with the advent  
>> of
>> opDispatch, would it be possible to deprecate supporting COM via D
>> interfaces in favor of a library solution?
>
> Don suggested defining them the same way as C++ classes.

Yes, if that is possible, I agree with that solution.  Essentially, COM  
interfaces simply become C++ interfaces, there is no special treatment for  
them, and non-C++ interfaces can be assumed to derive from Object.

>> There are some crappy drawbacks for having interface be dual-purposed:
>>
>> - Although 99.9% of interfaces are actually instances of Object, you  
>> can't
>> call Object functions directly on an interface.  This includes opEquals,
>> opCmp, toString and friends.
>> - They are not implicitly castable to Object.
>> - There is no centralized base interface, so there is no argument type  
>> you
>> can use that can accept any interface.  For instance, if you wanted to  
>> do
>> some runtime reflection to determine an interface's methods or  
>> something.
>> - All these drawbacks are absolutely pointless on non-Microsoft OSes.
>
> Casting interfaces is frequently an expensive runtime operation. It's  
> the price that we pay for allowing more than single inheritance with  
> interfaces. I don't like the idea of implicitly doing expensive  
> operations.

Casting interfaces to Object would not be expensive if the compiler knows  
every interface is an Object.  All that is required is to subtract the  
offset, found in the TypeInfo of the interface.  The expensive part of  
casting is searching for the typeinfo to ensure the cast is legal.

-Steve