revive let blocks

Benjamin Gruenbaum benjamingr at gmail.com
Thu Jun 18 13:35:26 UTC 2015


> From: Kyle Simpson <getify at gmail.com>
To: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
Cc:
Date: Thu, 18 Jun 2015 07:34:28 -0500
Subject: Re: revive let blocks
> > (function (a, b, c) {
> >
> > }(2))

> The main disadvantage of that style over the one I'm advocating for is
that it visually separates the variable declaration (`a`) from its value
initialization (`2`).

If that's the problem you can do
```js
((a = 2, b, c) => {

})();
```

And engines can optimize - but I can see the merit of explicit syntax for
this.

> I prefer creating explicit blocks for scope rather than implicitly
hijacking existing blocks for scope. I prefer to be able to reason about my
`if` block separately from a localized block of scope that may appear
inside it. That's why I create the explicit `{ .. }` block to put my `let`
declarations in. And that's why the next logical step is to move the `let`
declarations to a syntactic form that forcibly attaches them to the block,
making the purpose/intent of the block all that much clearer.

Well, traditionally this is something we've been moving _from_ in languages
- for example in C (before C99) you used to have to declare variables on
the top of a scope but don't anymore.  In Pascal, you had `var` for this
and this was complained about by people.

Why would a syntactic addition to the language be better than a linter here
that verifies where you declared your variables? The only issue I see here
where this sort of thing can be really important (and justify adding it for
other cases anyway) is stack allocation in a dynamic language - but I'm not
sure how that proposal looks like yet and from what I understand it'll be
discussed in the July TC meeting.

If anyone could shed light on the current ideas for stack allocation that'd
be great :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150618/58462791/attachment.html>


More information about the es-discuss mailing list