Why is concise body for method definition dropped?

Mark S. Miller erights at google.com
Wed Jun 5 18:00:19 PDT 2013


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.



On Wed, Jun 5, 2013 at 5:43 PM, Brendan Eich <brendan at mozilla.com> wrote:

> [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:
>
> https://mail.mozilla.org/**pipermail/es-discuss/2012-**March/021872.html<https://mail.mozilla.org/pipermail/es-discuss/2012-March/021872.html>
>
> 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.
>
> /be
>
> Brian Di Palma wrote:
>
>> 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?
>>
>> On Wed, Jun 5, 2013 at 4:38 PM, Brendan Eich<brendan at mozilla.com>  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.
>>>
>>> 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.
>>>
>>> /be
>>>
>>>  On Wed, Jun 5, 2013 at 8:07 AM, Rick Waldron<waldron.rick at gmail.com
>>>> <mailto:waldron.rick at gmail.com**>>  wrote:
>>>>
>>>>
>>>>
>>>>
>>>>      On Wed, Jun 5, 2013 at 10:56 AM, Matthew Robb
>>>> <matthewwrobb at gmail.com<**mailto: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
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> - Matthew Robb
>>>> ______________________________**_________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>>
>>> ______________________________**_________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>>
>> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130605/b242f817/attachment.html>


More information about the es-discuss mailing list