Suboptimal line breaks for long switch rules (with -> arrows)

[PhilippWendler]

For the following code, I would expect line breaks to be added at the arrows (->) of the rules of the switch expression:

public class Test {

  public String f(int i) {
    return switch (i) {
      case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 -> "looooooooooooooooooooooooooooooooooooooooong expression";
      default -> "looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong expression";
    };
  }
}

However, google-java-format 1.15.0 formats it like this:

public class Test {

  public String f(int i) {
    return switch (i) {
      case 0,
          1,
          2,
          3,
          4,
          5,
          6,
          7,
          8,
          9 -> "looooooooooooooooooooooooooooooooooooooooong expression";
      default -> "looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong"
                     + " expression";
    };
  }
}

It even prefers breaking up the string over a line break at the arrow. Please increase the priority of line breaking at the arrow. I guess it should be of higher priority than the list of cases and anything within the expression.

[kevinb9n]

Some overall thoughts on arrowform switch that y'all can pick apart

• Agreed, the formatter's favorite break should be after the arrow or the arrow-and-open brace
• Arrow always stays attached to previous token, like comma (seems to do this already)
• If there are braces, treat as a block (probably does this already)
• If no braces, and the entire expression won't stay with the arrow for whatever reason, wrap after arrow (as noted) and probably use a regular indent rather than continuation indent to avoid the overall switch expression being jagged
• If even then the expression still wraps, I guess that calls for a continuation indent from that level usually, right? (But not relative to the start of the expression; relative to the previous line's indentation level; that might not matter here)
• If case-plus-labels-plus-arrow must wrap, I think those wrapped lines are right to use a continuation indent as shown
• I can't remember if the formatter generally takes steps to avoid one-per-line formatting when a separated list contains very small elements like shown above, but this should ideally be the same as the other cases

[PhilippWendler]

I found another suboptimal formatting that is related to this, namely if there is a line comment right after the arrow. In this case, google-java-format misses to add indentation:

public class Test {
  public boolean test(int i) {
    return switch (i) {
      case 0 -> // zero
      false;
      case 1 -> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".length()
          == 0;
      default -> // otherwise
      true;
    };
  }
}

Together, these issues (plus #876) make using arrow rules not so nice currently, so any improvement here would be highly appreciated! We would likely move over to arrow rules completely in our code base once formatting works fine.

[cushon]

I have some work-in-progress improvements to switch rule handling that result in the following for these examples. This output is non-final but I think it's a step in the right direction.

There are also likely more issues lurking with the new features, so reports/feedback welcome if you see cases that aren't handled well with the new features!

class I880 {
  public String f(int i) {
    return switch (i) {
      case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ->
          "looooooooooooooooooooooooooooooooooooooooong expression";
      default ->
          "looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong expression";
    };
  }

  public String f(int i) {
    return switch (i) {
      case 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 ->
          "looooooooooooooooooooooooooooooooooooooooong expression";
      default ->
          "looooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooong" + " expression";
    };
  }

  public boolean test(int i) {
    return switch (i) {
      case 0 -> // zero
          false;
      case 1 ->
          "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa".length() == 0;
      default -> // otherwise
          true;
    };
  }
}

[PhilippWendler]

Thanks!