You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(if i'm recalling correctly) @syg pointed out that there might be memory issues with holding on to every intrinsic, and asked if this proposal could include only hidden intrinsics.
The upside: we could explicitly list all the hidden intrinsics in the spec, and implementations wouldn't have to keep track of every intrinsic. Additionally, https://npmjs.com/get-intrinsic and SES and test262 would all be able to drop their custom hardcoded ways to reach hidden intrinsics, since they're all now discoverable.
The downside: both https://npmjs.com/get-intrinsic and SES would have to retain their "walk the graph" approach in order to locate all intrinsics.
I strongly prefer that this be all intrinsics - "just hidden" would certainly achieve the SES need of ensuring that hidden intrinsics are no longer undiscoverable, but it wouldn't achieve the ergonomic and API requirements that motivated the proposal in the first place.
The text was updated successfully, but these errors were encountered:
An orthogonal question is whether to list all intrinsics or just reachable ones. There are actually 2 subsets in this subtle distinction:
Intrinsics that are currently never exposed to user code, and are really more like spec fiction. E.g. %ForInIteratorPrototype%
Intrinsics that are optionally exposed to user code, like %SharedArrayBuffer% and derived. The global SharedArrayBuffer is optional and a host may not provide a wasm or similar integration which means there would no alternative way of observing these intrinsics.
I don't believe spec fiction intrinsics should ever be exposed through any means, and I would strongly prefer that it would be permitted to skip otherwise unreachable intrinsics.
(There is also an argument to be made the better term according to the glossary would be primordial instead of intrinsic.)
Absolutely fictional intrinsics would never be included in this list.
Additionally, any intrinsic that isn't otherwise reachable through this proposal would certainly not be included - if SAB is not otherwise exposed in JS as a global, then it wouldn't be exposed here.
(if i'm recalling correctly) @syg pointed out that there might be memory issues with holding on to every intrinsic, and asked if this proposal could include only hidden intrinsics.
The upside: we could explicitly list all the hidden intrinsics in the spec, and implementations wouldn't have to keep track of every intrinsic. Additionally, https://npmjs.com/get-intrinsic and SES and test262 would all be able to drop their custom hardcoded ways to reach hidden intrinsics, since they're all now discoverable.
The downside: both https://npmjs.com/get-intrinsic and SES would have to retain their "walk the graph" approach in order to locate all intrinsics.
I strongly prefer that this be all intrinsics - "just hidden" would certainly achieve the SES need of ensuring that hidden intrinsics are no longer undiscoverable, but it wouldn't achieve the ergonomic and API requirements that motivated the proposal in the first place.
The text was updated successfully, but these errors were encountered: