Open ExE-Boss opened 4 years ago
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...
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 bigint
s for that (https://github.com/WebAssembly/spec/pull/707).
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.)
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.
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.
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.
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.
That’s why I went with [UnrestrictedFloat]
instead of [LegacyUnrestricted]
in https://github.com/heycam/webidl/pull/857.
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 usess*
for signed integers,u*
for unsigned integers andf*
for IEEE 754 floating point numbers.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
float
float32
f32
unrestricted float
[Unrestricted] float32
[Unrestricted] f32
double
float64
f64
unrestricted double
[Unrestricted] float64
[Unrestricted] f64
long
for different integer sizes:long
int32
int64
int64
By using the
int*
/sint*
,uint*
andfloat*
forms, it becomes clear at first glance what the integer size is.See also: