My proposal is to keep it simple and implement the if-assignment `if(
const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignment
behavior.
That way we can scope a variable to the `if` block and we can do that
*separately* from assignment.
Assigning and comparing at the same time opens up all sort of oddities
as the variable transitions from lvalue to comparison operand. This
already exists in the language and is definitely not good practice.
`if.value`, as proposed earlier is a bombshell similar to `this`,
which could easily get scrambled with the introduction of additional
`if` blocks.
The beauty of `if(;)` is that it makes scope blocks possible while
avoiding the asymmetric behavior caused by assigning and comparing in
one go.
if( let people=getTeamArray(); people.length > 2 ) {
console.log("it's a crowd", people.join(','));
}
else if( people.length == 2 ) {
console.log("just a pair");
}
else if( people.length == 1 {
console.log("solo");
}
else {
console.log("none");
}
On Wed, Mar 21, 2018 at 2:37 PM, Mike Samuel <[email protected]> wrote:
>
>
> On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo <[email protected]> wrote:
>>
>> Proposal: inline let/const statements to declare and initialize
>> variables within if statements, so that temporary variables exist only
>> within the if/else block scope.
>
>
> With setters you can get some oddities because the getter need not return
> the same value set.
>
> const o = { get x() { return this.x_ }, set x(v) { return this.x_ =
> String(v) } }
> if (!(o.x = 0)) {
> console.log('o.x is falsey: ' + !o.x);
> }
>
> If decorators are allowed on let/const declarations, then you might get a
> similar source of
> confusion.
>
> This might be especially confusing since in Java and C++ the result of an
> assignment is
> the value actually assigned after any type coercion (or a reference to the
> left).
>
> In JavaScript, the result of an assignment is the result of the right
> operand.
> Though its a bit muddy, since the result of x++ is x coerced to a number for
> symmetry with x += 1.
>
> If it turns out that decorators are widely used for type annotations on
> declarations and
> some do custom coercion on assignment, does that introduce potential
> problems?
>
>
>
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
