-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of "normative optional" annotation should be more consistent #3280
Comments
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 #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. |
This describes a couple of related issues regarding normative optionality:
The text was updated successfully, but these errors were encountered: