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.


Agreed.

Thank you all for your replies & clarifications!

---
Regards,
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