Nick Krempel wrote:
Taking it further, a (probably controversial) suggestion would be to
allow "let" and "const" to be expressions, enabling:
```js
if ((let foo = getFoo()).isReady()) {
// foo in scope
} else {
// foo in scope
}
// foo not in scope
```
There would be some details about whether its value is a Reference and
what to do with "let a = 1, b = 2" but probably the biggest issue
would be parsing ambiguities?
Yes, because let is not reserved in ES1-3, or ES5 non-strict, we can't
recognize it in expressions, only at start of statement (and even then
we propose to break any old code of the form let[x] = y; by interpreting
that as a destructuring let binding using a single-element array pattern).
ES4 had let expressions (let (x = y, z = w) ...), but presumed opt-in
versioning, thankfully dead with 1JS and never to return.
Or in a different direction, could consider allowing ToBoolean
conversions for objects to be overloaded.
Best not to overload your proposals, first.
Also, we do not want ToBoolean overloaded on arbitrary objects. Value
objects as I've shown in several talks, e.g.,
http://www.slideshare.net/BrendanEich/js-resp
do allow boolean test to be customized, but only for a value class --
and note that ! and != (and of course ===/!==) cannot be overridden.
Even without either of the two additions proposed above, I would still
find the if/switch/while(let) construct useful. For example, often a
value is known to be either an object or null (or undefined). (And if
it had the value 0 due to a bug in my program, it's not clear whether
I want the true branch or the false branch anyway: so I should just
use an assert if I want to protect against this.)
Right. JS has falsy values. The if(let) etc. shorthands do not compound
this "problem" (whether it's a real problem is a subject of endless debate).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
