Use of "normative optional" annotation should be more consistent about ecma262 HOT 8 OPEN

SAB should definitely be marked as normative optional, as that's explicitly what got consensus.

Re 2, i'm pretty certain that was the exact goal for SES-adjacent concerns, that the constructor property must be deniable.

from ecma262.

If I understood correctly, this part should have a normative-optional attribute, right? If so, then I'm ready to prepare a pull request

<p normative-optional>Whenever a host does not provide concurrent access to SharedArrayBuffers it may omit the *"SharedArrayBuffer"* property of the global object.</p>

from ecma262.

We're actually still discussing in Matrix whether the whole SAB feature should be marked as normative optional. Technically it's the same as hiding the constructor from the global unless the host exposes it, or if the language gains the ability to discover hidden intrinsics in the future.

from ecma262.

@mhofman We specifically didn't do that in #1903 because some hosts (including notably browsers) do expose it somewhere other than the global. Normative optional features are all-or-nothing, so marking the whole feature as normative optional would mean that if the constructor was not on the global then hosts could not expose it any other way, and hence would not accomplish the goal of allowing the actual behavior browsers implement.

Where on Matrix are those conversations happening? Feel free to DM me if you don't want to put the link here.

from ecma262.

The discussion is around here: https://matrixlogs.bakkot.com/TC39_Structs_and_Shared_Structs/2024-02-15#L11

And yes, my question was that if the host does not expose the SAB constructor in any other way (wasm), is it supposed to implement the feature at all? It's not observable today, but it may become observable in the future.

Then of course if the feature is implemented and exposed through a host mechanism, there is also the question of whether the constructor should be on the global.

IMO, Normative optional means that from the author's pov, the feature may or may not be present, and that an implementation is spec compliant if it doesn't implement the feature.

from ecma262.

My expectations would be that if there is another way to get at SharedArrayBuffer, it must conform to the spec, but if there is not, then it would never be observably implementable, which means it must be normative optional - but with caveats as described.

from ecma262.

My question is, if the language itself introduces a way to discover intrinsics (or just "hidden" ones), is a conformant implementation allowed to skip all SAB intrinsics, if they're not otherwise reachable any other way.

from ecma262.

Yes, that would need to be an explicit part of the getIntrinsics proposal, I think - that no intrinsic names may be returned or accepted unless the value is reachable from user code.

from ecma262.