----- 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 ? > > —Guy Rémi