Consider renaming numeric types to match ECMAScript typed arrays

[ExE-Boss]

Currently, WebIDL uses C names for number types.

This doesn’t match either ECMAScript or WebAssembly, where the former just uses the generic IEEE 754 64‑bit number type, and the latter uses s* for signed integers, u* for unsigned integers and f* for IEEE 754 floating point numbers.

I suggest applying the following renaming for integers:

Current (WebIDL)	Proposed (ECMAScript‑style)	Proposed (Rust‑style)	Proposed (WASM‑style)
byte	int8	i8	s8
octet	uint8	u8	u8
short	int16	i16	s16
unsigned short	uint16	u16	u16
long	int32	i32	s32
unsigned long	uint32	u32	u32
long long	int64	i64	s64
unsigned long long	uint64	u64	u64

And the following for floating‑point numbers:

Current (WebIDL)	Proposed (ECMAScript‑style)	Proposed (Rust/WASM‑style)
float	float32	f32
unrestricted float	[Unrestricted] float32	[Unrestricted] f32
double	float64	f64
unrestricted double	[Unrestricted] float64	[Unrestricted] f64

Unlike the current names, where several programming languages use long for different integer sizes:

Language	long
C	int32
C#	int64
Java	int64

By using the int*/sint*, uint* and float* forms, it becomes clear at first glance what the integer size is.

See also:

• Proposed solution to make grammar changes less disruptive #477

[bzbarsky]

Do the IDL types actually have the same semantics as the WebASM types? Because if not, naming them the same thing is a bit dangerous.

I do agree that it would be nice if the size were just explicit. But whether changing every single web spec for this is worthwhile is less clear.

One option would be to add the sized typedefs explicitly and see whether people actually use them...

[ExE-Boss]

Correction: WebAssembly uses s* for signed integers, i* is for uninterpreted integers, this differs from AssemblyScript, Rust and several C header files that provide sane integer types, which use u* for unsigned integers and i* for signed integers.

Apart from that, they have mostly identical semantics, especially because the WebAssembly binding for ECMAScript is defined in WebIDL.

i32 in WebAssembly uses ToInt32, whereas WebIDL uses ConvertToInt, which behave in an identical manner.

The only difference is that WebAssembly doesn’t currently allow passing i64 values between ECMAScript and WASM code, because they intend to use bigints for that (WebAssembly/spec#707).

[annevk]

I like this idea and with @saschanaz's rewriting tool this might even be feasible (though typedefs might be good transition help nevertheless).

(One problem it would resolve is that IDL and Infra conflict on byte. What Infra calls byte IDL currently calls octet.)

[ExE-Boss]

We could also merge unrestricted f* with the f* and making the current finite‑only floating point types use [Finite] or [EnforceRange].

Alternatively, change the unrestricted keyword into the [UnrestrictedFloat] extended attribute.

That would fix the current issue with unrestricted f32 and unrestricted f64 being a parse error, preventing #856 from being built.

[TimothyGu]

While I'm in principle for this change, the resultant IDL files in #856 now look like a strange and jarring mixture between the C/JavaScript style and the more concise Rust/WASM style…

My proposal would be to use uint32, int8, etc. for integral types, and float32 and float64 for floating point types. This provides symmetry with the various TypedArray class names and DataView method names, considering JavaScript remains the primary target for Web IDL (and also the fact that TypedArray classes are also Web IDL types). But no less importantly, it retains the same Web IDL look as it has been, IMHO.

[annevk]

Now that extended attributes can modify the type a [LegacyUnrestricted] extended attribute would probably work and might be nicer. We should probably make that change separately (and first) though.

[domenic]

I don't think unrestricted is legacy. But also it should remain opt-in; it's intentional that spec authors not have to think about Infinity/NaN cases when writing their specs unless they explicitly opt in to doing so.

[ExE-Boss]

That’s why I went with [UnrestrictedFloat] instead of [LegacyUnrestricted] in #857.