<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 24, 2015 at 4:00 AM, Victor Berger <span dir="ltr"><<a href="mailto:victor.berger@polytechnique.org" target="_blank">victor.berger@polytechnique.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
After some discussions on IRC, it appears this raises several concerns about back-compatibility.<br>
<br>
The main points being:<br>
<br>
- 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)<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- 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).<br></blockquote><div><br></div><div>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:<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- some enums, like xdg_shell::xdg_surface::states are by definition not complete.<br></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- and most likely other similar issues with "array" types or so<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.<br><br></div></div></div></div>