Enums, bitfields and wl_arrays

[Victor Berger]

Le 2015-10-02 14:12, Auke Booij a écrit :
> However, I'm not sure who you are trying to protect here. Everyone
> agrees that the new attributes should not change anything for C/C++,
> and in the current patches, they don't. And the other bindings writers
> understand the compatibility issues regarding this change, and, if I
> may speak for the majority of them, care much less about compatibility
> issues than about being able to provide proper APIs for their users.
> 
> In haskell, and many other modern languages, an easily fixable compile
> issue (we keep calling it a compatibility issue, which I think is a
> misnomer, although I don't know what category it should fall under) is
> *vastly* preferred over a potential bug. Arguably, that's the entire
> point of the language. Modern languages attempt to cross-check as many
> properties as possible, and the enum attribute would contribute
> greatly to this, even if that means breaking API every so often.
> 
> The wayland protocol currently does not specify the enum attribute,
> and I see no way how to write an API whose entire purpose is to
> *break* when you erroneously mix up enum attribute data, without
> breaking API as this data is added. More importantly, this problem
> does not matter because it is not a problem but a *solution*.

I mostly agree with that, from my Rust point of view.

While a huge part of my bindings can be generated by the scanner, these 
is still a need of some hand-written glue, to cleanly connect Rust into 
the wayland-client lib via the protocol. And given the current package 
model of Rust, I expect each protocol file to be interfaced as a rust 
package including a given version of the xml file and using the scanner 
to generate it at compile time. With all these packages (the scanner 
being one of them) properly versioned, nobody would be take by surprise 
by and update of the protocol file.

So, my main argument for Rust is that the mental overhead of binding 
generation would not be handled by the downstream consumer, but by the 
bindings maintainers. If some protocol requires an old version of the 
scanner, so be it, it just needs to set its dependencies accordingly and 
everything will be fine.

These were my two cents about Rust, I cannot talk for other languages.

Victor