BOOL and BOOLEAN are defined as a struct whereas VARIANT_BOOL is defined as an enum

[kennykerr]

This leads to strange inconsistencies. Can VARIANT_BOOL also be a [NativeTypedef] struct?

Originally posted by @kennykerr in microsoft/windows-rs#2206 (comment)

[mikebattista]

@elachlan what are your thoughts on this? VARIANT_BOOL is either VARIANT_TRUE or VARIANT_FALSE which is why this is an enum. The alternative is we make VARIANT_BOOL a [NativeTypedef] struct like bool typed as short, and VARIANT_TRUE and VARIANT_FALSE would be disconnected constants. How would this impact usability in WinForms?

[kennykerr]

The BOOL and BOOLEAN types also have true/false constants, although they appear to be missing from the metadata for some reason.

https://learn.microsoft.com/en-us/windows/win32/winprog/windows-data-types

[mikebattista]

TRUE and FALSE were added at one point but then removed based on feedback that projections were using their own true and false.

[kennykerr]

Ah right. In hindsight they're probably worth including. I've seen numerous requests for them as they are just so common in existing code/samples/docs that is ported to Rust.

[mikebattista]

Sure we can add them back. As long as @elachlan confirms WinForms is ok with the breaking change for VARIANT_BOOL.

[elachlan]

Currently where WinForms uses it is in VARIANT.cs. I don't believe it has been re-written yet. Since it would have been moved namespace wise. I think it would be fine to change it.

CC: @AArnott & @JeremyKuhne

[elachlan]

This will break the current code though. So its not zero effort.

[mikebattista]

Do you agree with @kennykerr's proposal? If it's a better definition then we would make the change.

[JeremyKuhne]

@mikebattista Consistency is good. There are slight performance benefits to having an enum as far as .NET is concerned, which is why they're defined as such in the .NET runtime, but it is minimal. I personally prefer structs as we can provide cast operators that make going to/from bool easy and, more importantly, correct.

[AArnott]

VARIANT_BOOL is a typedef in native code, so at least it would be consistent to make it a struct in metadata too.
As for defining any true/false constants, I'd still lean gently towards omitting them. But I think we can go either way.

[elachlan]

Consistency is nice. We can also add extensions to it, which we do for BOOL. So in general its a good change.

[mikebattista]

Ok. Will change to struct then. I will add TRUE/FALSE back as well given that the most recent feedback is they are wanted.

[riverar]

Think it's important we provide VARIANT_TRUE/VARIANT_FALSE constants, esp. given true is not represented with integer 1.

[mikebattista]

Yes I will add those as well similar to 05fbdc9 with a NativeTypeName for the struct.

[mikebattista]

@riverar if you get a chance could you validate usage of VARIANT_TRUE/FALSE in Rust? I defined them the same way as TRUE/FALSE but the definition in the metadata doesn't reference VARIANT_BOOL like TRUE/FALSE do with BOOL. They just show up as short.

[kennykerr]

Whatever type the metadata uses for these constants is what Rust will use. So, if the types of the constants are not BOOL and VARIANT_BOOL respectively then that won't work.

[mikebattista]

Everything looks correct except the VARIANT_TRUE/VARIANT_FALSE constants. Not sure why they're not getting typed as VARIANT_BOOL.

[riverar]

@mikebattista Here ya go #1397

[mikebattista]

Thanks!