This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
People are justifying using "octet" as terminology because IDL has it. Per https://encoding.spec.whatwg.org#byte we standardize on byte. So... Perhaps avoid calling these bytes directly altogether, as we have ArrayBuffer and friends for that. "short short" and "unsigned short short"?
We should just adopt the ES terms here. Int8, Uint8, etc. See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-typedarray-objects
+1, the ES terms are easy to understand and pretty standard.
(In reply to Tab Atkins Jr. from comment #2) > +1, the ES terms are easy to understand and pretty standard. +2 :-)
I dunno, I'd rather do something more ambitious (we have another bug for it) where the only type is "number" and you use a restriction specifier for parameters like foo(ClampBetween(0, 255) number bar) // clamps to range baz(EnsureBetween(0, 255) number bar) // throws outside range
Elsewhere [1], I proposed something like: typedef Number[−128..127] Byte; Having that would shrink the WebIDL spec significantly too ;) [1] https://github.com/heycam/webidl/issues/14
"Byte" is ambiguous - it means 8 bits, but doesn't specify how to interpret it. Int8 and Uint8 have no such issue.
(In reply to Tab Atkins Jr. from comment #6) > "Byte" is ambiguous - it means 8 bits, but doesn't specify how to interpret > it. Int8 and Uint8 have no such issue. for sure, the point is just to have some syntax to declare ranges... we might be able to kill a whole bunch as they are probably not used in specs.
> we might be able to kill a whole bunch as they are probably not used in specs. The following are used in specs as function arguments or writable attributes: octet, short, unsigned short, long, unsigned long, long long, unsigned long long. So the only unused one seems to be "byte". It's used for return values and constant values, but I don't see any obvious coercious to "byte" offhand.
One problem with using the uint8 name is that in theory ES wants to add native int8/uint8/etc. types: https://github.com/nikomatsakis/typed-objects-explainer/blob/master/core.md#primitive-type-definitions. It would be confusing for WebIDL to mean something (very) different. Still it'd be nice to fix the problem in the OP, without having to first solve the whole ambitious reform-number-types idea. Not sure what to do. (I plan to go comment on Marcos's GitHub issue with ideas for number types.)