Re: Proposal: if variable initialization

[Isiah Meadows]

Fun fact: you'd be surprised how many non-trivial JS stuff there is.
If you've ever used jQuery selectors, you've used a selector engine
implemented in JS [1], which uses quite a few advanced data structure
and algorithm techniques. Not all JavaScript is inherently async, nor
does it need to be. Updating the UI in larger web apps can't be easily
done synchronously, and it requires significant familiarity with data
structures. The alternative is to do it all server side, but then
you're wasting resources doing what your client could do just as
easily - it doesn't necessarily have all the data, but it certainly
has a working CPU and RAM chip. At smaller scale like with typical
business websites, it doesn't matter, but at even mid-level startup
scale, it drives server costs down quite a bit. (If you can move 15%
of the RAM/CPU workload to the client without affecting perceptible
performance, that's 15% fewer servers/data clusters you need. For
Facebook and Google, that could mean one less data center they have to
build and maintain.)

Also, little language annoyances are themselves worth tackling as real
problems. Programming languages aren't just made to solve problems.
They are also themselves an art form unto themselves.

[1]: https://github.com/jquery/sizzle/blob/master/src/sizzle.js
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Mar 21, 2018 at 3:56 PM, kai zhu  wrote:
> @mike yes that’s true, but issues with blocking-code javascript
> data-structures/algorithms are rarely the reason web-projects fail.  they
> fail largely due to unresolvable integration-level io/workflow issues (that
> are unique only to javascript).  block-scoping fixes the insignificant
> former, while exacerbating the more pressing latter, by encouraging people
> to pollute variable-declarations all-over-the-place; making it harder to
> discern-and-debug which ones are critical io-related closure-variables and
> which ones are not.
>
> data-structure and algorithmic coding-skills are rarely all that useful in
> javascript (just throw sqlite3 at it and it will likely go away).
> integration-level debugging-skills (and knowledge of which coding
> design-patterns to employ to make io easier to debug) are far more valuable
> and correlable to successfully shipping a web-project.
>
> On Mar 22, 2018, at 3:47 AM, Mike Samuel  wrote:
>
>
>
> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton 
> wrote:
>>
>> Because block-level scoping is a very good way to avoid certain bugs and
>> is easier to reason about. Especially when considering project successors.
>
>
> +1.  function-scoped variables in loop bodies caused tons of bugs before
> let-scoped variables and were a main motivating case.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
>
> vs
>
> for (let i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
>
> Yes, linters got pretty good at finding uses of closed-over variables
> modified in a loop, but the workarounds were not ideal.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function (i) { return function () { /* Do something with */ arr[i]; }
> }(i));
> }
>
> Block scoping is just better for code that uses loops, variables, and
> function expressions.
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Isiah Meadows]

My implication was that it'd only be available in the `if` (if
declared with `let`/`const`).
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Mar 21, 2018 at 6:25 PM, Sebastian Malton  wrote:
> Sorry if I missed a message but would such an initialization be only 
> available in the first `if` block or also in the subsequent `else if` and 
> `else` blocks?
>
> Sebastian Malton
>
>
>   Original Message
> From: isiahmead...@gmail.com
> Sent: March 21, 2018 6:18 PM
> To: mikesam...@gmail.com
> Cc: sebast...@malton.name; es-discuss@mozilla.org
> Subject: Re: Proposal: if variable initialization
>
> I'm personally very much *for* this `if (var ...; cond) { ... }`
> syntax. I couldn't tell you how many times I would've liked something
> to that effect, since that's probably one of my biggest areas of
> boilerplate.
>
> I would also be in favor of `if (var ...) { ... }` as a shorthand that
> guards `!= null` the expression result (pre-match), since that's about
> 90% of my use cases for it. There *is* a potential area of ambiguity
> in sloppy for `if ( let [ x ] = y )`, since that would be currently
> parsed as `var tmp = y; let[x] = tmp; if (tmp) { ... }`, but I doubt
> breaking that would be of much web compat risk. (A similar ambiguity
> existed with `for (let [`, but that break didn't cause many issues.)
> -
>
> Isiah Meadows
> m...@isiahmeadows.com
>
> Looking for web consulting? Or a new website?
> Send me an email and we can get started.
> www.isiahmeadows.com
>
>
> On Wed, Mar 21, 2018 at 2:47 PM, Mike Samuel  wrote:
>>
>>
>> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton 
>> wrote:
>>>
>>> Because block-level scoping is a very good way to avoid certain bugs and
>>> is easier to reason about. Especially when considering project successors.
>>
>>
>> +1.  function-scoped variables in loop bodies caused tons of bugs before
>> let-scoped variables and were a main motivating case.
>>
>> var i;
>> for (i = 0; i < arr.length; ++i) {
>>   f(function () { /* Do something with */ arr[i]; });
>> }
>>
>> vs
>>
>> for (let i = 0; i < arr.length; ++i) {
>>   f(function () { /* Do something with */ arr[i]; });
>> }
>>
>> Yes, linters got pretty good at finding uses of closed-over variables
>> modified in a loop, but the workarounds were not ideal.
>>
>> var i;
>> for (i = 0; i < arr.length; ++i) {
>>   f(function (i) { return function () { /* Do something with */ arr[i]; }
>> }(i));
>> }
>>
>> Block scoping is just better for code that uses loops, variables, and
>> function expressions.
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Sebastian Malton]

Sorry if I missed a message but would such an initialization be only available 
in the first `if` block or also in the subsequent `else if` and `else` blocks?

Sebastian Malton


  Original Message  
From: isiahmead...@gmail.com
Sent: March 21, 2018 6:18 PM
To: mikesam...@gmail.com
Cc: sebast...@malton.name; es-discuss@mozilla.org
Subject: Re: Proposal: if variable initialization

I'm personally very much *for* this `if (var ...; cond) { ... }`
syntax. I couldn't tell you how many times I would've liked something
to that effect, since that's probably one of my biggest areas of
boilerplate.

I would also be in favor of `if (var ...) { ... }` as a shorthand that
guards `!= null` the expression result (pre-match), since that's about
90% of my use cases for it. There *is* a potential area of ambiguity
in sloppy for `if ( let [ x ] = y )`, since that would be currently
parsed as `var tmp = y; let[x] = tmp; if (tmp) { ... }`, but I doubt
breaking that would be of much web compat risk. (A similar ambiguity
existed with `for (let [`, but that break didn't cause many issues.)
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Mar 21, 2018 at 2:47 PM, Mike Samuel  wrote:
>
>
> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton 
> wrote:
>>
>> Because block-level scoping is a very good way to avoid certain bugs and
>> is easier to reason about. Especially when considering project successors.
>
>
> +1.  function-scoped variables in loop bodies caused tons of bugs before
> let-scoped variables and were a main motivating case.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
>
> vs
>
> for (let i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
>
> Yes, linters got pretty good at finding uses of closed-over variables
> modified in a loop, but the workarounds were not ideal.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function (i) { return function () { /* Do something with */ arr[i]; }
> }(i));
> }
>
> Block scoping is just better for code that uses loops, variables, and
> function expressions.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Isiah Meadows]

I'm personally very much *for* this `if (var ...; cond) { ... }`
syntax. I couldn't tell you how many times I would've liked something
to that effect, since that's probably one of my biggest areas of
boilerplate.

I would also be in favor of `if (var ...) { ... }` as a shorthand that
guards `!= null` the expression result (pre-match), since that's about
90% of my use cases for it. There *is* a potential area of ambiguity
in sloppy for `if ( let [ x ] = y )`, since that would be currently
parsed as `var tmp = y; let[x] = tmp; if (tmp) { ... }`, but I doubt
breaking that would be of much web compat risk. (A similar ambiguity
existed with `for (let [`, but that break didn't cause many issues.)
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Mar 21, 2018 at 2:47 PM, Mike Samuel  wrote:
>
>
> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton 
> wrote:
>>
>> Because block-level scoping is a very good way to avoid certain bugs and
>> is easier to reason about. Especially when considering project successors.
>
>
> +1.  function-scoped variables in loop bodies caused tons of bugs before
> let-scoped variables and were a main motivating case.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
>
> vs
>
> for (let i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
>
> Yes, linters got pretty good at finding uses of closed-over variables
> modified in a loop, but the workarounds were not ideal.
>
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function (i) { return function () { /* Do something with */ arr[i]; }
> }(i));
> }
>
> Block scoping is just better for code that uses loops, variables, and
> function expressions.
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Operator for Currying

[Isiah Meadows]

Look here: https://github.com/tc39/proposal-pipeline-operator/#related-proposals
One of the links points to a partial application operator, and
alternative proposals in that repo are being actively discussed which
don't require partial application. So similar stuff have already been
considered, and currying has come up more than once.

My personal argument for curried functions in the spec is that 1. it's
generally useful in many contexts, and 2. the engine can better
optimize the hell out of it, not having to enter a full function +
code context just to return a lightweight closure. (For similar
reasons, I've in the past railed engines, in particular V8, for not
properly optimizing `Function.prototype.bind`. The call sequence is
brain-dead easy to optimize, and there's no good reason for it to be
slower than a function expression.)
-

Isiah Meadows
m...@isiahmeadows.com

Looking for web consulting? Or a new website?
Send me an email and we can get started.
www.isiahmeadows.com


On Wed, Mar 21, 2018 at 3:43 PM, Vikash Agrawal
 wrote:
> Hi everyone,
>
> I was going through the archives and found that some time ago, there had
> been discussions around currying
> [https://esdiscuss.org/topic/curried-functions] and wanted to know if there
> was any proposal for the same or how did the discussion go?
>
> I feel as we are proceeding with |> the pipeline operator, we should also
> discuss the potential of a currying operator and find out if this would be
> helpful.
>
> Regards
> ~Vikash
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Yank Named and Assigned Functions

[Ben Newman]

You seem to be assuming CommonJS semantics (require, exports, module),
which was never part of the ECMAScript specification.

Instead, ECMAScript has exactly the syntax you're looking for:

```js
export function fnName() {...}
fnName();
```

P.S. We say "hoisted" rather than "yanked" these days. In fact, I've never
heard of yanking before.

Ben

His errors are volitional and are the portals of discovery.
-- James Joyce

On Wed, Mar 21, 2018 at 5:54 PM, Sebastian Malton 
wrote:

> So function definitions are currently yanked to the top. This includes
> named functions.
>
> However if a function is set to a variable, even if it is named, it is not
> yanked. Nor is the name exposed. My suggestion is that it is.
>
> Namely, currently the following errors:
> ```js
> module.exports.fnName2 = function fnName (){...}
>
> fnName()
> ```
>
> But I propose that it would not. Currently this can be gotten around by
> making it two lines, one to define the function and another to export it
> but that seems clunky
>
> Sebastian Malton
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Yank Named and Assigned Functions

[Sebastian Malton]

 So function definitions are currently yanked to the top. This includes named functions.However if a function is set to a variable, even if it is named, it is not yanked. Nor is the name exposed. My suggestion is that it is.Namely, currently the following errors:```jsmodule.exports.fnName2 = function fnName (){...}fnName()```   But I propose that it would not. Currently this can be gotten around by making it two lines, one to define the function and another to export it but that seems clunky  Sebastian Malton  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[kai zhu]

@mike yes that’s true, but issues with blocking-code javascript 
data-structures/algorithms are rarely the reason web-projects fail.  they fail 
largely due to unresolvable integration-level io/workflow issues (that are 
unique only to javascript).  block-scoping fixes the insignificant former, 
while exacerbating the more pressing latter, by encouraging people to pollute 
variable-declarations all-over-the-place; making it harder to discern-and-debug 
which ones are critical io-related closure-variables and which ones are not.

data-structure and algorithmic coding-skills are rarely all that useful in 
javascript (just throw sqlite3 at it and it will likely go away).  
integration-level debugging-skills (and knowledge of which coding 
design-patterns to employ to make io easier to debug) are far more valuable and 
correlable to successfully shipping a web-project.

> On Mar 22, 2018, at 3:47 AM, Mike Samuel  wrote:
> 
> 
> 
> On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton  > wrote:
> Because block-level scoping is a very good way to avoid certain bugs and is 
> easier to reason about. Especially when considering project successors. 
> 
> +1.  function-scoped variables in loop bodies caused tons of bugs before 
> let-scoped variables and were a main motivating case.
> 
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
> 
> vs
> 
> for (let i = 0; i < arr.length; ++i) {
>   f(function () { /* Do something with */ arr[i]; });
> }
> 
> Yes, linters got pretty good at finding uses of closed-over variables 
> modified in a loop, but the workarounds were not ideal.
> 
> var i;
> for (i = 0; i < arr.length; ++i) {
>   f(function (i) { return function () { /* Do something with */ arr[i]; } 
> }(i));
> }
> 
> Block scoping is just better for code that uses loops, variables, and 
> function expressions.
> 

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Operator for Currying

[Vikash Agrawal]

Hi everyone,

I was going through the archives and found that some time ago, there had
been discussions around currying [
https://esdiscuss.org/topic/curried-functions] and wanted to know if there
was any proposal for the same or how did the discussion go?

I feel as we are proceeding with |> the pipeline operator, we should also
discuss the potential of a currying operator and find out if this would be
helpful.

Regards
~Vikash
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

TIL

On Wed, Mar 21, 2018 at 2:29 PM, kai zhu  wrote:

> /*jslint
>
stupid: true
>
*/
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

On Wed, Mar 21, 2018 at 1:27 PM, Sebastian Malton 
wrote:

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

+1.  function-scoped variables in loop bodies caused tons of bugs before
let-scoped variables and were a main motivating case.

var i;
for (i = 0; i < arr.length; ++i) {
  f(function () { /* Do something with */ arr[i]; });
}

vs

for (let i = 0; i < arr.length; ++i) {
  f(function () { /* Do something with */ arr[i]; });
}

Yes, linters got pretty good at finding uses of closed-over variables
modified in a loop, but the workarounds were not ideal.

var i;
for (i = 0; i < arr.length; ++i) {
  f(function (i) { return function () { /* Do something with */ arr[i]; }
}(i));
}

Block scoping is just better for code that uses loops, variables, and
function expressions.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[kai zhu]

i'm not trolling. unlike javascript, most other languages deal near exclusively 
with blocking-code, which is only applicable to low-level library-code in 
javascript (that pretty much anyone can write).  at higher-level 
integration-stuff dealing with non-blocking io, these blocking-code 
design-patterns from other languages are pretty-much useless.  like say … 
*block-level scoping*, because it doesn’t mix well with closures, which are 
heavily used in integration-level javascript to keep track of states for 
non-blocking code.

e.g.
```
/*jslint
bitwise: true,
browser: true,
maxerr: 8,
maxlen: 200,
node: true,
nomen: true,
regexp: true,
stupid: true
*/
(function () {
'use strict';

var chunkList, request, response, timerTimeout;
chunkList = [];
// auto-timeout and cleanup closure-vars request and response after 3 ms
timerTimeout = setTimeout(function () {
try {
request.destroy();
} catch (ignore) {
}
try {
response.destroy();
} catch (ignore) {
}
console.error('timeout error after 3 ms');
}, 3);
request = require('https').request(
require('url').parse('https://www.example.com'),
function (_response) {
response = _response;
response.on('data', function (chunk) {
// append chunk to closure-var chunkList
chunkList.push(chunk);
});
response.on('end', function () {
// print closure-var chunkList to stdout
console.log(Buffer.concat(chunkList).toString());
// cancel closure-var timerTimeout,
// after request successfully completes
clearTimeout(timerTimeout);
});
}
);
request.end();



/*
output:




Example Domain
...




Example Domain
This domain is established to be used for illustrative examples in 
documents. You may use this
domain in examples without prior coordination or asking for permission.
http://www.iana.org/domains/example;>More information...



*/
}());
```

> On Mar 22, 2018, at 2:31 AM, Christopher Thorn  wrote:
> 
> This is just trolling that seems intended to derail the discussion.
> 
> On Wed, Mar 21, 2018 at 10:21 AM, kai zhu  > wrote:
> 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 > > wrote:
>> 
>> 
>> 
>> On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo > > wrote:
>> My 

Re: Proposal: if variable initialization

[Jerry Schulteis]

 I have used the desugared version and found that what seemed obvious to me, 
that the purpose of the block was to limit the scope, was not obvious to other 
developers on  my team.
If this proposal moves forward I think it should include switch and while in 
addition to if.


On Wednesday, March 21, 2018, 11:56:08 AM CDT, Mike Samuel 
 wrote:  
 [...]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?

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

[...]
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
  ___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Christopher Thorn]

This is just trolling that seems intended to derail the discussion.

On Wed, Mar 21, 2018 at 10:21 AM, kai zhu  wrote:

> 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  wrote:
>
>
>
> On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo  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) {
>   ...

Re: Proposal: if variable initialization

[Sebastian Malton]

  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 blockSebastian MaltonFrom: kaizhu...@gmail.comSent: March 21, 2018 1:21 PMTo: mikesam...@gmail.comCc: es-discuss@mozilla.orgSubject: 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  wrote:On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo  wrote:My proposal is to keep it simple and implement the if-assignment `if(const o = ...; ! o ) { ... }` mimicking the `for(;;)` assignmentbehavior.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 odditiesas the variable transitions from lvalue to comparison operand. Thisalready 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 whileavoiding the asymmetric behavior caused by assigning and comparing inone 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", 

Re: Proposal: if variable initialization

[kai zhu]

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  wrote:
> 
> 
> 
> On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo  > 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?
>  
> 
> Current   Proposed
>   {
>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 

Re: Proposal: if variable initialization

[Mike Samuel]

On Wed, Mar 21, 2018 at 11:02 AM, Rodrigo  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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Rodrigo]

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  wrote:
>
>
> On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo  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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Mike Samuel]

On Tue, Mar 20, 2018 at 3:57 PM, Rodrigo  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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Add "???" Unimplemented

[Augusto Moura]

I think it can be easily implemented with decorators (
https://github.com/tc39/proposal-decorators).
Something like `@unimplemented`.

In my opinion it doesn't offer enough benefits to be added as a new syntax.

Em qua, 21 de mar de 2018 às 04:02, Naveen Chawla 
escreveu:

> Can you give a simple example?
>
> On Wed, 21 Mar 2018 at 00:44 dante federici 
> wrote:
>
>> With the advent of TypeScript, classes, etc one feature I liked from
>> scala is: `???`, the [Predef.???](
>> https://www.scala-lang.org/api/current/scala/NotImplementedError.html)
>> token.
>>
>> Basically, you can place `???` which would type as whatever the method is
>> typed as (for things like Typescript, Symbol definitions, etc.), and when
>> run, throws the "NotImplementedError".
>>
>> This is useful when writing libraries or other code -- more readable that
>> "cannot call undefined" when the method is missing, and a nice placeholder
>> for young APIs.
>>
>> This is basically the same as writing: `throw new Error('Unimplemented')`.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-- 
Augusto Moura
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[kai zhu]

@thomas, no.  i'm serious in my opinion that let and const were mistakes.

-kai

> On Mar 21, 2018, at 9:01 PM, Thomas Grainger  wrote:
> 
> Is this sarcastic?
> 
> On 21 Mar 2018 12:58, "kai zhu"  > wrote:
> this is why let and const should *never* have been introduced.  if we had 
> stuck with just var, none of these petty-arguments and bickering among 
> team-members/shops on scoping-styles that ultimately have *zero* productivity 
> or benefit to web-projects would be possible.
> 
> and there's nothing wrong with pre-declaring all variables at the top-level 
> of a function (which is an es5 best-practice that’s still valid today), 
> regardless whether some are only used in conditional-blocks or not, like this 
> real-world example [1]:
> 
> ```
> local.validateBySwaggerSchema = function (options) {
> /*
>  * this function will validate data against schema
>  * http://json-schema.org/draft-04/json-schema-validation.html#rfc.section.5 
> 
>  */
> var $ref,
> circularList,
> data,
> dataReadonlyRemove2,
> ii,
> oneOf,
> schema,
> test,
> tmp;
> ...
> // dereference schema.$ref
> $ref = schema && schema.$ref;
> if (!$ref) {
> break;
> }
> ...
> tmp = typeof data;
> if (tmp === 'object' && Array.isArray(data)) {
> tmp = 'array';
> }
> ...
> if (schema === local.swaggerSchemaJson.definitions.jsonReference) {
> ...
> }
> ...
> };
> ```
> 
> [1] https://github.com/kaizhu256/node-swgg/blob/2018.2.1/lib.swgg.js#L4076 
> 
> 
> -kai
> 
>> On Mar 21, 2018, at 7:15 PM, Jordan Harband > > wrote:
>> 
>> ```
>> if (someComplicatedCondition()) {
>>   doSomeLogic();
>>   doSomeOtherLogic(if.value, true);
>> }
>> ```
>> 
>> On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo > > wrote:
>> Here are my gripes with `let` and `const` returning values:
>> 
>> 1) declaration lists are hard to read:
>> 
>> if ((let x = 10, y = 20) > 15) {
>> // true, but what's being compared here? 10 or 20? (answer: 20)
>> }
>> 
>> Although right now this is allowed and the last element is compared:
>> 
>> if ((x = 10, y = 20) > 15) {
>> // result is true, 20 > 15
>> }
>> 
>> 2) Destructuring assignments are also confusing, what's being compared here?
>> 
>> if(let [x,y] = [1,2]) {
>> }
>> 
>> Again, this is allowed as of today:
>> 
>> if([x,y] = [1,2]) {
>> // true, as it returns [1,2]
>> }
>> 
>> 3) Nesting `let/const` would be either expected everywhere (not only
>> in the `if`) or a possible side effect from the implementation.
>> Similar to languages such as Perl.
>> 
>> let x = foo(let y = 100, z = 200);  // what's the scope of x and z?
>> 
>> This leads to hard to read and very confusing code golf.
>> 
>> That's why Golang went with something simple,
>> `if([declaration];[conditional])`, and avoided confusion over `:=`
>> assignments returning values anywhere in the code. `x:=( y:= 20 )` is
>> not allowed in Go.
>> 
>> It expands on the 45-year tried-and-true structure of `for(;;)` to
>> create `if(;)` and keep the ES language simple and clear expanding on
>> its own concept of `for(;;)`.
>> 
>> On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla > > wrote:
>> > OK I neglected to read the original post fully. My last post example would
>> > be based on allowing `const` and `let` declarations to expressions in of
>> > themselves (in the case of multi variables, returning the last one). So let
>> > me ask, what exactly would be the problem with this?
>> >
>> > On Wed, 21 Mar 2018 at 12:20 Naveen Chawla > > > wrote:
>> >>
>> >> What would `if.value` look like in an example?
>> >>
>> >> Wouldn't it be possible to have something like `if(const x = getX() &&
>> >> const y = getY())` to capture more than just the conditional if required?
>> >> I'm guessing that would probably break something somewhere, but I'm not 
>> >> sure
>> >> what.
>> >>
>> >> On Wed, 21 Mar 2018 at 04:35 Jordan Harband > >> > wrote:
>> >>>
>> >>> Is the use case only ever to capture the thing that serves as the
>> >>> conditional?
>> >>>
>> >>> If so, would perhaps something like `if.value` work better? Since it's a
>> >>> keyword, it could be made to only work in the `if` block, and you 
>> >>> wouldn't
>> >>> need any of that odd multi-statement stuff in the conditional parens.
>> >>>
>> >>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo > >>> > wrote:
>> 
>>  

Re: Proposal: if variable initialization

[Thomas Grainger]

Is this sarcastic?

On 21 Mar 2018 12:58, "kai zhu"  wrote:

> this is why let and const should *never* have been introduced.  if we had
> stuck with just var, none of these petty-arguments and bickering among
> team-members/shops on scoping-styles that ultimately have *zero*
> productivity or benefit to web-projects would be possible.
>
> and there's nothing wrong with pre-declaring all variables at the
> top-level of a function (which is an es5 best-practice that’s still valid
> today), regardless whether some are only used in conditional-blocks or not,
> like this real-world example [1]:
>
> ```
> local.validateBySwaggerSchema = function (options) {
> /*
>  * this function will validate data against schema
>  * http://json-schema.org/draft-04/json-schema-validation.
> html#rfc.section.5
>  */
> var $ref,
> circularList,
> data,
> dataReadonlyRemove2,
> ii,
> oneOf,
> schema,
> test,
> tmp;
> ...
> // dereference schema.$ref
> $ref = schema && schema.$ref;
> if (!$ref) {
> break;
> }
> ...
> tmp = typeof data;
> if (tmp === 'object' && Array.isArray(data)) {
> tmp = 'array';
> }
> ...
> if (schema === local.swaggerSchemaJson.definitions.jsonReference) {
> ...
> }
> ...
> };
> ```
>
> [1] https://github.com/kaizhu256/node-swgg/blob/2018.2.1/lib.swgg.js#L4076
>
> -kai
>
> On Mar 21, 2018, at 7:15 PM, Jordan Harband  wrote:
>
> ```
> if (someComplicatedCondition()) {
>   doSomeLogic();
>   doSomeOtherLogic(if.value, true);
> }
> ```
>
> On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo  wrote:
>
>> Here are my gripes with `let` and `const` returning values:
>>
>> 1) declaration lists are hard to read:
>>
>> if ((let x = 10, y = 20) > 15) {
>> // true, but what's being compared here? 10 or 20? (answer: 20)
>> }
>>
>> Although right now this is allowed and the last element is compared:
>>
>> if ((x = 10, y = 20) > 15) {
>> // result is true, 20 > 15
>> }
>>
>> 2) Destructuring assignments are also confusing, what's being compared
>> here?
>>
>> if(let [x,y] = [1,2]) {
>> }
>>
>> Again, this is allowed as of today:
>>
>> if([x,y] = [1,2]) {
>> // true, as it returns [1,2]
>> }
>>
>> 3) Nesting `let/const` would be either expected everywhere (not only
>> in the `if`) or a possible side effect from the implementation.
>> Similar to languages such as Perl.
>>
>> let x = foo(let y = 100, z = 200);  // what's the scope of x and z?
>>
>> This leads to hard to read and very confusing code golf.
>>
>> That's why Golang went with something simple,
>> `if([declaration];[conditional])`, and avoided confusion over `:=`
>> assignments returning values anywhere in the code. `x:=( y:= 20 )` is
>> not allowed in Go.
>>
>> It expands on the 45-year tried-and-true structure of `for(;;)` to
>> create `if(;)` and keep the ES language simple and clear expanding on
>> its own concept of `for(;;)`.
>>
>> On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla 
>> wrote:
>> > OK I neglected to read the original post fully. My last post example
>> would
>> > be based on allowing `const` and `let` declarations to expressions in of
>> > themselves (in the case of multi variables, returning the last one). So
>> let
>> > me ask, what exactly would be the problem with this?
>> >
>> > On Wed, 21 Mar 2018 at 12:20 Naveen Chawla 
>> wrote:
>> >>
>> >> What would `if.value` look like in an example?
>> >>
>> >> Wouldn't it be possible to have something like `if(const x = getX() &&
>> >> const y = getY())` to capture more than just the conditional if
>> required?
>> >> I'm guessing that would probably break something somewhere, but I'm
>> not sure
>> >> what.
>> >>
>> >> On Wed, 21 Mar 2018 at 04:35 Jordan Harband  wrote:
>> >>>
>> >>> Is the use case only ever to capture the thing that serves as the
>> >>> conditional?
>> >>>
>> >>> If so, would perhaps something like `if.value` work better? Since
>> it's a
>> >>> keyword, it could be made to only work in the `if` block, and you
>> wouldn't
>> >>> need any of that odd multi-statement stuff in the conditional parens.
>> >>>
>> >>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo 
>> 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.
>> 
>>  Reason: limits variable scope to the block where really needed, in
>>  similar fashion to variables defined in for(;;) statements. This
>>  improves readability while reducing unnecessary variables roaming
>>  outside their needed block.
>> 
>>  The syntax would be very similar to the for(;;) assignment/test pair:
>> 
>>  if (let x = 100; x > 50) 

Re: Proposal: if variable initialization

[kai zhu]

this is why let and const should *never* have been introduced.  if we had stuck 
with just var, none of these petty-arguments and bickering among 
team-members/shops on scoping-styles that ultimately have *zero* productivity 
or benefit to web-projects would be possible.

and there's nothing wrong with pre-declaring all variables at the top-level of 
a function (which is an es5 best-practice that’s still valid today), regardless 
whether some are only used in conditional-blocks or not, like this real-world 
example [1]:

```
local.validateBySwaggerSchema = function (options) {
/*
 * this function will validate data against schema
 * http://json-schema.org/draft-04/json-schema-validation.html#rfc.section.5
 */
var $ref,
circularList,
data,
dataReadonlyRemove2,
ii,
oneOf,
schema,
test,
tmp;
...
// dereference schema.$ref
$ref = schema && schema.$ref;
if (!$ref) {
break;
}
...
tmp = typeof data;
if (tmp === 'object' && Array.isArray(data)) {
tmp = 'array';
}
...
if (schema === local.swaggerSchemaJson.definitions.jsonReference) {
...
}
...
};
```

[1] https://github.com/kaizhu256/node-swgg/blob/2018.2.1/lib.swgg.js#L4076 


-kai

> On Mar 21, 2018, at 7:15 PM, Jordan Harband  wrote:
> 
> ```
> if (someComplicatedCondition()) {
>   doSomeLogic();
>   doSomeOtherLogic(if.value, true);
> }
> ```
> 
> On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo  > wrote:
> Here are my gripes with `let` and `const` returning values:
> 
> 1) declaration lists are hard to read:
> 
> if ((let x = 10, y = 20) > 15) {
> // true, but what's being compared here? 10 or 20? (answer: 20)
> }
> 
> Although right now this is allowed and the last element is compared:
> 
> if ((x = 10, y = 20) > 15) {
> // result is true, 20 > 15
> }
> 
> 2) Destructuring assignments are also confusing, what's being compared here?
> 
> if(let [x,y] = [1,2]) {
> }
> 
> Again, this is allowed as of today:
> 
> if([x,y] = [1,2]) {
> // true, as it returns [1,2]
> }
> 
> 3) Nesting `let/const` would be either expected everywhere (not only
> in the `if`) or a possible side effect from the implementation.
> Similar to languages such as Perl.
> 
> let x = foo(let y = 100, z = 200);  // what's the scope of x and z?
> 
> This leads to hard to read and very confusing code golf.
> 
> That's why Golang went with something simple,
> `if([declaration];[conditional])`, and avoided confusion over `:=`
> assignments returning values anywhere in the code. `x:=( y:= 20 )` is
> not allowed in Go.
> 
> It expands on the 45-year tried-and-true structure of `for(;;)` to
> create `if(;)` and keep the ES language simple and clear expanding on
> its own concept of `for(;;)`.
> 
> On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla  > wrote:
> > OK I neglected to read the original post fully. My last post example would
> > be based on allowing `const` and `let` declarations to expressions in of
> > themselves (in the case of multi variables, returning the last one). So let
> > me ask, what exactly would be the problem with this?
> >
> > On Wed, 21 Mar 2018 at 12:20 Naveen Chawla  > > wrote:
> >>
> >> What would `if.value` look like in an example?
> >>
> >> Wouldn't it be possible to have something like `if(const x = getX() &&
> >> const y = getY())` to capture more than just the conditional if required?
> >> I'm guessing that would probably break something somewhere, but I'm not 
> >> sure
> >> what.
> >>
> >> On Wed, 21 Mar 2018 at 04:35 Jordan Harband  >> > wrote:
> >>>
> >>> Is the use case only ever to capture the thing that serves as the
> >>> conditional?
> >>>
> >>> If so, would perhaps something like `if.value` work better? Since it's a
> >>> keyword, it could be made to only work in the `if` block, and you wouldn't
> >>> need any of that odd multi-statement stuff in the conditional parens.
> >>>
> >>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo  >>> > 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.
> 
>  Reason: limits variable scope to the block where really needed, in
>  similar fashion to variables defined in for(;;) statements. This
>  improves readability while reducing unnecessary variables roaming
>  outside their needed block.
> 
>  The syntax would be very similar to the for(;;) assignment/test pair:
> 
>  if (let x = 100; x > 50) {
>    

Re: Proposal: if variable initialization

[Jordan Harband]

```
if (someComplicatedCondition()) {
  doSomeLogic();
  doSomeOtherLogic(if.value, true);
}
```

On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo  wrote:

> Here are my gripes with `let` and `const` returning values:
>
> 1) declaration lists are hard to read:
>
> if ((let x = 10, y = 20) > 15) {
> // true, but what's being compared here? 10 or 20? (answer: 20)
> }
>
> Although right now this is allowed and the last element is compared:
>
> if ((x = 10, y = 20) > 15) {
> // result is true, 20 > 15
> }
>
> 2) Destructuring assignments are also confusing, what's being compared
> here?
>
> if(let [x,y] = [1,2]) {
> }
>
> Again, this is allowed as of today:
>
> if([x,y] = [1,2]) {
> // true, as it returns [1,2]
> }
>
> 3) Nesting `let/const` would be either expected everywhere (not only
> in the `if`) or a possible side effect from the implementation.
> Similar to languages such as Perl.
>
> let x = foo(let y = 100, z = 200);  // what's the scope of x and z?
>
> This leads to hard to read and very confusing code golf.
>
> That's why Golang went with something simple,
> `if([declaration];[conditional])`, and avoided confusion over `:=`
> assignments returning values anywhere in the code. `x:=( y:= 20 )` is
> not allowed in Go.
>
> It expands on the 45-year tried-and-true structure of `for(;;)` to
> create `if(;)` and keep the ES language simple and clear expanding on
> its own concept of `for(;;)`.
>
> On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla 
> wrote:
> > OK I neglected to read the original post fully. My last post example
> would
> > be based on allowing `const` and `let` declarations to expressions in of
> > themselves (in the case of multi variables, returning the last one). So
> let
> > me ask, what exactly would be the problem with this?
> >
> > On Wed, 21 Mar 2018 at 12:20 Naveen Chawla 
> wrote:
> >>
> >> What would `if.value` look like in an example?
> >>
> >> Wouldn't it be possible to have something like `if(const x = getX() &&
> >> const y = getY())` to capture more than just the conditional if
> required?
> >> I'm guessing that would probably break something somewhere, but I'm not
> sure
> >> what.
> >>
> >> On Wed, 21 Mar 2018 at 04:35 Jordan Harband  wrote:
> >>>
> >>> Is the use case only ever to capture the thing that serves as the
> >>> conditional?
> >>>
> >>> If so, would perhaps something like `if.value` work better? Since it's
> a
> >>> keyword, it could be made to only work in the `if` block, and you
> wouldn't
> >>> need any of that odd multi-statement stuff in the conditional parens.
> >>>
> >>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo 
> 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.
> 
>  Reason: limits variable scope to the block where really needed, in
>  similar fashion to variables defined in for(;;) statements. This
>  improves readability while reducing unnecessary variables roaming
>  outside their needed block.
> 
>  The syntax would be very similar to the for(;;) assignment/test pair:
> 
>  if (let x = 100; x > 50) {
>  console.log(x); // 100
>  }
>  console.log(x); // ReferenceError
> 
>  // same for const
>  if( const x = foo(); typeof x === 'object' ) {
>  //...
>  }
> 
>  // the variable is available within any else block
>  // after its declaration
>  if (let x = foo(); x < 50) {
>  console.log(x);  // y is not available here
>  } else if (let y = bar(); y > 0) {
>  console.log(x, y);
>  } else {
>  console.log(x, y);
>  }
> 
>  Right now there isn't a way to limit a variable to the if block:
> 
>  let x = 100;
>  if (x > 50) {
>  console.log(x);
>  }
>  // x is in scope, but may not be needed beyond the if statement
>  console.log(x);
> 
>  // or a non-strict assignment, which also "leaks" scope
>  if( (x = 100) > 50 ) {
>  // ...
>  }
> 
>  There are many "workarounds" available, here's a few:
> 
>  // workaround 1: can be remedied with a scope block
>  // but it's asymmetrical and non-idiomatic
>  {
>  let x = 100;
>  if (x > 50) {
>  console.log(x);
>  }
>  }
> 
>  // workaround 2: with a for statement
>  // but this is non-idiomatic, hard to read and error-prone
>  for (let x = 100; x > 50;) {
>  console.log(x);
>  break;
>  }
> 
>  If-initialization is available in many languages (Go, Perl 

Re: Big integer, Big float, and operator overloading ideas

[David Teller]

That proposal is quite interesting, but I'm a bit scared about potential
for breakage. Maybe Integer/Float values should be introduced only in
your "use math" mode? Would that be sufficient?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Rodrigo]

Here are my gripes with `let` and `const` returning values:

1) declaration lists are hard to read:

if ((let x = 10, y = 20) > 15) {
// true, but what's being compared here? 10 or 20? (answer: 20)
}

Although right now this is allowed and the last element is compared:

if ((x = 10, y = 20) > 15) {
// result is true, 20 > 15
}

2) Destructuring assignments are also confusing, what's being compared here?

if(let [x,y] = [1,2]) {
}

Again, this is allowed as of today:

if([x,y] = [1,2]) {
// true, as it returns [1,2]
}

3) Nesting `let/const` would be either expected everywhere (not only
in the `if`) or a possible side effect from the implementation.
Similar to languages such as Perl.

let x = foo(let y = 100, z = 200);  // what's the scope of x and z?

This leads to hard to read and very confusing code golf.

That's why Golang went with something simple,
`if([declaration];[conditional])`, and avoided confusion over `:=`
assignments returning values anywhere in the code. `x:=( y:= 20 )` is
not allowed in Go.

It expands on the 45-year tried-and-true structure of `for(;;)` to
create `if(;)` and keep the ES language simple and clear expanding on
its own concept of `for(;;)`.

On Wed, Mar 21, 2018 at 7:57 AM, Naveen Chawla  wrote:
> OK I neglected to read the original post fully. My last post example would
> be based on allowing `const` and `let` declarations to expressions in of
> themselves (in the case of multi variables, returning the last one). So let
> me ask, what exactly would be the problem with this?
>
> On Wed, 21 Mar 2018 at 12:20 Naveen Chawla  wrote:
>>
>> What would `if.value` look like in an example?
>>
>> Wouldn't it be possible to have something like `if(const x = getX() &&
>> const y = getY())` to capture more than just the conditional if required?
>> I'm guessing that would probably break something somewhere, but I'm not sure
>> what.
>>
>> On Wed, 21 Mar 2018 at 04:35 Jordan Harband  wrote:
>>>
>>> Is the use case only ever to capture the thing that serves as the
>>> conditional?
>>>
>>> If so, would perhaps something like `if.value` work better? Since it's a
>>> keyword, it could be made to only work in the `if` block, and you wouldn't
>>> need any of that odd multi-statement stuff in the conditional parens.
>>>
>>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo  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.

 Reason: limits variable scope to the block where really needed, in
 similar fashion to variables defined in for(;;) statements. This
 improves readability while reducing unnecessary variables roaming
 outside their needed block.

 The syntax would be very similar to the for(;;) assignment/test pair:

 if (let x = 100; x > 50) {
 console.log(x); // 100
 }
 console.log(x); // ReferenceError

 // same for const
 if( const x = foo(); typeof x === 'object' ) {
 //...
 }

 // the variable is available within any else block
 // after its declaration
 if (let x = foo(); x < 50) {
 console.log(x);  // y is not available here
 } else if (let y = bar(); y > 0) {
 console.log(x, y);
 } else {
 console.log(x, y);
 }

 Right now there isn't a way to limit a variable to the if block:

 let x = 100;
 if (x > 50) {
 console.log(x);
 }
 // x is in scope, but may not be needed beyond the if statement
 console.log(x);

 // or a non-strict assignment, which also "leaks" scope
 if( (x = 100) > 50 ) {
 // ...
 }

 There are many "workarounds" available, here's a few:

 // workaround 1: can be remedied with a scope block
 // but it's asymmetrical and non-idiomatic
 {
 let x = 100;
 if (x > 50) {
 console.log(x);
 }
 }

 // workaround 2: with a for statement
 // but this is non-idiomatic, hard to read and error-prone
 for (let x = 100; x > 50;) {
 console.log(x);
 break;
 }

 If-initialization is available in many languages (Go, Perl and Ruby
 come to mind) and are considered best practice in each one of them:

 // Golang - x is defined, assigned and conditionally tested
 if x := 100; x > 50 {
 // x is in scope here
 } else {
 // and in here
 }
 // x is not available here

 ## Perl
 if( my $x = 100 ) {
 print $x;
 }
 print $x; # an error

Re: Re: Function composition vs pipeline

[Terence M. Bandoian]

That's very true.  However, every new feature is an added cost to the 
developer that can't be wished away with a linter.


-Terence Bandoian


On 3/20/2018 6:07 PM, Jordan Harband wrote:
Learning is a continuing requirement with or without new features in 
the language; any one feature *not* added to the language tends to 
mean you'll have to learn about more than one userland solution to 
that problem. Obviously there's a cost to adding anything to the 
language - but there's a cost to *not* adding things too - and in no 
case are you afforded the luxury of "no more learning".


On Tue, Mar 20, 2018 at 12:23 PM, Terence M. Bandoian 
> wrote:


When "features" are added to the language, developers have to
learn them. Either that or risk being relegated to second class
status.  That means more time learning about and testing and
sorting out support for new features and less time actually
developing an application.  I like the idea of "keeping it
small".  To me, the ideal is a balance of simple and powerful.

-Terence Bandoian



On 3/13/2018 9:59 AM, Mark Miller wrote:



On Mon, Mar 12, 2018 at 11:33 PM, Jordan Harband
> wrote:

As someone who does wear the shoes of a senior programmer
responsible (along with my team) for overseeing a very very
large web project, the super trivial and easy answer to this
is "use a linter" - eslint can be configured to restrict any
syntax you like, and since surely your CI process is already
gating any merges, so too can the linter be used to gate
merges, which will prevent anyone from any using any syntax
you deem unclean.

Tons of new syntax can be added to JavaScript forever and it
need not have a single bit of impact on any of your project's
code except a few lines in your eslint configuration.



Hi Jordan, while I agree with some of your overall point, I think
this goes way too far. The larger the language, and the more
diversity there is in which subset one shop chooses vs another,
the more we loose the benefits of having many developers use a
common language. No one shop writes all the JS they use. They use
libraries written by others whose lint rules are different. They
hire programmers from other shops. They read and post to
stackOverflow, etc.

Much better is for the language to omit as much as possible,
keeping it small. I am glad my "Tragedy of the Common Lisp" post
is so widely cited and appreciated. Later in that thread, at

https://esdiscuss.org/topic/the-tragedy-of-the-common-lisp-or-why-large-languages-explode-was-revive-let-blocks#content-22


I state a hierarchy of different parts of a language with
different pressures towards minimality:


the force of my [minimality] point gets weaker as we move
from core language to standardizing libraries. The overall
standard language can be seen as consisting of these major
parts:

  * fundamental syntax -- the special forms that cannot
faithfully be explained by local expansion to other syntax

  * semantic state -- the state than computation manipulates

  * kernel builtins -- built in library providing
functionality that, if it were absent, could not be
provided instead by user code.

  * intrinsics -- libraries that semantic state or kernel
builtins depend on. For example, with Proxies, one might
be able to do Array in user code. But other kernel
builtins already have a dependency on Array specifically,
giving it a privileged position over any replacement.

  * syntactic sugar -- the syntax that can be explained by
local expansion to fundamental syntax.

  * global convenience libraries -- could be implemented by
unprivileged user code, but given standard global naming
paths in the primordial global namespace.

  * standard convenient library modules

I have listed these in order, according to my sense of the
costs of growth and the urgency for minimalism. For all of
these we still need to exercise discipline. But it is only
for the last one that we should consider growth of absolute
size to be unbounded; restricting ourselves only to the rate
of growth as we wait for candidates to prove themselves first
by the de facto process. Ideally, TC39 should stop being the
bottleneck on the last bullet anyway, as external de facto
and de jure processes should be perfectly capable of
independently arguing about and evolving standard convenience

Re: Add "???" Unimplemented

[Naveen Chawla]

Can you give a simple example?

On Wed, 21 Mar 2018 at 00:44 dante federici 
wrote:

> With the advent of TypeScript, classes, etc one feature I liked from scala
> is: `???`, the [Predef.???](
> https://www.scala-lang.org/api/current/scala/NotImplementedError.html)
> token.
>
> Basically, you can place `???` which would type as whatever the method is
> typed as (for things like Typescript, Symbol definitions, etc.), and when
> run, throws the "NotImplementedError".
>
> This is useful when writing libraries or other code -- more readable that
> "cannot call undefined" when the method is missing, and a nice placeholder
> for young APIs.
>
> This is basically the same as writing: `throw new Error('Unimplemented')`.
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Naveen Chawla]

OK I neglected to read the original post fully. My last post example would
be based on allowing `const` and `let` declarations to expressions in of
themselves (in the case of multi variables, returning the last one). So let
me ask, what exactly would be the problem with this?

On Wed, 21 Mar 2018 at 12:20 Naveen Chawla  wrote:

> What would `if.value` look like in an example?
>
> Wouldn't it be possible to have something like `if(const x = getX() &&
> const y = getY())` to capture more than just the conditional if required?
> I'm guessing that would probably break something somewhere, but I'm not
> sure what.
>
> On Wed, 21 Mar 2018 at 04:35 Jordan Harband  wrote:
>
>> Is the use case only ever to capture the thing that serves as the
>> conditional?
>>
>> If so, would perhaps something like `if.value` work better? Since it's a
>> keyword, it could be made to only work in the `if` block, and you wouldn't
>> need any of that odd multi-statement stuff in the conditional parens.
>>
>> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo  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.
>>>
>>> Reason: limits variable scope to the block where really needed, in
>>> similar fashion to variables defined in for(;;) statements. This
>>> improves readability while reducing unnecessary variables roaming
>>> outside their needed block.
>>>
>>> The syntax would be very similar to the for(;;) assignment/test pair:
>>>
>>> if (let x = 100; x > 50) {
>>> console.log(x); // 100
>>> }
>>> console.log(x); // ReferenceError
>>>
>>> // same for const
>>> if( const x = foo(); typeof x === 'object' ) {
>>> //...
>>> }
>>>
>>> // the variable is available within any else block
>>> // after its declaration
>>> if (let x = foo(); x < 50) {
>>> console.log(x);  // y is not available here
>>> } else if (let y = bar(); y > 0) {
>>> console.log(x, y);
>>> } else {
>>> console.log(x, y);
>>> }
>>>
>>> Right now there isn't a way to limit a variable to the if block:
>>>
>>> let x = 100;
>>> if (x > 50) {
>>> console.log(x);
>>> }
>>> // x is in scope, but may not be needed beyond the if statement
>>> console.log(x);
>>>
>>> // or a non-strict assignment, which also "leaks" scope
>>> if( (x = 100) > 50 ) {
>>> // ...
>>> }
>>>
>>> There are many "workarounds" available, here's a few:
>>>
>>> // workaround 1: can be remedied with a scope block
>>> // but it's asymmetrical and non-idiomatic
>>> {
>>> let x = 100;
>>> if (x > 50) {
>>> console.log(x);
>>> }
>>> }
>>>
>>> // workaround 2: with a for statement
>>> // but this is non-idiomatic, hard to read and error-prone
>>> for (let x = 100; x > 50;) {
>>> console.log(x);
>>> break;
>>> }
>>>
>>> If-initialization is available in many languages (Go, Perl and Ruby
>>> come to mind) and are considered best practice in each one of them:
>>>
>>> // Golang - x is defined, assigned and conditionally tested
>>> if x := 100; x > 50 {
>>> // x is in scope here
>>> } else {
>>> // and in here
>>> }
>>> // x is not available here
>>>
>>> ## Perl
>>> if( my $x = 100 ) {
>>> print $x;
>>> }
>>> print $x; # an error
>>>
>>> if ( ( my $x = myfoo() ) > 50 ) {  # also ok in Perl
>>> print $x;
>>> }
>>>
>>> ## Ruby
>>> if ( x = 100 )  # parens required per style guide
>>> puts(x)
>>> end
>>> puts(x) # unfortunately Ruby does not limit scope to if, so x "leaks"
>>>
>>> I think this would be a great and important addition to the language.
>>>
>>> -Rodrigo
>>>
>>> PS: Just for the sake of comparison, Perl-style if-assignments could
>>> also be an
>>> option, albeit a very bad one IMO:
>>>
>>> if( ( let x = 100 ) > 50 ) {
>>> }
>>>
>>> A Perl-style, value-returning let/const has readability issues, opens
>>> quite a few fronts and sort of implies that let/const can return
>>> values anywhere in the code outside if/else. On the other hand it
>>> would fit with the currently if assignment if( x = y ). Definitely not
>>> recommended.
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Proposal: if variable initialization

[Naveen Chawla]

What would `if.value` look like in an example?

Wouldn't it be possible to have something like `if(const x = getX() &&
const y = getY())` to capture more than just the conditional if required?
I'm guessing that would probably break something somewhere, but I'm not
sure what.

On Wed, 21 Mar 2018 at 04:35 Jordan Harband  wrote:

> Is the use case only ever to capture the thing that serves as the
> conditional?
>
> If so, would perhaps something like `if.value` work better? Since it's a
> keyword, it could be made to only work in the `if` block, and you wouldn't
> need any of that odd multi-statement stuff in the conditional parens.
>
> On Tue, Mar 20, 2018 at 12:57 PM, Rodrigo  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.
>>
>> Reason: limits variable scope to the block where really needed, in
>> similar fashion to variables defined in for(;;) statements. This
>> improves readability while reducing unnecessary variables roaming
>> outside their needed block.
>>
>> The syntax would be very similar to the for(;;) assignment/test pair:
>>
>> if (let x = 100; x > 50) {
>> console.log(x); // 100
>> }
>> console.log(x); // ReferenceError
>>
>> // same for const
>> if( const x = foo(); typeof x === 'object' ) {
>> //...
>> }
>>
>> // the variable is available within any else block
>> // after its declaration
>> if (let x = foo(); x < 50) {
>> console.log(x);  // y is not available here
>> } else if (let y = bar(); y > 0) {
>> console.log(x, y);
>> } else {
>> console.log(x, y);
>> }
>>
>> Right now there isn't a way to limit a variable to the if block:
>>
>> let x = 100;
>> if (x > 50) {
>> console.log(x);
>> }
>> // x is in scope, but may not be needed beyond the if statement
>> console.log(x);
>>
>> // or a non-strict assignment, which also "leaks" scope
>> if( (x = 100) > 50 ) {
>> // ...
>> }
>>
>> There are many "workarounds" available, here's a few:
>>
>> // workaround 1: can be remedied with a scope block
>> // but it's asymmetrical and non-idiomatic
>> {
>> let x = 100;
>> if (x > 50) {
>> console.log(x);
>> }
>> }
>>
>> // workaround 2: with a for statement
>> // but this is non-idiomatic, hard to read and error-prone
>> for (let x = 100; x > 50;) {
>> console.log(x);
>> break;
>> }
>>
>> If-initialization is available in many languages (Go, Perl and Ruby
>> come to mind) and are considered best practice in each one of them:
>>
>> // Golang - x is defined, assigned and conditionally tested
>> if x := 100; x > 50 {
>> // x is in scope here
>> } else {
>> // and in here
>> }
>> // x is not available here
>>
>> ## Perl
>> if( my $x = 100 ) {
>> print $x;
>> }
>> print $x; # an error
>>
>> if ( ( my $x = myfoo() ) > 50 ) {  # also ok in Perl
>> print $x;
>> }
>>
>> ## Ruby
>> if ( x = 100 )  # parens required per style guide
>> puts(x)
>> end
>> puts(x) # unfortunately Ruby does not limit scope to if, so x "leaks"
>>
>> I think this would be a great and important addition to the language.
>>
>> -Rodrigo
>>
>> PS: Just for the sake of comparison, Perl-style if-assignments could also
>> be an
>> option, albeit a very bad one IMO:
>>
>> if( ( let x = 100 ) > 50 ) {
>> }
>>
>> A Perl-style, value-returning let/const has readability issues, opens
>> quite a few fronts and sort of implies that let/const can return
>> values anywhere in the code outside if/else. On the other hand it
>> would fit with the currently if assignment if( x = y ). Definitely not
>> recommended.
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss