Call for bikeshed -- break replacement in expression switch

[Remi Forax]

----- Mail original -----
> De: "Guy Steele" <guy.steele at oracle.com>
> À: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "Éamonn McManus" <emcmanus at 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.cimadamore at oracle.com> wrote:
>> 
>> 
>> On 16/05/2019 21:46, John Rose wrote:
>>> On May 16, 2019, at 1:34 PM, Maurizio Cimadamore
>>> <maurizio.cimadamore at 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 ?

> 
> —Guy

Rémi