<div dir="ltr"><div><div>I am very much in favor of this, and posted earlier a further patch that uses this information to produce better protocol documentation.<br><br></div>The above design is exactly correct (in particular the bitfield indicator is on the enumeration, not the argument).<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 8:04 AM, Auke Booij <span dir="ltr"><<a href="mailto:auke@tulcod.com" target="_blank">auke@tulcod.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 26 June 2015 at 16:02, Auke Booij <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>> wrote:<br>
> Although arguments can only refer to enums in specific cases (see the<br>
> scanner.c changes), this new protocol data should not break the C bindings.<br>
> It is thinkable that other bindings *do* use the data in a way that breaks<br>
> the protocol; however such usage will be considered nonstandard.<br>
<br>
</span>In retrospect, I phrased this a bit poorly. Obviously this new code<br>
should not break any existing bindings: it merely introduces two new<br>
datums that no one is using so far. Instead, the three points I am<br>
making here are:<br>
<br>
- The scanner.c code checks whether arguments that have an enum<br>
attribute are of type (u)int, and if they refer to an enum with<br>
bitfield=true, then it checks they are of type uint (not int!).<br>
- In the discussion a few months ago, it emerged that whenever a<br>
protocol starts supplying such data, when it did not specify it<br>
before, this should not change the bindings API ("being more specific<br>
shouldn't break anything"). Indeed this is not the case for the C<br>
scanner, since it still doesn't use the data - these patches only<br>
block builds when the new attributes aren't consistent in the sense<br>
made by the previous point.<br>
- Other bindings, in theory, can use the data given by these new<br>
attributes, for example to strengthen the type safety of the generated<br>
API. However, this might introduce API breakages when the protocol is<br>
updated in a non-breaking way. While this is definitely not endorsed<br>
by this set of changes, these changes do provide a way to convey more<br>
type safety in strongly typed languages. My own (ab)use-case here is<br>
the Haskell bindings I wrote.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div>