Sent from my iPhone
> On May 17, 2019, at 2:30 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
>
> ----- Mail original -----
>> De: "Guy Steele" <guy.ste...@oracle.com>
>> À: "Maurizio Cimadamore" <maurizio.cimadam...@oracle.com>
>> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>, "Éamonn
>> McManus" <emcma...@google.com>
>> Envoyé: Jeudi 16 Mai 2019 23:41:05
>> Objet: Re: Call for bikeshed -- break replacement in expression switch
>
>>> On May 16, 2019, at 5:05 PM, Maurizio Cimadamore
>>> <maurizio.cimadam...@oracle.com> wrote:
>>>
>>>
>>>> On 16/05/2019 21:46, John Rose wrote:
>>>> On May 16, 2019, at 1:34 PM, Maurizio Cimadamore
>>>> <maurizio.cimadam...@oracle.com> wrote:
>>>>> On the other hand is a trivial one to resolve, given what we're
>>>>> discussing now
>>>>> is something like
>>>>>
>>>>> "yields" EXPRESSION
>>>>>
>>>>> so, as soon as the compiler sees a "(" it will say: "ok, that's not a new
>>>>> yield
>>>>> statement".
>>>> The tricky bit with that is the user experience. What if the
>>>> user needs a parenthesized expression:
>>>>
>>>> yield ("answer is "+x).trim();
>>>>
>>>> There are some sharp edges here.
>>>
>>> I was hoping we didn't need to go there :-)
>>>
>>> There are other contexts in which we limit what can be done w/r/t/
>>> parenthesized
>>> expressions (since these are ambiguous with cast to generic types). So this
>>> looks like another case where the grammar has to say - sorry no parens here.
>>
>> And _that_ would very much give me pause. I would find it quite wrenching to
>> have a place in the language where an expression cannot be parenthesized and
>> have it mean exactly the same thing.
>>
>> Maybe we should go back to a hyphenated keyword.
>
> goto-with ?
throw-yield ?
