I see. You're right. :) On 5 Oct 2015 22:31, "Victor Berger" <<a href="mailto:victor.berger@m4x.org">victor.berger@m4x.org</a>> wrote: > > 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. >