Sent from my iPhone
> On May 17, 2019, at 2:30 AM, Remi Forax <[email protected]> wrote:
>
> ----- Mail original -----
>> De: "Guy Steele" <[email protected]>
>> À: "Maurizio Cimadamore" <[email protected]>
>> Cc: "amber-spec-experts" <[email protected]>, "Éamonn
>> McManus" <[email protected]>
>> 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
>>> <[email protected]> wrote:
>>>
>>>
>>>> On 16/05/2019 21:46, John Rose wrote:
>>>> On May 16, 2019, at 1:34 PM, Maurizio Cimadamore
>>>> <[email protected]> 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 ?
