On 04/27/2015 12:05 AM, Pekka Paalanen wrote:
- From the first definition of an interface, specify how unknown values
should be handled. Otherwise users do not expect unknown values to
appear.
The latter case is where you do not want an automatic always-on warning
or error.
This is no problem. The caller has to do a cast, ie EnumName(43), to get
this value. I am pretty certain users of strongly-typed languages do not
expect a raw 43 to work and are quite willing to do the cast.
I suppose you could purposely prevent the cast from working on "final"
enuerations, but that is usually just frustrating to programmers that
will need it some times, even if they know they are only generating
valid values. In particular it may make it difficult to implement one
api atop another.
Except if you happen to have an old libwayland which you develop your
3rd party app against, for instance because you use a distribution that
does not include a more recent version yet.
The enum part of the protocol has zero effect on the implementation or
abi of libwayland. At the point functions are called in libwayland they
have already been turned into int/uint.
If the arguments to the C abi were changed to C enums instead of
int/uint it would break things. However I think the proposal is to use
the enums in minimal ways in the C abi.
Depending on the language, I suppose the breakage could go both ways?
Is there a language where an enum is not allowed to be implicitly
converted to a uint or int?
Yes lots of them. However this is irrelevant because the binding code
will be changing them to int/uint in some way. Eventually it has to
stuff the value into the Wayland byte stream and that code certainly
will be thinking about int/uint.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
