Why is concise body for method definition dropped?
On Wed, Jun 5, 2013 at 4:45 AM, Yusuke SUZUKI <utatane.tea at gmail.com> wrote:
Hello all,
I remember that ConcideBody for MethodDefinition was once introduced into the draft, but after that it was reverted. And I have a question why it is dropped. Searching maling list, I've found 2 threads.
esdiscuss.org/topic/concisefunctionbody, esdiscuss.org/notes/2012-05-23
But I couldn't find why it is dropped. Probably I missed the discussion. So I'd appreciate it if you would inform me about it.
I see what you're referring to, but I can assure you that the addition of syntactically "concise" methods hasn't been dropped. It looks like Allen has just re-organized/removed some of the naming conventions in 13.3.
MethodDefinition : PropertyName ( FormalParameterList ) { FunctionBody }
Still defines a "concise body", but doesn't specifically label it as such and PropertyDefinition still contains the MethodDefinition-part
Hopefully this helps?
Does a concise body method still return by default?
On Wed, Jun 5, 2013 at 9:50 AM, Rick Waldron <waldron.rick at gmail.com> wrote:
MethodDefinition : PropertyName ( FormalParameterList ) { FunctionBody }
Still defines a "concise body", but doesn't specifically label it as such and PropertyDefinition still contains the MethodDefinition-part
Hopefully this helps?
Rick, I think Yusuke was asking about this form:
class F {
f(x) x+1
}On Wed, Jun 5, 2013 at 10:56 AM, Matthew Robb <matthewwrobb at gmail.com>wrote:
Does a concise body method still return by default?
ArrowFunction offers implicit return in the unbraced form:
let two = () => 1 + 1;
two(); // 2
Whereas the braced form requires an explicit return, otherwise returning the default undefined.
Rick
/snip
On Wed, Jun 5, 2013 at 10:57 AM, Jason Orendorff <jason.orendorff at gmail.com>wrote:
On Wed, Jun 5, 2013 at 9:50 AM, Rick Waldron <waldron.rick at gmail.com>wrote:
MethodDefinition : PropertyName ( FormalParameterList ) { FunctionBody }
Still defines a "concise body", but doesn't specifically label it as such and PropertyDefinition still contains the MethodDefinition-part
Hopefully this helps?
Rick, I think Yusuke was asking about this form:
class F { f(x) x+1 }
Yes, it appears I conflated the two "shortened method" syntaxes. Apologies for the noise and thanks for the correct clarification.
At one point I was under the impression that the following would produce an implicit return method:
class x { method(x) x+x }
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.
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.
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.
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+xsymbol+y" (note unary "+" :-P).
It's a rabbit-hole we'd rather avoid.
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+xsymbol+y" (note unary "+" :-P). It's a rabbit-hole we'd rather avoid.
Agreed.
Thank you all for your replies & clarifications!
, Yusuke Suzuki
Meant to send the message to es-discuss!
---------- Forwarded message ---------- From: Brian Di Palma <offler at gmail.com>
Date: Wed, Jun 5, 2013 at 9:12 PM Subject: Re: Why is concise body for method definition dropped? To: Brendan Eich <brendan at mozilla.com>
Was there any desire to support Rust style expressions if enclosed within '{}' i.e.
class C { method( x ) { x + x } }
So the same as in Rust, the last value is returned if no ';' is used to turn the line into a statement?
It's quite elegant and I would imagine is a safer approach?
[Resending my 1:1 reply. /be]
We decisively rejected statement-level Tennent's Correspondence Principle when I did a stand-up routine at the March 2012 TC39 meeting and thereby got arrow function syntax accepted:
C/Java/JS are not Rust or ML. Can't start fresh. In particular, we don't want return/break/continue to satisfy TCP. We also don't want unintended completion-value leaks that are inevitable doing what you propose.
No decision made to date prevents us from TCPing continue-to-label and break-to-label in the future. Currently, any use of a label name defined by a lexically enclosing function is a static error, so this TCPing these would be a compatible change. We knowingly gave up on TCP for normal "return", but this does not preclude a future lexical TCPish return-to-label.
What broke the TCP camel's back for me was yield. To TCP yield would be to give up on the constraint that yield is only shallow. This we must not do.
Hello all,
I remember that ConcideBody for MethodDefinition was once introduced into the draft, but after that it was reverted. And I have a question why it is dropped. Searching maling list, I've found 2 threads.
esdiscuss.org/topic/concisefunctionbody, esdiscuss.org/notes/2012-05-23
But I couldn't find why it is dropped. Probably I missed the discussion. So I'd appreciate it if you would inform me about it.
, Yusuke Suzuki