[R-pkg-devel] R feature suggestion: Duplicated function arguments check

[Avi Gross]

Vincent,

But is the second being ignored the right result?

In many programming situations, subsequent assignments replace earlier ones.
And consider the way R allows something like this:

func(a=2, b=3, a=4, c=a*b)

Is it clear how to initialize the default for c as it depends on one value
of "a" or the other?

Of course, you could just make multiple settings an error rather than
choosing an arbitrary fix.

R lists are more like a BAG data structure than a SET.

-----Original Message-----
From: R-package-devel <r-package-devel-bounces using r-project.org> On Behalf Of
Vincent van Hees
Sent: Monday, November 8, 2021 11:25 AM
To: Duncan Murdoch <murdoch.duncan using gmail.com>
Cc: r-package-devel using r-project.org
Subject: Re: [R-pkg-devel] R feature suggestion: Duplicated function
arguments check

Thanks Duncan, I have tried to make a minimalistic example:

myfun = function(...) {
  input = list(...)
  mysum = function(A = c(), B= c()) {
    return(A+B)
  }
  if ("A" %in% names(input) & "B" %in% names(input)) {
    print(mysum(A = input$A, B = input$B))
  }
}

# test:
> myfun(A = 1, B = 2, B = 4)
[1] 3

# So, the second B is ignored.



On Mon, 8 Nov 2021 at 17:03, Duncan Murdoch <murdoch.duncan using gmail.com>
wrote:

> On 08/11/2021 10:29 a.m., Vincent van Hees wrote:
> > Not sure if this is the best place to post this message, as it is 
> > more
> of a
> > suggestion than a question.
> >
> > When an R function accepts more than a handful of arguments there is 
> > the risk that users accidentally provide arguments twice, e.g 
> > myfun(A=1, B=2, C=4, D=5, A=7), and if those two values are not the 
> > same it can have frustrating side-effects. To catch this I am 
> > planning to add a check for duplicated arguments, as shown below, in 
> > one of my own functions. I am
> now
> > wondering whether this would be a useful feature for R itself to 
> > operate
> in
> > the background when running any R function that has more than a 
> > certain number of input arguments.
> >
> > Cheers, Vincent
> >
> > myfun = function(...) {
> >    #check input arguments for duplicate assignments
> >    input = list(...)
> >    if (length(input) > 0) {
> >      argNames = names(input)
> >      dupArgNames = duplicated(argNames)
> >      if (any(dupArgNames)) {
> >        for (dupi in unique(argNames[dupArgNames])) {
> >          dupArgValues = input[which(argNames %in% dupi)]
> >          if (all(dupArgValues == dupArgValues[[1]])) { # double
> arguments,
> > but no confusion about what value should be
> >            warning(paste0("\nArgument ", dupi, " has been provided 
> > more
> than
> > once in the same call, which is ambiguous. Please fix."))
> >          } else { # double arguments, and confusion about what value
> should
> > be,
> >            stop(paste0("\nArgument ", dupi, " has been provided more 
> > than once in the same call, which is ambiguous. Please fix."))
> >          }
> >        }
> >      }
> >    }
> >    # rest of code...
> > }
> >
>
> Could you give an example where this is needed?  If a named argument 
> is duplicated, R will catch that and give an error message:
>
>    > f(a=1, b=2, a=3)
>    Error in f(a = 1, b = 2, a = 3) :
>      formal argument "a" matched by multiple actual arguments
>
> So this can only happen when it is an argument in the ... list that is 
> duplicated.  But usually those are passed to some other function, so 
> something like
>
>    g <- function(...) f(...)
>
> would also catch the duplication in g(a=1, b=2, a=3):
>
>    > g(a=1, b=2, a=3)
>    Error in f(...) :
>      formal argument "a" matched by multiple actual arguments
>
> The only case where I can see this getting by is where you are never 
> using those arguments to match any formal argument, e.g.
>
>    list(a=1, b=2, a=3)
>
> Maybe this should have been made illegal when R was created, but I 
> think it's too late to outlaw now:  I'm sure there are lots of people 
> making use of this.
>
> Or am I missing something?
>
> Duncan Murdoch
>

	[[alternative HTML version deleted]]

______________________________________________
R-package-devel using r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel