Enums, bitfields and wl_arrays in the .xml file

[Bill Spitzak]

On Thu, Sep 24, 2015 at 4:00 AM, Victor Berger <
victor.berger at polytechnique.org> wrote:

> Hi,
>
> After some discussions on IRC, it appears this raises several concerns
> about back-compatibility.
>
> The main points being:
>
> - if a protocol file previously did not use these extra attributes, and
> choses to add them, depending on the language using them it can be a
> breaking change (as it would change the prototype of the requests from
> u(int) to the enum type for example)
>

Um, that is entirely the point of this change! The current xml does not
provide enough information so that a language binding can know that some
arrangements are illegal. Therefore current language bindings don't produce
errors for invalid code. With this extra information, the compiler now
knows that the arrangement is invalid, and can produce an error. If a new
error is a "breaking change" then this patch MUST be a breaking change, or
it is not working.


> - if a variant is added to an already existing enum, it can be a breaking
> change for some languages (Rust is one of them, as the compiler enforces
> you to cover all possible variants when matching on an enum).
>

What do you mean by "variant"? My guess is this does not mean "a new enum
value that did not exist before", but instead the ability to send arbitrary
numbers. But that seems to be duplicated by your next statement:


> - some enums, like xdg_shell::xdg_surface::states are by definition not
> complete.
>

Therefore the language binding must provide a method to send an arbitrary
number. However this can require extra syntax so that it is clear that the
programmer intended it. In C++ this is done by casting that number to the
enumeration value, ie you can't put 42 in the argument list, but you can
put EnumerationType(42). Your description of how you would handle this in
Rust sounds the same.

- and most likely other similar issues with "array" types or so
>
These questions need to be resolved, and a proper specification of what
> should contain the .xml files will certainly need to be written to properly
> handle all this.
>

The proposed additions provide EXACTLY what is needed by many language
bindings. Yes maybe there willl be new things added later. That is not a
reason to stop the current proposal.

It does sound a bit like it would be useful for Rust to know whether it
needs to support arbitrary values ("variant"s?), because an enum that does
not support them might be a lot simpler (in fact this is probably the main
reason for the bitfield indicator, in C++ and Python and probably many
languages a type that supports bit operations is much more complex and ugly
than an enum). So maybe a new field should be added to enum/bitfields to
indicate that arbitrary values must be supported. However that is a NEW
field, it does not change the current proposal at all, and there is no
reason to hold off useful and important changes until this new field is
decided on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150924/30342517/attachment.html>