Support would require multiple raw VARIANT structs, which differ on the string types - and possibly the array types in the future.
Currently all interface pointers within VARIANTs are of Automation type system, but this is somewhat easy to change.
One proposal is to have
VARIANT_raw and VARIANT_automation structs. VARIANT_automation is the same as Microsoft's VARIANT struct. VARIANT_raw would replace BSTRs with char*s, etc. Rust would need to define both of these raw structs. The friendly intercom::Variant would then implement conversion into and from both of these.
The low level parameter support would come just by having the tyhandler::VariantParam defining the underlying com_ty as the respective raw struct. We'll use into/from and com_into/com_from for conversions anyway so that should magically just work once the com_ty handles the type system.
The big downside here is that we'd need to come up with two different names for these in intercom-cpp. The global VARIANT is already reserved in Windows programming so that kind of needs to stay. On the other hand Intercom-cpp might want to use intercom::VARIANT as the raw version, which is more likely to be used with intercom C++ code anyway.
Or should we have intercom::VARIANT_raw and intercom::VARIANT_automation as the two concrete types and then some flags to define which typedef intercom::VARIANT into one of those?
Currently not supported. Should we support these?
Support would require multiple raw VARIANT structs, which differ on the string types - and possibly the array types in the future.
Currently all interface pointers within VARIANTs are of Automation type system, but this is somewhat easy to change.
One proposal is to have
VARIANT_raw
andVARIANT_automation
structs.VARIANT_automation
is the same as Microsoft's VARIANT struct. VARIANT_raw would replace BSTRs with char*s, etc. Rust would need to define both of these raw structs. The friendlyintercom::Variant
would then implement conversion into and from both of these.The low level parameter support would come just by having the
tyhandler::VariantParam
defining the underlying com_ty as the respective raw struct. We'll useinto
/from
andcom_into
/com_from
for conversions anyway so that should magically just work once thecom_ty
handles the type system.The big downside here is that we'd need to come up with two different names for these in intercom-cpp. The global
VARIANT
is already reserved in Windows programming so that kind of needs to stay. On the other hand Intercom-cpp might want to useintercom::VARIANT
as the raw version, which is more likely to be used with intercom C++ code anyway.Or should we have
intercom::VARIANT_raw
andintercom::VARIANT_automation
as the two concrete types and then some flags to define which typedefintercom::VARIANT
into one of those?