On Oct 2, 2014, at 8:31 AM, Andreas Rossberg <rossberg at google.com> wrote:

> On 2 October 2014 17:17, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
>> I believe that the module champions have always wanted static unresolvablse reference rejection to be part of the module semantics.  But we've never had actual specification for that semantics.
> 
> Yes, I had always hoped for a "stricter mode" applied to modules. But
> I don't think that's something that's still possible at this (or a
> later) point. If it had been, then it would have made total sense for
> it to check against const assignments as well, along with a number of
> other things.

Yeah, I did wish for it, but we conceded a long time ago that it wasn't going to work out to have additional checks in modules. It's especially problematic because whether something is unbound or global is entirely dynamic (globals can be added and removed), scripts can be loaded at dynamically unpredictable times (so predicting the state of the global at the time code will be loaded is hard), in some modes HTML even throws element ids on the global and removes them again ...

> 
>> Personally, I think it would be fine for all of these sort of conditions to be specified as runtime errors and leave it to linters to find them early and JS implementations to optimize the runtime checks away.
> 
> Outside modules, with the language being as it is, adding one minor
> new static check definitely does not seem worth the trouble and the
> cost risk.

Agreed. The consolation prize is that modules now make it possible for linters to do free variable analysis and errors without any user-configuration at all. (By contrast, JSHint has historically required programmers to annotate the set of globals they intend to use so that they aren't reported as free variable errors.)

Dave

On Oct 2, 2014, at 8:31 AM, Andreas Rossberg <rossberg at google.com> wrote:

> Yes, I had always hoped for a "stricter mode" applied to modules. But
> I don't think that's something that's still possible at this (or a
> later) point. If it had been, then it would have made total sense for
> it to check against const assignments as well, along with a number of
> other things.

Yeah, I did wish for it, but we conceded a long time ago that it wasn't going to work out to have additional checks in modules. It's especially problematic because whether something is unbound or global is entirely dynamic (globals can be added and removed), scripts can be loaded at dynamically unpredictable times (so predicting the state of the global at the time code will be loaded is hard), in some modes HTML even throws element ids on the global and removes them again ...

> Outside modules, with the language being as it is, adding one minor
> new static check definitely does not seem worth the trouble and the
> cost risk.

Agreed. The consolation prize is that modules now make it possible for linters to do free variable analysis and errors without any user-configuration at all. (By contrast, JSHint has historically required programmers to annotate the set of globals they intend to use so that they aren't reported as free variable errors.)