On Fri, Sep 16, 2016 at 10:43 AM, J Decker wrote:
> I saw it mentioned in several messages earlier about the comma operator as
> applied to the let/var statement... I suppose that IS an issue.
>
> for example : if( let a = 1, b = 0 )
> 1) if( 1, 0 ) the comma operator clears the expression st
I saw it mentioned in several messages earlier about the comma operator as
applied to the let/var statement... I suppose that IS an issue.
for example : if( let a = 1, b = 0 )
1) if( 1, 0 ) the comma operator clears the expression stack and
results with only the value after the comma... so you
On Fri, Sep 16, 2016 at 2:43 AM, Bob Myers wrote:
> I often find myself wanting to do this in the case of `while`. I've been
> writing
>
> ```
> for (let a; a = someLongCondition();) { doSomethingWith(a); }
> ```
>
> In that spirit, an oddball proposal:
>
> ```
> while (let a = someLongCondition(
I often find myself wanting to do this in the case of `while`. I've been
writing
```
for (let a; a = someLongCondition();) { doSomethingWith(a); }
```
In that spirit, an oddball proposal:
```
while (let a = someLongCondition(); a) { ...use a... }
if (let a = someLongCondition(); a) { ...use a...
I say let's hold off until JavaScript gets pattern matching support
(assuming it does). It's rather limiting otherwise, and the use case IMHO
doesn't really merit a new syntax for it.
On Thu, Sep 15, 2016, 15:47 Jeremy Martin wrote:
> > If yes ... why would anyone write that ?
>
> I think it wou
> If yes ... why would anyone write that ?
I think it would have to be "yes" (and that's probably just a contrived
example that doesn't demonstrate the usefulness).
Slightly less contrived, I could see the value in this, though. E.g.,
```
router.get('/user', (req, res, next) => {
if (let use
> if( let a = ( let b = 10 ) * 3 > 10 )
I've honestly no idea, at first/quick read, what the hell that would
produce.
Is `a` going to be just `true` ? 'cause if not, this proposal violates
operator precedence.
If yes ... why would anyone write that ?
On Thu, Sep 15, 2016 at 7:30 PM, J Decker w
Why not more generally - allow let/var declarations in expressions?
coming from a long and rich C background, I have no issues with the
existing mechanisms... but for those languages that do support variable
declarations in for loops; I've always wondered why not any expression?
if( let a = ( let
On 09/12/2016 05:32 PM, Danielle McLean wrote:
In current ECMAScript, it is legal to place a variable declaration inside the
initialiser of a `for` loop, as well as to declare the variable used by a
`for...in` or `for...of` loop within the declaring expression:
for (let i = 0; i < 5; ++i) c
I agree but at the same time those examples simply look like bad coding
practices to me and we can't completely hide from those. Since it's new
semantics we shouldn't have to worry about it breaking something existing
and it would be really easy to do a transpile back into ES5 or ES6 should
people
The main barrier that I can see is that this requires new semantics. At
the moment, variable declarations don't have any kind of usable result. If
you consider
let a = eval('let b = 1');
console.log(a);
//-> undefined
This sounds like an easy thing to solve, but how about this:
I really like the idea of declaring a variable directly in the conditional
itself. Many other languages do it. It's certainly not a critical thing (it
makes 2 lines of code into 1) but I certainly would like it to happen.
Considering it only moves the declaration I'm not convinced it makes code
har
How so? Assignment is already possible in control structures. I think this
reads better:
```
if (let a = foo) {
```
Than:
```
let a;
//...
if (a = foo) {
```
Having the `let` or `const` inside the conditional part clarifies the
intent. There's an argument for not doing assignment inside the
For what it's worth, I'm on the side of people that do not want to see
assignment statements in control structures. I don't think it is necessary
and it results in code that is harder to read.
On Wed, Sep 14, 2016 at 8:51 PM, Alan Johnson wrote:
> What about `else if`?
>
> On Sep 14, 2016 9:28 P
"Bergi" wrote:
> What about `else` blocks, would the variables be available in them as well?
No. If the `else` block executes, then the variable's value would be
falsy and therefore presumably not useful for further processing. Of
course, there are multiple falsy values in ES, but knowing which
What about `else if`?
On Sep 14, 2016 9:28 PM, "Bergi" wrote:
> Danielle McLean wrote:
>
> variables declared
>> using `let` or `const` would be scoped to the individual `if` or `while`
>> statement, rather than the containing block. In other words, the above
>> syntax
>> would be equivalent to
Danielle McLean wrote:
variables declared
using `let` or `const` would be scoped to the individual `if` or `while`
statement, rather than the containing block. In other words, the above syntax
would be equivalent to the following currently-valid form I ended up writing:
{
const oldVal
For what it's worth, that specific use case would be addressed by
https://github.com/tc39/String.prototype.matchAll ;-)
On Wed, Sep 14, 2016 at 4:20 PM, Oriol Bugzilla
wrote:
> I like this proposal. Specially for `while` loops.
>
> When I want to iterate all matches of a global regex, I always t
I like this proposal. Specially for `while` loops.
When I want to iterate all matches of a global regex, I always think the
variable declaration at the top seems ugly
```js
let match;
while (match = regex.exec(string)) {
// ...
}
```
This looks better:
```js
while (let match = regex.exec(str
Given that `let x == 10` or `let x === 10` is illegal, it doesn’t seem too bad
to allow `if (let x = f(y))`, LexicalDeclaration is visually distinct from
EqualityExpression because of the `let` or `const` prefix.
> On Sep 14, 2016, at 6:41 PM, Jordan Harband wrote:
>
> While I like the idea o
While I like the idea of making it simpler to restrict the scope of
variables, currently a reigning best practice is to never do assignment in
conditionals, since it can be an easy typo from `==` or `===`, and because
it conflates assignment with expression truthiness, harming readability.
This se
On 14 September 2016 at 17:58:24, Viktor Kronvall
(viktor.kronv...@gmail.com(mailto:viktor.kronv...@gmail.com)) wrote:
> Does this really need new semantic interpretation of the syntax? Using the
> `Array.prototype` methods `.forEach` and `.map` already mitigates this
> problem as far as I can t
Does this really need new semantic interpretation of the syntax? Using the
`Array.prototype` methods `.forEach` and `.map` already mitigates this
problem as far as I can tell by having a different bound variable (argument
in this case) for each call.
I agree that the behavior may be non-intuitive
An alternative to the block which you ended up with is to extract that
logic to a function, which provides something which can be tested too.
Possibly overkill for oneliners like this though.
However, writing a lot of code like this myself (get a value, if it's
truthy do something, else do other),
24 matches
Mail list logo
