ANN Switch Expressions in IntelliJ 2019.1 EAP

[Tagir Valeev]

Hello, Brian!

Thank you for evaluating the enhanced switch support in IntelliJ IDEA

> cal =switch (caltype) {
>      case "buddhist" ->new BuddhistCalendar(zone, aLocale);
>      case "japanese" ->new JapaneseImperialCalendar(zone, aLocale);
>      case "gregory" ->new GregorianCalendar(zone, aLocale);
> }
>
> The latter is much better style (expressions all the way down, less repetition, less error-prone).

Agreed, reported:
https://youtrack.jetbrains.com/issue/IDEA-208192
This works nicely if the variable is declared right before the switch.
In this case switch will be moved to variable initializer. Also, as
you noted, pulling return is supported. We could try to pull any
common part, but it doesn't always works pretty. E.g. if all switch
branches look like callSomeMethod(1, 2, 3, <variable part>, 4, 5),
then pulling the switch inside the arguments list is questionable. So
we just support some particular scenarios.

> Similarly, if each RHS is a cast to the same target, you may want to factor the cast out as well.

Looks rare case (if I understand you correctly), but reported as well:
https://youtrack.jetbrains.com/issue/IDEA-208193

> I noticed it didn't merge, say, WHITESPACE and WHITE_SPACE with commas; it did offer to do that as a follow-on refactor.

Yes, these actions are orthogonal: branches could be merged without
conversion to enhanced switch, and some people may prefer to have
separate branches. E.g.:

static boolean hasAppointment(DayOfWeek day) {
    return switch (day) {
        case MONDAY -> false;
        case TUESDAY -> true;
        case WEDNESDAY -> false;
        case THURSDAY -> true;
        case FRIDAY -> false;
        case SATURDAY -> true;
        case SUNDAY -> false;
    };
}

This indeed has duplicating branches (and we suggest to merge them),
but some people may prefer sorted list of days over more compact code.
In this case they may disable the second inspection. Also doing both
things at once (conversion to enhanced switch and merging branches)
may look like too magical, so I think it's fine to have two more clear
steps.

> Here's one it didn't try to transform at all, even though all paths are basically "status = ..; break":
>
> switch (state) {
> case NORMAL:
>      status ="[Completed normally]";
>      break;
> case EXCEPTIONAL:
>      status ="[Completed exceptionally: " +outcome +"]";
>      break;
> case CANCELLED:
> case INTERRUPTING:
> case INTERRUPTED:
>      status ="[Cancelled]";
>      break;
> default:
>      final Callable<?> callable =this.callable;
>      status = (callable ==null)
>          ?"[Not completed]" :"[Not completed, task = " + callable +"]";
> }

Agreed. Reported: https://youtrack.jetbrains.com/issue/IDEA-208195

> I might factor the switch refactor into two; one for expressions and one for statements.  While the -> form is sometimes useful for statements, refactoring often doesn't gain nearly as much as for expressions.  Separating them allows people to set them at different levels of severity.

Not sure about complete separation, but we may introduce an option to
not highlight switches which we cannot convert automatically to switch
expression (only to switch statement). Reported:
https://youtrack.jetbrains.com/issue/IDEA-208196

Thank you again!
With best regards,
Tagir Valeev.


>
>
>
> On 1/29/2019 12:49 PM, Anna Kozlova wrote:
> > Hi all,
> >
> > we have initially supported switch expressions, please give it a try.
> >
> > The download link: https://www.jetbrains.com/idea/nextversion/
> >
> > Your feedback is very welcome.
> > Thanks,
> > Anna
>