One of the first issues, #5, struggled with how to use these types and through that we built the following consensus:
ComItf<T>
A non-owning COM interface reference. Does not increment or decrease reference count automatically.
ComRc<T>
An owned COM interface. Responsible for incrementing and decreasing reference count on its own.
Note that a ComItf<T> is a reference type. Yet it behaves like an owned type. This goes against Rust's lifetime safety.
Proposal: ComItf<T> -> ComItf<'a, T>
Give ComItf an explicit lifetime. While this lifetime isn't really tied to any safe concept, it could manually tie the lifetime of a ComItf to the validity of the underlying InterfacePtr. This would prevent anyone from reciving a ComItf as a parameter and storing it (it's even a Copy type currently. ;_;) into something that outlives the original AddRef.
If the user needs to store a ComItf, they can then convert it into a ComRc, which does an add ref on it.
We'll also need to document the various From/Into implementations between these types in a sane way. Currently those things have been added "to get things working" - but that's not sustainable strategy.
One of the first issues, #5, struggled with how to use these types and through that we built the following consensus:
ComItf<T>A non-owning COM interface reference. Does not increment or decrease reference count automatically.
ComRc<T>An owned COM interface. Responsible for incrementing and decreasing reference count on its own.
Note that a
ComItf<T>is a reference type. Yet it behaves like an owned type. This goes against Rust's lifetime safety.Proposal:
ComItf<T>->ComItf<'a, T>Give ComItf an explicit lifetime. While this lifetime isn't really tied to any safe concept, it could manually tie the lifetime of a
ComItfto the validity of the underlyingInterfacePtr. This would prevent anyone from reciving aComItfas a parameter and storing it (it's even aCopytype currently. ;_;) into something that outlives the original AddRef.If the user needs to store a
ComItf, they can then convert it into aComRc, which does an add ref on it.We'll also need to document the various
From/Intoimplementations between these types in a sane way. Currently those things have been added "to get things working" - but that's not sustainable strategy.