search

tc39 / proposal-defer-import-eval

A proposal for introducing a way to defer evaluate of a module
https://tc39.es/proposal-defer-import-eval
MIT License
208 stars 12 forks source link

Concern about making local variable access side effecting #4

Closed bakkot closed 10 months ago

bakkot commented 3 years ago

We've generally tried to avoid having access to local variables be side effecting, a property which is useful both for engines and for humans reading the code. (Obviously you can break that property using with, and it does not hold for global variables.) If I'm reading this proposal correctly - if the module evaluation would happen when the bindings were first referenced - that would no longer be true for lazy-loaded module bindings. I think that's worrisome.

This isn't a blocker for stage 1, since this is a concern only about that specific strategy, and there are other possible strategies for lazy loading.

codehag commented 3 years ago

Thanks for raising this. Yes -- this is a concern with the current strategy. You mentioned other strategies, I am wondering, do you have something specific in mind already? I would like to keep this as open to other solutions as possible.

bakkot commented 3 years ago

The obvious alternative that comes to mind is that you'd have an import form which gave you a thunk for the namespace object, which the importing script could force if/when it wanted evaluation to happen. (This would have the same issue with top-level await, of course.)

nicolo-ribaudo commented 10 months ago

The proposal is now going in the direction of only supporting deferred imports through namespace imports, so that side effects only happen on property access.