On Oct 13, 2008, at 6:08 PM, Waldemar Horwat wrote:
> Brendan Eich wrote:
>>> Because presumably the "let x:t" became "var x:t" and var can't have
>>> types?
>>>> Why can't var have a type annotation?
>> Because a function can have many var declarations for the same
> variable and because you can use the variable before any of the var
> declarations are evaluated. You can work out the implications
> easily enough. This has been brought up at meetings before.
Of course, ES4 had var x:t all over, but as you noted, different rules
for evaluating t. Still, with new syntax comes the opportunity for
reformed semantics, including restrictions on any "bad" var abusages
we would like to move away from.
So my question remains (amended to be clear about what is the same):
why does this mean we cannot equate let and var scope at the top
level? I'm not talking about allowing them to mix in bad ways, or mix
at all (see below). I'm talking about not having an implicit block
around top-level function and global code.
> You wrote that you'd like let to become var (and unlike let as used
> within an independent block) if used at the top level of a function:
Ok, sorry for being unclear. I do not mean to translate top-level
'let' to 'var' and free let bindings from necessary restrictions. I do
mean that let binds in the variable object, and let usage restricts
other usage.
We can forbid mixed var x and let x at top level. We can require the
same single definition for any let x at any level. We can forbid
arguments usage if arguments[i] could alias a let binding, since let
is new (along with rest and optional parameters to enable arguments
deprecation).
But must we have an implicit block around programs and function bodies
that contain let declarations, distinct from the variable scope
(object)?
> What did you mean by "had better fail to compile"? Other than the
> type annotation, there is nothing about
>> function f() {
> x = 15;
> ...
> var t = some_runtime_expression;
> ...
> var x:t = ...
> }
>> that ought to fail to compile.
The assignment to x in that temporal dead zone before t's initializer
has been evaluated.
Why is this different if you s/var x/let x/?
/be