<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Thanks for the responses.</p>
<p> </p>
<blockquote type="cite">I don't really expect this feature to
happen, but I feel like this thread ought to include some mention
of the actual benefits of the feature?</blockquote>
<p></p>
<p>You are absolutely right. Thanks for listing them. The Scala
project also listed advantages and drawbacks in <a href="https://docs.scala-lang.org/sips/trailing-commas.html">SIP-27
- Trailing Commas</a> before its implementation.</p>
<p> </p>
<blockquote type="cite">For every person who has a strong preference
in favour of allowing trailing commas where they’re not allowed
today you’ll find another with an equally strong preference
against allowing them. Additionally, if this option exists, people
will want to write or update style guides preferring one style or
the other. So the result is a lot of time, and possibly completely
disproportionate emotion, spent for what, at best, is little gain.
To me this sounds like the kind of change that is bound to require
more effort — not on the implementation perhaps, but in debate —
than it’s worth.</blockquote>
<p></p>
<p>If I understand correctly, you're pointing out the effort
required to determine if the entire community would support this
change? That is a fair point. I still want to mention that in my
personal experience outside the Java ecosystem, discussions around
trailing commas haven't been as contentious as those involving
whitespaces, tabs, or line breaks. They've generally leaned
towards supporting trailing commas. This is why I unfortunately
failed to list the advantages as I did not consider trailing
commas particularly controversial by themself. This might be a
personal bias of course. Nevertheless, I acknowledge that there
might be more pressing topics at the moment.<br>
</p>
<p> </p>
<blockquote type="cite"> - every change we made that "makes life
easier for code generators" makes life harder for parsers, and it
is not clear that privileging one over the other is a good idea;</blockquote>
<p></p>
<p>I think the main drawback lies in the requirement to change
existing tooling. However, tools have to adapt to new Java
versions all the time. Adding support for trailing commas to a
parser, in my experience, requires minimal changes and doesn't
significantly complicate the implementation. When I added support
for trailing commas to my parser of the Nix Expression Language, I
only had to make a small change to a single line (besides adding
tests).</p>
<p> </p>
<blockquote type="cite">Your point about smaller diffs and
reordering lists is correct, and (I'm guessing) what originally
motivated this feature.</blockquote>
<p></p>
<p>Yes, you are right. It's all about making it easier to work with
lists.<br>
</p>
<p> </p>
<blockquote type="cite">However, that motivation only applies when
the items you are listing are normally or typically placed on
separate lines.</blockquote>
<p></p>
<p>I think putting method arguments onto separate lines is also
somewhat common, especially when considering varargs. I also
imagine it quite useful for the component list in records. For the
remaining language constructs, it might be less common, but I have
definitely seen cases where other constructs were placed on
separate lines as well.</p>
<p>Thanks again. I will take from this conversation that trailing
commas are unlikely to be prioritized anywhere soon.<br>
</p>
<p>Best regards,<br>
Johannes<br>
</p>
<p> </p>
<p></p>
</body>
</html>