Enums, bitfields and wl_arrays

[Auke Booij]

On 2 October 2015 at 12:31, Pekka Paalanen <ppaalanen at gmail.com> wrote:
>> I know that several people have proposed patches on this - Bill, Nils
>> and Auke at least.  Since there's a definite need for this, and since
>> agreement appears to be not far off, I would like to get this landed
>> this release.  And ideally I'd like to get this landed early in the
>> release so we give plenty of time for testing.
>
> The things that have been lacking in my opinion are specifications,
> especially answering the questions listed here by Victor after our irc
> discussion:
> http://lists.freedesktop.org/archives/wayland-devel/2015-September/024382.html
>
> The "do not break existing code" rule applies also proactively, not
> just at the time we decide to start using the new attributes, so it is
> important to define what things are under the "stable protocol"
> definition and cannot change after publishing. IOW, what are we carving
> in stone.
>
> There is a paradox: if the new attributes affect codegen for some
> languages in a way that will break the build (which is exactly the
> reason why they are wanted: to enforce type-safety), we cannot add
> these attributes to the existing protocols, most importantly
> wayland.xml, because it would "break existing code". You might escape
> that paradox once, by claiming that there is no "existing code", after
> all the generators for these languages will be new. But this escape
> hatch will only work once. When these generators get into use, we can
> no longer add the attributes to stable protocols without breaking
> things. Not even if the generators had a "legacy mode" that ignores the
> new attributes, because they would then regress on arguments that
> already had the new attributes set.
>
> The important thing to realize is that once an XML file starts using
> these new attributes, the attributes can no longer be added later into
> more arguments. We need to get it right on the first go, but hey,
> that's how extending already stabilized protocols goes.
>
> A further complication here is that currently, the definition of the
> XML language is literally "what wayland-scanner accepts", bugs and
> oversights in wayland-scanner notwithstanding. This makes it tricky to
> add XML language features that are not really used in the C bindings.
>
> Or, would it be ok to dismiss all non-C languages as second-class
> citizens, and say that we can change whatever as long as it does not
> break the wire format, wayland-scanner or the bindings generated by it?
> Somehow I don't think that would be an acceptable position.
>
> This is actually a fundamental question:
>
> Should we make any stability guarantees towards non-C bindings
> generators that exceed what we need for C?
>
> If no, then there's nothing to solve, but like I said, that would be
> pretty harsh and inconsiderate.
>
> Since most XML file authors are likely going to test only with
> wayland-scanner, wayland-scanner should detect as many problems as
> possible. This is why I have asked for generator patches to at least use
> the new attributes somehow. Otherwise we would be breaking the non-C
> generators all the time.

I agree (if that's what you're saying) that this point about
compatibility is the main debate towards the new attributes.

However, I'm not sure who you are trying to protect here. Everyone
agrees that the new attributes should not change anything for C/C++,
and in the current patches, they don't. And the other bindings writers
understand the compatibility issues regarding this change, and, if I
may speak for the majority of them, care much less about compatibility
issues than about being able to provide proper APIs for their users.

In haskell, and many other modern languages, an easily fixable compile
issue (we keep calling it a compatibility issue, which I think is a
misnomer, although I don't know what category it should fall under) is
*vastly* preferred over a potential bug. Arguably, that's the entire
point of the language. Modern languages attempt to cross-check as many
properties as possible, and the enum attribute would contribute
greatly to this, even if that means breaking API every so often.

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. More importantly, this problem
does not matter because it is not a problem but a *solution*.