Brian Di Palma wrote:
> The recent thread on throwing errors on mutating immutable bindings
> touched upon the fact that there is no static unresolvable reference
> rejection in modules.
> I was wondering if that was down to needing to allow access to
> properties set on the global object?
>
> If that's the case why could you not just import the global into a module scope?
> Just like you import module meta data the module system could have a
> way of providing you the global object if you import it.
> That would mean that any reference that is accessed via the global
> import can't be checked but every other one can.
>
> Something like
>
>
> import * as global from "@global";
>
> const myValue = global.myGlobalFunction(); //Special won't be checked
> can be mutated by everyone, big red flag in code reviews.
>
> function test() {
>      x = 10; //Static error, we know this is not an access to a global
> x as it must be accessed via global.
> }
>
>
> Could this work?

The problem this doesn't solve is the one Andreas Rossberg raised (at a 
past TC39 meeting, and just the other day here): browser-based 
implementations must parse lazily and super-fast, they cannot be 
presumed to be able to afford binding checks. Someone should go 
super-hack a binding checker that doesn't degrade page load perf, or 
other metrics.

Absent such evidence, there are two strikes against what you propose: 1) 
performance effects of binding checking when parsing; 2) whether async 
script loads make global bindings unordered and so not generally worth 
trying to check.

/be

The problem this doesn't solve is the one Andreas Rossberg raised (at a 
past TC39 meeting, and just the other day here): browser-based 
implementations must parse lazily and super-fast, they cannot be 
presumed to be able to afford binding checks. Someone should go 
super-hack a binding checker that doesn't degrade page load perf, or 
other metrics.

Absent such evidence, there are two strikes against what you propose:

1. performance effects of binding checking when parsing;
2. whether async script loads make global bindings unordered and so not generally worth 
trying to check.

The problem this doesn't solve is the one Andreas Rossberg raised (at a 
past TC39 meeting, and just the other day here): browser-based 
implementations must parse lazily and super-fast, they cannot be 
presumed to be able to afford binding checks. Someone should go 
super-hack a binding checker that doesn't degrade page load perf, or 
other metrics.

Absent such evidence, there are two strikes against what you propose: 1) 
performance effects of binding checking when parsing; 2) whether async 
script loads make global bindings unordered and so not generally worth 
trying to check.