Why is concise body for method definition dropped?

Yusuke SUZUKI utatane.tea at gmail.com
Wed Jun 5 10:56:11 PDT 2013

> Rick, I think Yusuke was asking about this form:
>     class F {
>         f(x) x+1
>     }

Yes, this is what I asked.

Brendan Eich wrote:

> Matthew Robb wrote:
>> At one point I was under the impression that the following would produce
>> an implicit return method:
>> class x {
>>    method(x) x+x
>> }
> We dropped it. Maybe Rick can find the meeting notes -- I'm short on time
> due to travel today. The problem is you must terminate with a ; or else the
> expression body may continue into what the user intended to be a subsequent
> property name, especially one of the form we considered (but ultimately
> rejected for now):
>   class C {
>     method(x) x+x
>     [symbol]: 42
>   }
> If there was no syntax error, then ASI does not apply.

Oh, I've understood the problem of MethodDefinition's ConciseBody!

Now we could reckon that [computed-property-name] is "out", so we can put
> expression body back "in" -- but the future-fragility if not
> future-hostility stayed our hands from doing this. I think that's the right
> call, still.

Of course, the expression body "x+x[symbol]:42" does have a later syntax
> error, on the ":" -- but that is confusing.
> Also it could be with computed property names combined with concise
> methods that you get "x+x[symbol](y)+y" (note unary "+" :-P).
> It's a rabbit-hole we'd rather avoid.


Thank you all for your replies & clarifications!

Yusuke Suzuki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130606/369d6e92/attachment.html>

More information about the es-discuss mailing list