On 26 June 2015 at 16:02, Auke Booij <a...@tulcod.com> wrote:
> Although arguments can only refer to enums in specific cases (see the
> scanner.c changes), this new protocol data should not break the C bindings.
> It is thinkable that other bindings *do* use the data in a way that breaks
> the protocol; however such usage will be considered nonstandard.
In retrospect, I phrased this a bit poorly. Obviously this new code
should not break any existing bindings: it merely introduces two new
datums that no one is using so far. Instead, the three points I am
making here are:
- The scanner.c code checks whether arguments that have an enum
attribute are of type (u)int, and if they refer to an enum with
bitfield=true, then it checks they are of type uint (not int!).
- In the discussion a few months ago, it emerged that whenever a
protocol starts supplying such data, when it did not specify it
before, this should not change the bindings API ("being more specific
shouldn't break anything"). Indeed this is not the case for the C
scanner, since it still doesn't use the data - these patches only
block builds when the new attributes aren't consistent in the sense
made by the previous point.
- Other bindings, in theory, can use the data given by these new
attributes, for example to strengthen the type safety of the generated
API. However, this might introduce API breakages when the protocol is
updated in a non-breaking way. While this is definitely not endorsed
by this set of changes, these changes do provide a way to convey more
type safety in strongly typed languages. My own (ab)use-case here is
the Haskell bindings I wrote.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
