Indent block-like function expression bodies when split at =>

[munificent]

A function expression may have a => body followed by a block-like expression, like a list, map, switch expression, or even another function expression. Right now, that inner expression's block indentation is not increased by virtue of being nested inside a function expression. That leads to output like:

SomeLongFunctionName(
  argument: () => [
    listElement,
    listElement,
    listElement,
  ],
);

I think this formatting works pretty well. Most users seem to be OK with it too since lots of code is formatted this way and I haven't heard many complaints. However, the formatting looks weird if we end up needing to split after the => because the parameter list is long or before the block-like expression has something long before its opening bracket, as in:

SomeLongFunctionName(
  argument: (longParameterName______) =>
      <LongTypeArgument>[
    listElement,
    listElement,
    listElement,
  ],
);

This looks pretty strange because now the opening delimiter is on its own line (as opposed to be on the same line as the =>) but that line doesn't align with the corresponding closing delimiter. It looks particularly strange with a switch expression (#1197):

SomeLongFunctionName(
  argument: (longParameterName______) =>
      switch (e) {
    1 => listElement,
    2 => listElement,
    3 => listElement,
  },
);

I've tried changing it to always indent the block body, which gives:

SomeLongFunctionName(
  argument: (longParameterName______) =>
      switch (e) {
        1 => listElement,
        2 => listElement,
        3 => listElement,
      },
);

This example now looks better, but the first one is worst:

SomeLongFunctionName(
  argument: () => [
        listElement,
        listElement,
        listElement,
      ],
);

From testing on a corpus of open source code, there are a lot of callsites that would be affected by this, and almost all of them ended up looking worse like the last example here.

The correct fix is to have the block indentation change based on whether we split after the =>. If it splits, then indent the block, otherwise don't.

Unfortunately, the architecture of the formatter doesn't currently support that. Block indentation is calculated when the AST is transformed into chunks before line splitting.

I won't be able to fix that easily, so I'm filing this to track hopefully being able to do that better fix when I have more time.

[munificent]

I ran these examples through the forthcoming tall style and they look like:

SomeLongFunctionName(
  argument:
      () => [
        listElement,
        listElement,
        listElement,
      ],
);

SomeLongFunctionName(
  argument:
      (longParameterName______) =>
          <LongTypeArgument>[
            listElement,
            listElement,
            listElement,
          ],
);

SomeLongFunctionName(
  argument:
      (longParameterName______) =>
          switch (e) {
            1 => listElement,
            2 => listElement,
            3 => listElement,
          },
);

The new formatting style doesn't try to keep the parameter list and => on the same line as a named argument. It has a simpler more regular set of rules for deciding to split there. So this output isn't quite what this issue initially talks about, but I think the output makes sense and looks clear. The most important part is that it never has indentation that looks "backwards" where the collection literal or switch body is indented less than the closure than contains it.