Should we use `...` to force making some arguments explicit

[bart1]

This discussion was raised in #739 , by using ... after arguments that should or are frequently provided you can force users in making argument names explicit. This can help prevent accidental usage of argument and makes the code less sensitive to changes in the order of arguments. Below there are some examples. Would it be worth starting to use this into the future?

aa<-function(x, ..., d, e){
  if(!missing(e))
  {
    cli::cli_inform("e: {e}")
  }
  if(!missing(d))
  {
    cli::cli_inform("d: {d}")
  }
  return(x)
}
ad<-function(x, ..., d, e){
  rlang::check_dots_used()
  if(!missing(e))
  {
    cli::cli_inform("e: {e}")
  }
  if(!missing(d))
  {
    cli::cli_inform("d: {d}")
  }
  return(x)
}
ab<-function(x, d, e){
  if(!missing(e))
  {
    cli::cli_inform("e: {e}")
  }
  if(!missing(d))
  {
    cli::cli_inform("d: {d}")
  }
  return(x)
}
# In this case were not forced to make explicit what the 3 is meant fors
ab(2, 3)
#> d: 3
#> [1] 2
# By using dots the second argument has to be made explicit otherwise it is not used
aa(2, 3)
#> [1] 2
# Using rlang we can force an error if not all arguments can be matched
ad(2, 3)
#> Error in `ad()`:
#> ! Arguments in `...` must be used.
#> ✖ Problematic argument:
#> • ..1 = 3
#> ℹ Did you misspell an argument name?

# it all behaves the same when the argument is made explicit
ab(2, e=3)
#> e: 3
#> [1] 2
aa(2, e=3)
#> e: 3
#> [1] 2
ad(2, e=3)
#> e: 3
#> [1] 2

[PietrH]

I think we should/could put ... after any required arguments, but before any optional arguments.

See design principle: https://design.tidyverse.org/dots-after-required.html

• It forces the user of your function to fully name optional arguments, because arguments that come after ... are never matched by position or by partial name. We believe that using full names for optional arguments is good practice because it makes code easier to read.
• This in turn means that uou can easily add new optional arguments or change the order of existing arguments without affecting existing code.

Is this what you had in mind?

[bart1]

Yes that is indeed what I meant, i just was not able to find the link :)

[PietrH]

Then we are in agreement!

[adokter]

Sounds good to adopt this for new functions. For existing functions adding the dots would break backward compatibility, so we could reserve that for an upcoming major release in which we make other breaking changes.