Is it time to deprecate COM compatibility through D interfaces?

[Kagamin]

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?
> 
COM interface is not a D interface.

> 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.
1. Interfaces don't derive from object.
2. You always know which interface is a D interface and which isn't, so you always know, whether you can cast it to object or not.

> - They are not implicitly castable to Object.
This has nothing to do with COM interfaces, I believe.

> - 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.

This is irrelevant to COM interfaces either. Can you use Variant for this purpose?

> - All these drawbacks are absolutely pointless on non-Microsoft OSes.
> 
They are pointless on ms oses too. And have nothing to do with COM. And dmd supports XPCOM.

> We are in the process of getting rid of builtin complex types in favor of  
> library types -- can we do something similar?
> 
If you have a solution, we can.

> I admit I am not familiar with COM, except my few experiences with it I  
> hated :)  Does anyone actually use D interfaces to represent COM objects?   
> What would the drawbacks be of interfacing COM objects via compile-time  
> generated structs that do the busy work?
> 
Syntax, I suppose.