It would be nice to have a way to control line breaking on method arguments

[jacob314]

Using // to control line breaking of method arguments works nicely for arrays but doesn't work for
array like method arguments.
it would be nice if the same technique works.

Example

_Rule OR(
        [a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, //
        t, u, v, w, x, y, z])  =>
    _compileMultiRule(
        (a is List && b == null) // Backward compat. OR([a, b]) => OR(a, b).
            ? a
            : _unspread(a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s,
                t, u, v, w, x, y, z),
        false,
        (compiledRules, valueCount, reducer) => new _ChoiceRule(compiledRules));

should leave a, b, c, ... s // as one line
instead of changing the output to

_Rule OR(
        [a,
        b,
        c,
        d,
        e,
        f,
        g,
        h,
        i,
        j,
        k,
        l,
        m,
        n,
        o,
        p,
        q,
        r,
        s, //
        t,
        u,
        v,
        w,
        x,
        y,
        z]) =>
    _compileMultiRule(
        (a is List && b == null) // Backward compat. OR([a, b]) => OR(a, b).
            ? a
            : _unspread(a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s,
                t, u, v, w, x, y, z),
        false,

[dnfield]

I came here looking for this, but it looks like it's implemented? https://github.com/dart-lang/dart_style/wiki/FAQ#why-does-the-formatter-mess-up-my-collection-literals

[munificent]

The FAQ is talking about collection literals. The bug here is about parameter and argument lists, which are different. (The example is a little confusing here because the parameters are optional, so are surrounded by [ ... ], which makes them look like a collection.)

[dnfield]

Ahh I see now.

[munificent]

With the forthcoming tall style, you get:

_Rule OR([
  a,
  b,
  c,
  d,
  e,
  f,
  g,
  h,
  i,
  j,
  k,
  l,
  m,
  n,
  o,
  p,
  q,
  r,
  s, //
  t,
  u,
  v,
  w,
  x,
  y,
  z,
]) => _compileMultiRule(
  (a is List && b == null) // Backward compat. OR([a, b]) => OR(a, b).
      ? a
      : _unspread(
        a,
        b,
        c,
        d,
        e,
        f,
        g,
        h,
        i,
        j,
        k,
        l,
        m,
        n,
        o,
        p,
        q,
        r,
        s,
        t,
        u,
        v,
        w,
        x,
        y,
        z,
      ),
  false,
  (compiledRules, valueCount, reducer) => new _ChoiceRule(compiledRules),
);

That's definitely, uh, tall. But I don't think there are changes I want to make to the formatter to improve this because I think they would overall cause more problems than they solved. Functions with a long list of very short parameters are rare.

Much more common are functions with a comment in the parameter list somewhere. And in most of those, I believe the user does not indent that comment to change how the parameter list is formatted. They just want to put a comment there. (I suspect that the majority of comments in parameters are actually just commented out parameters.)

So I'm going to go ahead and close this as working as intended. Honestly, I think the better long-term solution here is varargs support in the language so that you don't need long homogeneous parameter lists like this in the first place.