tc39
Use of "normative optional" annotation should be more consistent
This describes a couple of related issues regarding normative optionality:
- In The SharedArrayBuffer Constructor, "Whenever a host does not provide concurrent access to SharedArrayBuffers it may omit the "SharedArrayBuffer" property of the global object" text seems identical to the requirements of Normative Optional and should be marked as such (supporting, among other benefits, cross-referencing).
- In WeakRef Objects, WeakRef.prototype.constructor is marked normative optional, implying that WeakRef is required but the "constructor" property of its prototype object is not. While this might have been the intent of #2089, there was no discussion on the point and it strikes me as rather unlikely.
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.
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>
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.
@mhofman We specifically didn't do that in https://github.com/tc39/ecma262/pull/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.
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.
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.
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.
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.