Code with cascading calls inside an assert is moved too soon to a new line.

[Jonas-Sander]

Actual

class Foo {
  final List<Foo> subsections;
  final bool aBoolWithSomeVeryLongName;

  Foo({
    this.subsections,
    this.aBoolWithSomeVeryLongName,
  }) : assert(subsections
                .where((element) => element.aBoolWithSomeVeryLongName)
                .length <=
            1);
}

Expected
(Or something along these lines)

class Foo {
  final List<Foo> subsections;
  final bool aBoolWithSomeVeryLongName;

  Foo({
    this.subsections,
    this.aBoolWithSomeVeryLongName,
  }) : assert(subsections
                .where((element) => element.aBoolWithSomeVeryLongName)
                .length <= 1);
}

[munificent]

I ran this code through the forthcoming tall style and it gives you:

class Foo {
  final List<Foo> subsections;
  final bool aBoolWithSomeVeryLongName;

  Foo({this.subsections, this.aBoolWithSomeVeryLongName})
    : assert(
        subsections
                .where((element) => element.aBoolWithSomeVeryLongName)
                .length <=
            1,
      );
}

I admit that's still a little funny looking. But that's mostly a consequence of the structure of the code. The formatter has a very simple rule that if either operand of a binary operator contains a newline then we split at the operator too. That helps clarify precedence when you have nested binary operators of different kinds and generally avoids the operator getting buried in the middle of a pile of large code.

But in this case, it looks weird because you have one really large operand before <= (the entire subsections...length expression) and one really short one after (1). So it splits at the <= and the 1 looks a little lonely.

Aside from that, I think the new formatter is doing what I expect here and looks OK. (If this were my code, I'd probably make a utility function for the subsections...length part and call that from the assert.)