<!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>