@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 <[email protected]> wrote: > > Is this sarcastic? > > On 21 Mar 2018 12:58, "kai zhu" <[email protected] > <mailto:[email protected]>> 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 > <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 > <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 <[email protected] >> <mailto:[email protected]>> wrote: >> >> ``` >> if (someComplicatedCondition()) { >> doSomeLogic(); >> doSomeOtherLogic(if.value, true); >> } >> ``` >> >> On Wed, Mar 21, 2018 at 2:52 AM, Rodrigo <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> > <mailto:[email protected]>> 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 <[email protected] >> >> <mailto:[email protected]>> 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 <[email protected] >> >>> <mailto:[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. >> >>>> >> >>>> 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 >> >>>> [email protected] <mailto:[email protected]> >> >>>> https://mail.mozilla.org/listinfo/es-discuss >> >>>> <https://mail.mozilla.org/listinfo/es-discuss> >> >>> >> >>> >> >>> _______________________________________________ >> >>> es-discuss mailing list >> >>> [email protected] <mailto:[email protected]> >> >>> https://mail.mozilla.org/listinfo/es-discuss >> >>> <https://mail.mozilla.org/listinfo/es-discuss> >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] <mailto:[email protected]> >> https://mail.mozilla.org/listinfo/es-discuss >> <https://mail.mozilla.org/listinfo/es-discuss> > > > _______________________________________________ > es-discuss mailing list > [email protected] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
