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?

  div(
    style: {
      'display': 'block',
      'width': '10px',
    },
    contents: [
      span(
        id: 'msg',
        contents: [
          text(this.message)
        ]
      ),
      button(
        contents: [
          text('Save')
        ]
      )
    ]
  );

Could you eliminate extra list allocations and named parameters from the API and still make it look nice?

The formatter should just never have assymetric whitespace around punctuation pairs. If there's a newline after the (, it should put a newline before the ), and so on. The alternative is much uglier in general, not just around this kind of tree structure.

@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.)