[Formatting issue] Chaining null-aware member access with if-null formats weirdly

[C0Florent]

What input code did you provide to the formatter?

String melosVersion = argResults
    ?.option("melos-version-specification")
    ?.nonEmpty()
    ?? "7.0.0-dev.9";

What output did the formatter produce?

String melosVersion =
    argResults?.option("melos-version-specification")?.nonEmpty() ??
        "7.0.0-dev.9";

What output did you expect or want the formatter to produce?

I think a better format would be my original input, we can clearly read the chaining member access operators and the ending if-null on the start of a line rather than on the end of a line.

String melosVersion = argResults
    ?.option("melos-version-specification")
    ?.nonEmpty()
    ?? "7.0.0-dev.9";

To me this reads much better because operators on line endings are very easy to miss, thus it is easy to miss (not see) the ?? at the end of the line and wonder why there is an indented string on the following line.

Anything else we should know?

Interestingly, if the member access chain is longer, it is somewhat better formatted already :

String melosVersion = argResults
        ?.option("melos-version-specification")
        ?.nonEmpty()
        .toString() ??
    "7.0.0-dev.9";

Although I still dislike the ?? on the end of line, and have no idea why the default string would be deindented compared to the member acccess chain

Perhaps this could be implemented by treating a ?? at the end of a ?. chain the same as . member access for formatting. Examples of what I mean:

Treating the following

      String? melosVersion = argResults
          ?.option("melos-version-specification")
          ?.nonEmpty()
          .toString();

The same as this:

      String melosVersion = argResults
          ?.option("melos-version-specification")
          ?.nonEmpty()
          ?? "7.0.0-dev.9";

[munificent]

This is an interesting one. The formatter has two basic rules that usually come into play:

1. If a child of some piece of syntax contains a newline, then force the outer thing to split too.

2. When a parent and child both split, indent the child more than the parent.

These rules get tweaked in some contexts, but for infix operators, that's pretty much how they work. For example:

someVeryLongOperand *
        anotherLongOperand +
    third;

Here, we split after + because of rule (1) and we indent anotherLongOperand +8 because of rule (2). For the most part, these rules do what users expect and produce nice tree-like formatting where the indentation reflects the nesting structure of the code.

That's exactly what you're seeing here:

argResults
        ?.option("melos-version-specification")
        ?.nonEmpty()
        .toString() ??
    "7.0.0-dev.9";

We split after the ?? because of (1) and we indent the ?. and . lines +8 because of (2). There's no special handling.

We could consider treating ?? specially and have it behave sort of like another call on the method chain when its left operand is a method chain containing null-aware operators like your example here. That might produce output kind of like you suggest in these examples.

But I don't know if code like this is common enough for special-case formatting to be worth it, and there's a good chance it will end up making other kinds of code look worse. I'll have to do some experimentation and try it out when I get time.