-
Notifications
You must be signed in to change notification settings - Fork 67
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
Import assertions #351
Comments
It must support import assertions, or you wouldn’t be able to import json from a fresh realm where nobody could have mutated it. |
Yes, import assertions surely need to be threaded through here, although they will be quite useless at first. The absence from the current specification is purely historical, as import assertions were not yet Stage 3 when the Realm spec was written. IMO the third argument of importValue should be of the same form as the second argument of dynamic import (which should ensure forward compatibility with evaluator attributes, which seem to have new interest in committee). |
You will not be able to do that @ljharb, it will throw because the object can't cross the callable boundary. |
ha, good point I’d still expect assertions to work in a general sense. |
I agree that these should be plumbed through. The difference is observable since some things will be errors rather than having that third argument ignored. Theoretically, import assertions might work in some "other" host environment. |
Prior to ShadowRealm, stage 3 proposal import assertions introduced a new parameter to the dynamic import call as:
Also notably, stage 1 proposal like https://github.com/tc39/proposal-import-reflection is trying to introduce new options to the second parameter of dynamic import call:
Should
ShadowRealm.prototype.importValue
support such features?The text was updated successfully, but these errors were encountered: