Re: Exhaustiveness in switch

- Mail original - > De: "Brian Goetz" > À: "amber-spec-experts" > Envoyé: Jeudi 10 Mai 2018 22:12:37 > Objet: Exhaustiveness in switch > In the long (and indirect) thread on "Expression Switch Exception > Naming", we

Re: Exhaustiveness in switch

> De: "Kevin Bourrillion" > À: "Brian Goetz" > Cc: "amber-spec-experts" > Envoyé: Jeudi 10 Mai 2018 22:44:33 > Objet: Re: Exhaustiveness in switch > * I think that for most occurrences of `default: throw...`, by

Re: Exhaustiveness in switch

OK, but consider these cases. Case 1:     enum E { A, B }     ...     switch (e) {     case A -> ...     case B -> ...     default: throw ...;     } Now, we add "C" to E and recompile.  No compilation error, and it throws on input C. Case 2:     enum E { A, B }     ...    

Re: Exhaustiveness in switch

> On May 10, 2018, at 2:46 PM, Guy Steele wrote: > >> On May 10, 2018, at 4:54 PM, Brian Goetz > > wrote: >> >>> * It would feel strange to even bother applying this exhaustiveness goo to >>> byte switches. If we

Re: Exhaustiveness in switch

* Users of Guava's Preconditions love the support for "%s"-formatting.  But on the other hand, in code where you /are definitely/ about to throw something, why wouldn't I just use string concatenation? That is generally easier to read because you don't have to mentally correlate specifiers

Re: Exhaustiveness in switch

This is just a quick initial response and that it will veer off-topic: * Users of Guava's Preconditions love the support for "%s"-formatting. But on the other hand, in code where you *are definitely* about to throw something, why wouldn't I just use string concatenation? That is generally easier

Exhaustiveness in switch

In the long (and indirect) thread on "Expression Switch Exception Naming", we eventually meandered around to the question of when should the compiler deem an expression switch to be exhaustive, and therefore emit a catch-all throwing default. Let's step back from this for a bit and remind

Re: Treatment of nested 'break'

> On May 10, 2018, at 3:57 PM, Kevin Bourrillion wrote: > > I'm just going to say that naming a keyword as the argument of another > keyword seems novel and unprecedented for Java, and as such I think should > require pretty strong justification. I concur. Note that “case

Re: Treatment of nested 'break'

This might not help, but perhaps think of it as a compound keyword; "break switch" is not "break with an argument of switch", but a multi-word keyword itself. (Back in lambda, when we explored the consequence of using "return" in lambda, and observed it foreclosed on nonlocal return should we

Re: Treatment of nested 'break'

I'm just going to say that naming a keyword as the argument of another keyword seems novel and unprecedented for Java, and as such I think should require pretty strong justification. On Thu, May 10, 2018 at 12:12 PM, Guy Steele wrote: > > > On May 10, 2018, at 3:06 PM,

Re: Treatment of nested 'break'

> On May 10, 2018, at 3:06 PM, Brian Goetz wrote: > > >> I think these are both valid explanations, with different outcomes, but >> anyway it's fair to say that it would be confusing to have the latter >> perspective and then try to explain how a value break can get

Re: Treatment of nested 'break'

I think these are both valid explanations, with different outcomes, but anyway it's fair to say that it would be confusing to have the latter perspective and then try to explain how a value break can get past a surrounding 'for' loop. One option is: you can't.  While I agree there is code

Re: Treatment of nested 'break'

> On May 9, 2018, at 2:32 PM, Brian Goetz wrote: > > The model here is that break is like return; the type of its operand must > agree with the enclosing method. Okay, I think I've successfully wrapped my mind around the two views we're discussing. One is that

Re: JEP325: Switch expressions spec

On 5/10/2018 10:36 AM, Dan Smith wrote: On May 10, 2018, at 6:28 AM, Gavin Bierman wrote: 15.29 "the switch expression completes normally": More conventionally, "the value of the switch expression is …" That phrase occurs in several places, so you’ll have to tell me

Re: JEP325: Switch expressions spec

> On May 10, 2018, at 6:28 AM, Gavin Bierman wrote: > >> SwitchStatementClause is probably too general. I don't think we want to >> allow arbitrary statements to occur on the RHS without braces. It's unweildy >> (think about a chain of if-else, for example),

Re: JEP325: Switch expressions spec

> On May 10, 2018, at 11:03 AM, Guy Steele wrote: > > >> On May 10, 2018, at 10:11 AM, Brian Goetz wrote: >> >> This was the thinking behind UA1; that sometimes you were going to want to >> "fall into" an arrow case > > "What I propose IS NOT

Re: JEP325: Switch expressions spec

> On May 10, 2018, at 10:11 AM, Brian Goetz wrote: > > This was the thinking behind UA1; that sometimes you were going to want to > "fall into" an arrow case "What I propose IS NOT FALLTHROUGH!” he continues to howl into the darkness (but otherwise keeps his mouth

Re: JEP325: Switch expressions spec

> On May 10, 2018, at 8:28 AM, Gavin Bierman wrote: > > >> On 9 May 2018, at 00:08, Dan Smith wrote: >> . . . >> 14.11: somewhat arbitrarily, '->' is considered an "operator" while ':' is >> considered a "separator". Should match that

Re: JEP325: Switch expressions spec

This was the thinking behind UA1; that sometimes you were going to want to "fall into" an arrow case, and one of the reasons that UA1 allowed mixing:     case B:     case L -> S; But, people hated that, so we went another way. As John points out, the one place where it gets ugly is "case

Re: JEP325: Switch expressions spec

Hah! Yes, good catch. Let me think about this one. Thanks, Gavin > On 30 Apr 2018, at 17:13, Éamonn McManus wrote: > > I believe the grammar is ambiguous regarding `->`. If you have > case a -> b -> c > then in principle it could mean (1) when the selector expression

Re: JEP325: Switch expressions spec

[Apologies for slow reply. Now going through the latest batch of feedback.] Ack. Thanks. Gavin > On 27 Apr 2018, at 22:55, Alex Buckley wrote: > > On 4/27/2018 8:03 AM, Gavin Bierman wrote: >> I have uploaded the latest draft of the spec for JEP 325 at >>