Proposal: expression mode (=)

Isiah Meadows isiahmeadows at
Mon Oct 31 13:17:58 UTC 2016

For what it's worth, if the `=` requires a space before it (I disagree that
the semantic ambiguity must exist at assignment - it could simply require
whitespace), that alone would create sufficient context to differentiate.
Compare these two:

a == {} // loose equals, almost always false
a = = {} // a = undefined

Labels would already be unambiguous, because it can only parse statements.

Here's my concern about ambiguity, though:

var b = 1
var a = b
= { c }

What's `a`? ASI makes this much less obvious to resolve, and resolving this
by changing assignment to require no line terminator before the `=` is
technically a breaking change. (Oh, and the Closure Compiler can and will
spit out that.)

On Sun, Oct 30, 2016, 23:35 Yongxu Ren <renyongxu at> wrote:

> For supporting label, yes that is kinda a problem.
> However, IMO jumping around labels is an anti-pattern in functional
> programming, I don't think it needs to be supported. Syntax error might be
> the most reasonable way in this case.
> for 'match', while it is just some thought. I wasn't intended to proposal
> it but just showing potential of  extending `= expression`.
> Personally I do not think label would be a problem for implementing this
> pattern.
> here are two possible solutions I can think of:
> 1. If `[name]:` exist inside the block, just parse it as object and throw
> error if the structure doesn't match.
> 2. If `[label]:` does exist inside the block,  only allow in scope jump.
> (label not accessible outside the scope)
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list