#[com_class(Self)]
struct S;
#[com_interface]
#[com_impl]
impl S {
...
}
However this is currently insanely unsafe if we ever accept ComItf<S> (or ComRc) as a parameter. The interface will be defined in IDL/C++ like any other interface and the user code could implement such interface in IDL/C++. If the user code passes such self-implemented interface pointer in through a ComItf<S> parameter, we have no way to invoke or even recognize that. Our current implementation for ComItf<S> calls will assume that the underlying object truly is a S and does some very unsafe casts to acquire that.
There's two options:
Hidden trait
When a struct wants to expose itself through a COM interface, Intercom will generate a hidden trait that implements the struct interface. Once we have such a trait, we can then implement that trait on ComItf instead of having to go through a nasty deref implementation.
IIsClass interface
Alternatively we could implement another built in interface: IIsClass, which can be used to verify that the ComItf truly represents the assumed type S. This would give us a better guarantee that the underlying type really is an S and would allow us to throw E_FAIL or similar in case that isn't true.
The hidden trait is probably best as then the user code is free to implement the trait as well if they want.
Currently we support the following:
However this is currently insanely unsafe if we ever accept
ComItf<S>(orComRc) as a parameter. The interface will be defined in IDL/C++ like any other interface and the user code could implement such interface in IDL/C++. If the user code passes such self-implemented interface pointer in through aComItf<S>parameter, we have no way to invoke or even recognize that. Our current implementation forComItf<S>calls will assume that the underlying object truly is aSand does some very unsafe casts to acquire that.There's two options:
Hidden trait
When a struct wants to expose itself through a COM interface, Intercom will generate a hidden trait that implements the struct interface. Once we have such a trait, we can then implement that trait on
ComItfinstead of having to go through a nastyderefimplementation.IIsClass interface
Alternatively we could implement another built in interface:
IIsClass, which can be used to verify that theComItftruly represents the assumed typeS. This would give us a better guarantee that the underlying type really is anSand would allow us to throwE_FAILor similar in case that isn't true.The hidden trait is probably best as then the user code is free to implement the trait as well if they want.