Unify wit's stance on trailing commas

[sno2]

These productions currently allow trailing commas:

• Include with names list: include-names-list
• Use lists: use-names-list
• Record fields: record-fields
• Flag fields: flags-fields
• Variant cases: variant-cases
• Enum cases: enum-cases
• Tuple type list: tuple-list

And these disallow trailing commas:

• Include with names list: include-names-list
• Function parameters: named-type-list
• Constant-length generic parameter types: option, result, future, stream, borrow

All of the cases that we currently disallow trailing commas can accept trailing commas without adding ambiguity. I agree with @tschneidereit's judgment and think we should allow trailing commas in all currently disallowed cases.

Split off from #585

[lukewagner]

Makes sense to me except that, with option, future, stream and borrow, there are no lists/commas at all so I wouldn't think we would add the ability to add a spurious dangling comma.

[alexcrichton]

I'd agree with @tschneidereit that we should allow trailing commas everywhere. I'd also go so far as to explicitly allow it for option and single-type-parameter things too since from a parser's perspective it seems reasonable to have a shared "parse parameterized types" routine which always accepts trailing commas without having to special-case single-type-only things. One example is that stream<T> is the only valid thing today, but in the future it's planned to go so far as stream<T, U, V> where trailing commas become more reasonable at that point.

[lukewagner]

Future additions to futures and streams were one of my concerns actually. For one thing, stream<T,> would today be the same as stream<T>, but if we added more type parameters, stream<T,> would not have the same meaning as stream<T, _>, which would be surprising. Separately, I had been worried that commas and positional parameters are too subtle for the additional stream/future type parameters and that some other token as separator might improve legibility (e.g., stream<u8 then result reply-with result>). This may not end up being what we go with, but I'd rather not commit ourself to commas in the short term.

If we want a regular principle to apply here, perhaps it's this: for n-ary expressions (where the grammar allows any number of operands), allow the trailing comma; but when the arity is fixed, keep it as is.

[alexcrichton]

Oh interesting! To me stream<T,> is never something I'd consider equivalent to stream<T,_>. That may be my Rust history showing though since that's how commas work everywhere in Rust AFAIK.

In the meantime though I'm not opposed to limiting statically-can't-have-more-than-one-thing to no trailing commas as that's more conservative. Parsers will need to special case all those cases instead of having one shared "parse stuff between < and > routine" in the meantime, but that doesn't seem too costly in this respect.