In putil/config_putil.N there is a directive NOT to publish BitMaskNative into the interrogated API. Which makes sense. However, this seems at odds with BitArray::get_word returning exactly that type (through the MaskType alias) and being published.
I understand why it get_word would want to do that, as that is the type in the underlying array. Though this is asymmetric to set_word. My inclination is to change get_word to return WordType, as not exporting get/set_word seems a bit heavy handed.
MaskType is not exported either. But still get_word exists in Python. The Python binding generator doesn’t seem to care that the typedef itself isn’t exported, as long as the underlying type is.
I added that comment in config_util.N (as it was called at the time), and the reason was related to the ability to produce universal builds on macOS, binaries containing both 32-bit and 64-bit code. The easiest way to do this was to run interrogate only once, producing a source file that could be compiled both for 32-bit and 64-bit systems at once. With BitMaskNative pointing to different types on 32-bit and 64-bit, this would cause issues due to a mismatch between the architecture interrogate assumed and one of the architectures we built for. As it happens, we no longer support 32-bit macOS systems, so this is a bit moot now.
It does seem asymmetric that get_word and set_word take different types. My inclination would be to make set_word accept a MaskType, since some applications might rely on the return type, that’s what the underlying array actually stores, and WordType will automatically coerce to a MaskType where needed anyway.
The typedef is, of course, just an alias to the actual type. Given that BitMaskNative is, itself, an alias that might be where things are not behaving entirely. In any event, I’d say that the python still emitting something that returns a type that is explicitly stated to be ignored sounds sus.
In any event, I’ve re-jiggered things slightly and will address concerns when I get the PR out.
The Python binding generator doesn’t seem to care that the typedef itself isn’t exported, as long as the underlying type is.