Possible `trailing-comma` option

Consider the following tribble

lookup <- tribble(
  ~from             , ~to               ,
  "UNC"             , "UNC Chapel Hill" ,
  "Chapel Hill"     , "UNC Chapel Hill" ,
  "Duke"            , "Duke"            ,
  "Duke University" , "Duke"
)

this would look nicer with a trailing comma

lookup <- tribble(
  ~from             , ~to               ,
  "UNC"             , "UNC Chapel Hill" ,
  "Chapel Hill"     , "UNC Chapel Hill" ,
  "Duke"            , "Duke"            ,
  "Duke University" , "Duke"            ,
)

Similarly, it is commonly adopted in other languages to always add a trailing comma to expanded forms of constructs that allow them. Like in Rust

https://users.rust-lang.org/t/trailing-commas/13993/4

enum Message {
    Quit,
    Move { x: i32, y: i32 },
    Write(String),
    ChangeColor(i32, i32, i32), // <-- Trailing comma
}

The trailing comma here isn't required, but is considered good practice because it makes refactoring easier.

We have the same kind of idea in R with list2(), and anything that is built on it.

list2(
  this,
  that,
  those, # <- trailing comma
)

vec_c() and other vctrs functions that take ... are examples of something that is "built on" list2():

vctrs::vec_c(
  this,
  that,
  those,
)

It would be interesting to consider if we could have a means to support auto-adding trailing commas in expanded form for some cases like this.

If we went the route of doing something like table and default-table, then we could have:

• A default set of functions that would get trailing commas. Opt out of them with default-trailing-comma: false.

  • list2()
  • tribble()
  • dplyr verbs? mutate()? That would be generate a very noisy diff!

• A trailing-comma = [] option where you can provide your own set of functions you'd like to prefer trailing commas in.

This would be a rather complex option because it would interact with persistent-line-breaks. For example:

# Start with this
list2(this, that, those)

# Request expansion
list2(
this, that, those)

# Get this, note the new addition of the trailing comma as well
list2(
  this, 
  that, 
  those,
)

# Re-request flat
list2(this, 
  that, 
  those,
)

# ----
# Now what?

# Do we get this?
list2(this, that, those, )

# Do we refuse to flatten?

# Do we detect this was a trailing-comma function and remove it + flatten?
# That might be the best option, but is pretty complicated!
list2(this, that, those)

Start by reading the existing table and default-table option behavior, then trace how persistent-line-breaks handles expansion and flattening. The issue’s examples identify list2(), tribble(), and vec_c() as target cases; done requires a settled option design and defined behavior for configured functions when lines are expanded or flattened.