On Mar 22, 2012, at 9:10 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
>>
>>> > Andreas Rossberg wrote:
>> Right, but my comment was only about checking of assignments to const
>> variables. Those are always an error, regardl
Allen Wirfs-Brock wrote:
On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> Right, but my comment was only about checking of assignments to const
variables. Those are always an error, regardless of TDZ behaviour.
>
> Agreed, absolutely. In all-strict code we k
On 21 March 2012 20:05, Allen Wirfs-Brock wrote:
> On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
> > Andreas Rossberg wrote:
> >> Right, but my comment was only about checking of assignments to const
> variables. Those are always an error, regardless of TDZ behaviour.
> >
> > Agreed, absolut
On Mar 21, 2012, at 10:11 AM, Brendan Eich wrote:
> Andreas Rossberg wrote:
>> Right, but my comment was only about checking of assignments to const
>> variables. Those are always an error, regardless of TDZ behaviour.
>
> Agreed, absolutely. In all-strict code we know all the bindings, we see
Hello,
Unifying the specifications of let and const in the latest draft means
that now, const statements can have no initializer. Is that intended?
Beyond that, const is just a bit strange. For example:
(function (){
baz = 20;
return baz;
const baz = 30;
baz = 40;
ba
Andreas Rossberg wrote:
Right, but my comment was only about checking of assignments to const
variables. Those are always an error, regardless of TDZ behaviour.
Agreed, absolutely. In all-strict code we know all the bindings, we see
all assignments.
/be
__
On 21 March 2012 17:47, Brendan Eich wrote:
> There are still temporal dead zone cases that can't be statically analyzed
> -- at least not without an aggressive higher-order control flow analysis,
> and even then analysis is approximate so we'd have to mandate false
> positives or bail to dynamic
There are still temporal dead zone cases that can't be statically
analyzed -- at least not without an aggressive higher-order control flow
analysis, and even then analysis is approximate so we'd have to mandate
false positives or bail to dynamic checks.
Isn't the issue that strict mode would d
On 20 March 2012 21:46, Allen Wirfs-Brock wrote:
> It is an open issue whether an implementation should be
> permitted/required/forbidden to report the statically detectable cases as
> early errors.
>
The obvious and (and IMO right) rule is that static checks should be
required iff the declarati
On Tue 20 Mar 2012 21:46, Allen Wirfs-Brock writes:
>> (function (){
>> baz = 20;
>> return baz;
>> const baz = 30;
>> baz = 40;
>> baz = 50;
>> })()
>> => 20
> no, throws on baz=20; because assignment to an immutable binding
Ah, I see. T
On Mar 20, 2012, at 1:23 PM, Andy Wingo wrote:
> On Tue 20 Mar 2012 21:13, Allen Wirfs-Brock writes:
>
>> On Mar 20, 2012, at 8:55 AM, Andy Wingo wrote:
>>
>>On Tue 20 Mar 2012 16:45, Andy Wingo writes:
>>
>> Your original post doesn't seem to have made it to the discussion list.
>
> O
On Tue 20 Mar 2012 21:13, Allen Wirfs-Brock writes:
> On Mar 20, 2012, at 8:55 AM, Andy Wingo wrote:
>
> On Tue 20 Mar 2012 16:45, Andy Wingo writes:
>
> Your original post doesn't seem to have made it to the discussion list.
Odd. Here's the meat:
Const is just a bit strange. For ex
On Mar 20, 2012, at 8:55 AM, Andy Wingo wrote:
> On Tue 20 Mar 2012 16:45, Andy Wingo writes:
Your original post doesn't seem to have made it to the discussion list.
>
>> Unifying the specifications of let and const in the latest draft means
>> that now, const statements can have no initiali
On Tue 20 Mar 2012 16:45, Andy Wingo writes:
> Unifying the specifications of let and const in the latest draft means
> that now, const statements can have no initializer. Is that intended?
Of course, after sending this mail, I find:
Static Semantics: Early Errors
LexicalBinding : Bind
14 matches
Mail list logo