Feature request: Some types are still aliases when they were newtypes in 0.28

[poliorcetics]

Motivation

See #1393

Drawbacks

No response

Rationale and alternatives

No response

Additional context

I'm seeing

• MESSAGEBOX_STYLE
• WIN32_ERROR
• GET_FILE_VERSION_INFO_FLAGS

There may be others.

[poliorcetics]

Also:

• USER_PRIV
• USER_ACCOUNT_FLAGS
• VS_FIXEDFILEINFO_FILE_FLAGS
• VS_FIXEDFILEINFO_FILE_OS
• VS_FIXEDFILEINFO_FILE_TYPE
• VS_FIXEDFILEINFO_FILE_SUBTYPE
• LOAD_LIBRARY_FLAGS
• IMAGE_FILE_MACHINE

[kennykerr]

#1393/#1423 was concerned with handle types. These are all C-style enums. I'm less convinced these benefit greatly from being unique types at the expense of all the extra code gen required.

[poliorcetics]

• VS_FIXEDFILEINFO_FILE_TYPE
• VS_FIXEDFILEINFO_FILE_SUBTYPE

These are both i32s behind the scene and very easy to get wrong because of autocompletion or just using the wrong type.

Since we have windows-sys for "very raw" bindings, I think windows should be much more type-heavy. It would become a choice of compilation speed vs type safety, and I'm ready to lose seconds for the safety when I choose to use windows.

Other people may not have this opinion, have there been opposite opinions to this elsewhere ?

[kennykerr]

I'm getting this change ready.

[poliorcetics]

Thank you very much, both for working on this and for your swift responses !

[kennykerr]

0.32.0 has now been published and includes this change.