IEnumWbemClassObject::Next hard to use

[kennykerr]

The first parameter is a timeout that you can use for an arbitrary timeout, or you can pass either WBEM_NO_WAIT or WBEM_INFINITE. Unfortunately, those constants are grouped into an enum, making it hard to pass directly to this function which expects an integer. These constants should just be loose integer constants rather than an enum.

[mikebattista]

This enum is coming from the headers as is, and it looks like the enum is typed as int already, as is the timeout parameter of the API. What's making it hard to pass? Do you need to cast the enum value to int?

[kennykerr]

The constants WBEM_NO_WAIT and WBEM_INFINITE are typed WBEM_TIMEOUT_TYPE so any language that doesn't provide implicit conversions to the underlying type (int) will require an additional cast to call Next to be called with these constants.

I should be able to say Next(123, ...) or Next(WBEM_INFINITE, ...) but as it is I have to "unpack" the value behind the constant and say Next(WBEM_INFINITE.0, ...) in Rust or in C++ you'd have to say Next(static_cast<int>(WBEM_NO_WAIT), ...).

But if those two constants were typed int, which is what the API expects, then it would "just work" without requiring a cast.

The confusion may come from the fact that they're declared as old-fashioned C-style enums which are nothing more than global constants, rather than C++-style enums which are scoped.

[mikebattista]

Ok. We can exclude the enum from the header and declare the constants manually.

[mikebattista]

Windows.Win32.System.Wmi.WBEM_TIMEOUT_TYPE removed
Windows.Win32.System.Wmi.WBEM_TIMEOUT_TYPE.WBEM_INFINITE removed
Windows.Win32.System.Wmi.WBEM_TIMEOUT_TYPE.WBEM_NO_WAIT removed
Windows.Win32.System.Wmi.Apis.WBEM_INFINITE added
Windows.Win32.System.Wmi.Apis.WBEM_NO_WAIT added