Proposal: expression mode (=)

Isiah Meadows isiahmeadows at gmail.com
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:

```js
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:

```js
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 gmail.com> 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 mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161031/578dc063/attachment.html>


More information about the es-discuss mailing list