New candidate JEP: 361: Switch Expressions (Standard)

[Fred Toussi]

Thanks,

You asked for experience of using the feature. I attempted it previously and noticed all the colons needed changing to two different symbols in order to factor out the "break" usage. As for IDE's, they do not solve the extensive version control diffs caused by converting huge switch statements.

Eveloving the switch form is a good idea. What I proposed looks more like an evolution of the traditional switch, as code will have fewer visible changes than with the current JEP 361 syntax. If the colon is retained as the case separator, the additions such as the option of qualifiying the switch with "break" and the use of the arrow and "yield" to return values just serve the purpose exactly at the point of use.

Regards

Fred

On Mon, Oct 21, 2019, at 16:26, Gavin Bierman wrote:
> 
> 
> > On 21 Oct 2019, at 15:53, Fred Toussi <fredt at users.sourceforge.net> wrote:
> > 
> > Typos:
> > 
> > The spac still uses SwitchLabeledRule where it defines the new production.
> 
> Thank you. I’ll fix that.
> 
> > 
> > The example with switch (day) implies we can use both the comma and the colon as case separators.
> 
> Yes, that is right, and I recall some discussion on this. We think 
> people will move to the comma form in time. 
> 
> > 
> > I wote to the amber-spec-observers last October (https://mail.openjdk.java.net/pipermail/amber-spec-observers/2018-October/000907.html), but got no reply to the substance of my concerns.
> > 
> > To avoid extensive changes to existing apps, and to reduce developer confusion with multiple colon and comma  separators (which is evident in the aforementioned mixed-up example given in the spec document) , I proposed:
> > 
> > 1. Adding a keyword to the start of the switch _statement_ to indicate "break" will be automatic at the end of each case. I suggested "new switch(val) {",  but "switch break(va l) {" is a probably a better alternative. No change to the usage of the colon is required.
> > 
> > 2. Continued usage of colon for switch expression cases, with the use of the proposed arrow "->" and  "yield" to return expression values. 
> 
> I was asking for experience of using the feature, rather than requests 
> to reopen the design. Actually Brian has addressed this before - we had 
> a strong design goal to *not* introduce a new switch form, but to try 
> to evolve the existing one. Of course, evolving a feature comes with a 
> cost, which is that some code will have evolved and some might not. 
> However, IDEs will probably help here. Do you have experience that 
> suggests otherwise?
> 
> Thanks,
> Gavin