Enums, bitfields and wl_arrays

[Nils Chr. Brause]

I see. You're right. :)

On 5 Oct 2015 22:31, "Victor Berger" <victor.berger at m4x.org> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151005/1647b336/attachment-0001.html>