Enums, bitfields and wl_arrays

[Victor Berger]

Le 2015-10-05 21:53, Nils Chr. Brause a écrit :
> Bill Spitzak wrote:
>> Similarly it seems like an "open" indicator that can be added to enums
>> (including bitfields) would help, as it sounds like some languages 
>> make it
>> difficult or cryptic to allow casting of arbitrary numbers to the enum 
>> value.
>> The "open" flag > would be an indication that the language binding 
>> needs to
>> support this. The lack of it does *not* mean that a language binding 
>> must
>> prevent casting of arbitrary numbers to the enum.
> 
> Since a language binding should support unknown values anyway, I don't 
> quite
> see the benefit of an 'open' flag.

It depends. In some case, it could be valid to support unknown values by 
simply ignoring them.

Consider a program written against a certain version of the protocol. 
Then, it is used on a compositor with a newer version of the protocol, 
where one of the enums have one more possible value.

What can the client do if it receives this value ? It has no possible 
way to give it a proper meaning, so it can either ignore it, or trigger 
a fatal error. Are there other options ?

In this case, for a "closed" enum, the binding can decide to ignore any 
value received on the wire that is not described in the XML, as anyway, 
the client would not know what to do with it (and if they knew, they 
should be using a more recent version of the binding).

This can be useful in some languages to allow such a thing. For example 
in Rust, handling an "open" enum would require some overhead in terms of 
usability of the API, to gracefully handle unknown values. While simply 
ignoring them would lead to a much simpler design. Unless it is not a 
good idea to ignore unkown values, in which case I'd gladly read an 
explanation of why it is and which problems I missed.

Without this flag, I have to choices: either consider enums as 
uints/ints and a set of constants to compare against (like C), of put 
this overhead on every single enum. To be honest, none of these 
possibilities feel satisfying. But They are still possible outcomes, 
hence the bindings _can_ live without this indication.

There is a similar concern with the enum/bitfield duality: in Rust, enum 
type are just a set of possible values, and are not meant for bitwise 
operations. On the other hand there is way to define bitfiealds types, 
with all the fancy methods you like to have to manipulate bitfields. So 
having the information of which enum is a bitfield would allow me to 
make the generated API much more comfortable to use.

I hope this was a clear explanation of why I think these values can be 
useful. Without then, I cannot really make use of the new attribute 
linking an argument to its enum, apart from writing it in the 
documentation and using (u)ints everywhere.