Re: Proposal: if variable initialization

Wed, 21 Mar 2018 10:28:10 -0700

Because block-level scoping is a very good way to avoid certain bugs and is easier to reason about. Especially when considering project successors. 

Now, you cannot say that arguing that other languages have it is irrelevant. That is not the case because they have decided to so for good software engineering reasons. They could have easily had everything functionally scoped too but they don't. 

And bringing up your opinion that we don't need a feature that is currently in the spec is not helpful in this context because it is never going away, that would be an insane breaking change. 


*rant over*

Otherwise, the for(;;) syntax seems like the best and most intuitive. Especially for how that would work actually. 

Question though, would the variable be available in an else or else-if block

Sebastian Malton

Sent: March 21, 2018 1:21 PM
Subject: Re: Proposal: if variable initialization

how is any of this less-confusing than a simple style-guide of pre-declaring all variables @ the beginning of a function?
again, there’s zero legitimate reason why _javascript_ even needs block-level scoping of variables (and arguing because other languages have it is not a reason).  you're just creating more needless _javascript_ style-guide variance that further confuses your team-members / project-successor.

```
/*jslint
    bitwise: true,
    browser: true,
    maxerr: 8,
    maxlen: 100,
    node: true,
    nomen: true,
    regexp: true,
    stupid: true
*/
(function () {
    'use strict';
    // es5 best-practice of declaring all variables at beginning of function,
    // and runtime-checked by 'use strict' pragma
    var bar,
        c0,
        c1,
        foo,
        getTeamArray,
        people,
        v1,
        xx,
        yy;



    getTeamArray = function () {
        return [1, 2, 3];
    };
    people = getTeamArray();
    if (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");
    }
    // output: it's a crowd 1,2,3



    bar = function () {
        return 0;
    };
    foo = function () {
        return 50;
    };
    (function () {
        xx = foo();
        if (xx < 50) {
            console.log(xx); // yy is not available here
            return;
        }
        yy = bar();
        if (yy > 0) {
            console.log(yy);
            return;
        }
        // else
        console.log(xx, yy);
    }());
    // output: 50 0



    c0 = null;
    c1 = function (xx) {
        return xx;
    };
    v1 = false;
    // 'unset' xx
    xx = undefined;
    (function () {
        if (c0) {
            console.log(c0); // xx is not available here
            return;
        }
        xx = v1;
        if (c1(xx)) {
            console.log(xx);
            return;
        }
        // else
        console.log(c0, xx);
    }());
    // output: null false
}());
```

On Mar 22, 2018, at 1:56 AM, Mike Samuel <[email protected]> wrote:



On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo <[email protected]> wrote:
My proposal is to keep it simple and implement the if-assignment `if(
const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignment
behavior.

Fair enough.  If the assignment is separate from the condition, then none of that matters.
That question only pertained to let/const declarations used for their value.

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");
       }

IIUC, it sounds like the right side could be syntactic sugar for the left side.
If that's right, what about the left side warrants new syntax to enable the right?
 

CurrentProposed
  {
       let people = getTeamArray();
       if( 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");
       }
  }
   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");
   }

I can imagine that it might be nice when used later in an else-if chain:

if (c0) {
  ...
} else (let x = v1, c1(x)) {
  ...
} else ...

vs

if (c0) {
  ...
} else {
  let x = v1;
  if (c1(x)) {
    ...
  } else ...
}

Can you point at any particularly tricky code that could be simplified by this?
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to