Enums, bitfields and wl_arrays

[Auke Booij]

On 2 October 2015 at 13:12, Auke Booij <auke at tulcod.com> wrote:
> 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.

Actually, for my particular scenario, I just thought of a very elegant
solution that would introduce no new compatibility issues. With this
solution, *more* code would compile *with* the right enum attributes
than *without*. So we would have the best of both worlds: the type
safety that modern languages want, without new compatibility issues to
keep track of. (If anyone is interested in the technicalities behind
this, contact me. But it is a solution that is rather specific to
Haskell. Essentially, it would work by, rather than passing enum
values as ints until we have a proper data type for them, we would
pass each field as a different data type, until we know that two enum
fields should have been the same type. In haskell, this can be done in
a backwards-compatible way.)

Maybe a solution can be found in more languages, and we can make the
compatibility, that e.g. Pekka is looking for, a requirement for
bindings, rather than make compatibility a requirement for the
protocol writers. So something along these lines would be in the
specification:

[start]
The enum and bitfield attributes are in principle for documentation
purposes only. The enum and bitfield attributes may also be used by
bindings, but only in such a way that code written prior to the
specification of these attributes still works after their
specification. In other words, specifying an attribute for an
argument, that previously did not have it, should not break API.
[end]

Obviously C is not rich enough to do this in an elegant way. (Maybe
it's possible in C++ with some template magic?) But it definitely
solves the "backwards compatibility" debate, since, while anyone is
free to ignore this bit in the specification, solutions might
sometimes be possible, and it guards the entire C world from issues in
the non-C bindings.