whatwg
Normative: Rename integer types to match ECMAScript typed arrays
I’ve separated out the integer types rename from https://github.com/heycam/webidl/pull/856, as it has greater support and can be done without waiting for parser changes (see also https://github.com/whatwg/webidl/issues/477).
This renames the integer types to match ECMAScript typed arrays in order to resolve the conflict between the Infra byte and the IDL byte; refs https://github.com/whatwg/webidl/issues/843#issuecomment-586203060:
(One problem it would resolve is that IDL and Infra conflict on byte. What Infra calls byte IDL currently calls octet.)
Floating‑point types were left for a future PR because it’s not possible to simply rename unrestricted float/unrestricted double to unrestricted float32/unrestricted float64 without the parser being updated first, which is why that depends on something like https://github.com/whatwg/webidl/pull/857.
I decided to go with int* for signed integers since it’s what ECMAScript typed arrays use, and because ECMAScript provides built‑in support for 32‑bit signed integers using the bitwise OR operator, but none for unsigned integers:
let numInt32 = (num | 0); // Converts `num` to a 32-bit signed integer
ECMAScript Arrays also restrict the length to a positive 32‑bit signed integer.
- Part of: https://github.com/whatwg/webidl/issues/843
- Extracted from: https://github.com/whatwg/webidl/pull/856
- [ ] At least two implementers are interested (and none opposed):
- …
- …
- [ ] Tests are written and can be reviewed and commented upon at:
- …
- [ ] Implementation bugs are filed:
- Chrome: …
- Firefox: …
- Safari: …
(See WHATWG Working Mode: Changes for more details.)
Seeing new activity on this, I'm curious if this change is a sure thing - i.e. is this renaming settled and there's just remaining work to do to get everything aligned, or is it still an open question?
(I think these are positive changes - even though I've grown kinda of fond of the quirky old names. My interest stems from maintaining some Web IDL tools that will need to be updated to account for this.)
I think this is a good change if we can pull it off, with regards to the tooling and downstream review impact.
I also like this since this fits better with modern C++ integer names and most of implementations are in C++ (with an exception of Servo but it also better matches Rust names).
Thanks for removing the pseudo IDL blocks but I mean the aliases are probably not needed at all, and parsers can support both in the reasonably short term while @autokagami sends patches. It does depend on how quickly maintainers will respond (and plus, on whether other people here are convinced), though.