On 21 March 2012 20:05, Allen Wirfs-Brock al...@wirfs-brock.com 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.
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 know
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, regardless of TDZ
On 20 March 2012 21:46, Allen Wirfs-Brock al...@wirfs-brock.com 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
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
On 21 March 2012 17:47, Brendan Eich bren...@mozilla.org 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
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
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;
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 all
On Tue 20 Mar 2012 16:45, Andy Wingo wi...@igalia.com 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
On Mar 20, 2012, at 8:55 AM, Andy Wingo wrote:
On Tue 20 Mar 2012 16:45, Andy Wingo wi...@igalia.com 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
On Tue 20 Mar 2012 21:13, Allen Wirfs-Brock al...@wirfs-brock.com writes:
On Mar 20, 2012, at 8:55 AM, Andy Wingo wrote:
On Tue 20 Mar 2012 16:45, Andy Wingo wi...@igalia.com writes:
Your original post doesn't seem to have made it to the discussion list.
Odd. Here's the meat:
On Mar 20, 2012, at 1:23 PM, Andy Wingo wrote:
On Tue 20 Mar 2012 21:13, Allen Wirfs-Brock al...@wirfs-brock.com writes:
On Mar 20, 2012, at 8:55 AM, Andy Wingo wrote:
On Tue 20 Mar 2012 16:45, Andy Wingo wi...@igalia.com writes:
Your original post doesn't seem to have made it to
On Tue 20 Mar 2012 21:46, Allen Wirfs-Brock al...@wirfs-brock.com 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
14 matches
Mail list logo
