trailing commas for tree-like code in Dart

tree_code_fmt.dart

// frameworks such as Flutter and UIX encourage users to express their
// UI using tree-like syntaxes.

// unfortunately dartfmt will format this code:
main() {
  var componentTree = new MyButton(
    title: 'Save',
    onClick: () {
      doSomthing();
    },
    icon: new Image(
      src: '/images/save.png',
      width: 10
    )
  );
}

// to this:
main() {
  var componentTree = new MyButton(title: 'Save', onClick: () {
    doSomthing();
  }, icon: new Image(src: '/images/save.png', width: 10));
}

// what if Dart allowed trailing commas in function/method/constructor calls and
// dartfmt treated them as a signal that the closing paren must go on the next line?
main() {
  var componentTree = new MyButton(
    title: 'Save',
    onClick: () {
      doSomthing();
    },
    icon: new Image(
      src: '/images/save.png',
      width: 10,  // <-- trailing comma
    ),  // <-- trailing comma
  );
}

// problem solved?

@Hixie, that's true, however, how would the formatter choose between putting a newline and not putting one after the opening paren? I'm proposing a simple syntactic rule:

Is there a trailing command in the function call/constructor call/annotation/list literal/map literal?
Yes: put newline after the opening paren and before the closing paren
No: no newlines (or whatever it does today)

@munificent: oh yeah, I forgot to mention annotations. Today we have:

@Component(
    selector: 'my-component',
    host: const {
      '(keypress)': 'handleKeyPress()',
      'tabindex': '0',
    },  // awesome
    directives: const [
      NgIf,
      NgFor,
    ],  // awesome!!!
    styleUrls: const ['some.css'])  // :(

While with this proposal we could have:

@Component(
  selector: 'my-component',
  host: const {
    '(keypress)': 'handleKeyPress()',
    'tabindex': '0',
  },  // awesome
  directives: const [
    NgIf,
    NgFor,
  ],  // awesome!!!
  styleUrls: const ['some.css'],
)  // woohoo!!!

It would just do whatever the author did. If the author includes a newline, include a newline and match it before the closing punctuation, otherwise, try to fit it on one line and break if necessary (and if there's a good breaking point -- but after an open punctuation is not a good breaking point).

(I understand that what I'm proposing is incompatible with dartfmt's current goals. I think dartfmt's goals should change.)