Closed PaulDance closed 2 months ago
@microsoft-github-policy-service agree company="HarfangLab"
Thanks, I'd like to reduce rather than expand VARIANT
support in windows-core
, likely by moving this to a dedicated crate like windows-variant
. I also think that array support should be pushed to a SAFEARRAY
wrapper rather than being baked into VARIANT
. This is closely tied to VARIANT
so I imagine I'd probably combine these in the same crate. At any rate, if you can give me some time to figure out that restructuring it should be easier to get more VARIANT
type support up and running.
Alright, ping me when you do :slightly_smiling_face:
?
We'll keep the discussion alive on the issue. 😊
Actually, I just thought about this again: why block this PR's review, iteration and potential merge while waiting for a refactor you want to achieve?
The added APIs would still remain after the refactor, whether they are added before or after, right? Also, in any case, moving the types to a separate crate could potentially constitute an API break, but that is independent of the things proposed here, right?
This and that can be done in parallel, no?
Dear maintainers,
This is an attempt to close #2983. It is effectively an upstream of remainder of the equivalent higher-level wrapper we have around
VARIANT
.It contains:
VT_NULL
variant.is_null
was also added as a bonus for symmetry withis_empty
.From<String>
mapping toVT_BSTR
sinceBSTR
also implements it.From<&[&str]>
mapping toVT_ARRAY | VT_BSTR
sinceBSTR
implementsFrom<&str>
.From<&[String]>
mapping toVT_ARRAY | VT_BSTR
sinceBSTR
also implementsFrom<&String>
.From<&[u8]>
mapping toVT_ARRAY | VT_UI1
.The array variants require allocation that is hopefully handled correctly. The
Drop
implementations were updated accordingly.Also,
is_empty
wasconst
, so I thought it would be interesting as a sort of bonus to mark the other methods as such: see first commit. I can remove it though, if it is judged not acceptable.Cheers, Paul.