Re: [whatwg/webidl] BREAKING: Convert the `unrestricted` keyword into an extended attribute (#857)

Very late to this, but in case it were to return:

Currently extended attributes are described like this:

> ...used to control how language bindings will handle those constructs...

And the extended attributes defined by Web IDL are described like this:

> This specification defines a number of extended attributes that are applicable to the ECMAScript language binding, which are described in § 3.3 Extended attributes.

That description doesn’t outright preclude the possibility that the “built-in” EAs could also be applicable to other language bindings — but it’s notable that if so, it would not be due to anything the spec states on the matter. Certain EAs seem like they surely ought to have significance to other bindings, but the current definitions of EAs stay true to the text quoted above: all of their effects and associated algorithms are specific to ECMAScript. CrossOriginIsolated, for example, is not defined in terms of its abstract effects but its concrete effects on the initialization of Web IDL constructs in a new ECMAScript realm.

Most non-exposure-related EAS don’t have an “intuitive” applicability outside of JS though. Looking at the existing applicable-to-numeric-types EAs, would there be any reason to believe that [Clamp] or [EnforceRange] should have significance for other language bindings? Their defined behavior appears pretty specific to ES’s Number type. In new bindings for a language with a native u64 type, it would be a bit odd if the setting a `[Clamp] long long` attribute to 0x20_0000_0000_0000 would mean it first gets converted it to 0x1F_FFFF_FFFF_FFFF (assuming a generous interpretation of all of the algorithm steps that wouldn’t be coherent anyway).

To me this makes it seem a lot like `unrestricted double` isn’t `double`-but-annotated. The Web IDL types proper have different value ranges — it’s not just about the behaviors realized at the boundary between ES and Web IDL.

This PR does (or would have) addressed this since this sentence is unqualified by anything specific to ES:

> When defined with the [Unrestricted] extended attribute, the float type additionally corresponds to the single-precision 32 bit IEEE 754 non-finite, and special "not a number" values (NaNs).

If this is still bubbling, I’d suggest that having a clearer model of the intended scope of EA effects first would be helpful, and that the EA introduction would need to be updated to make it explicit that some, like [Unrestricted], are _not_ binding-specific. However I also suspect this wouldn’t be a positive change and that it’s actually desirable for EAs, at least those applicable to types, to remain binding-specific.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/webidl/pull/857#issuecomment-962511023