# Re: Proposal for variadic functions

• From: Michael Kay <mike@saxonica.com>
• Date: Tue, 8 Dec 2020 16:36:43 +0000
• To: Dimitre Novatchev <dnovatchev@gmail.com>
• Message-Id: <E69B0E32-4033-4027-BA97-4C2CC7E9B65C@saxonica.com>
```>
> If a function is variadic, then its name must be unique within the static context.
>
> Does this mean that there cannot exist two variadic functions with the same name, for example
>
>     myFun(\$arg1, \$arg2, \$arg3 default: 0 )
>
> and
>
>       myFun(\$argName1, \$argName2 default: 3 )
>
> If so, why is this restriction?

To keep the rules simple and understandable, and to enable simple and clear error messages when people get things wrong. It would be possible in theory to have one function F with arity range 1-2 and another with arity range 3-5, but things like function-lookup would all get unnecessarily complicated.

In your example, which function would myFun(1, 2) invoke?
>
>
> A variadic function can be identified by a function reference of the form name#*. fn:function-arity applied to a variadic function returns (); fn:function-lookup and fn:function-available accept a second argument of () to identify a variadic function.
>
>
> I think it would be more precise to have: name#m-n  where m is the number of positional/required arguments and n is the number of keyword arguments.

Well, firstly, this doesn't parse unambiguosly. One could solve that with a different syntax such as name#(m-n) but it just seems unnecessary complexity; you're providing users with extra rope to hang themselves by.

>
> As other people asked, I don't understand what "virtual fixed-arity" function means. Please, elaborate and provide an example.

I hope my explanations to Norm Tovey-Walsh and Reece Dunn explained the general idea. Obviously the detailed spec remains to be written.
>
>
> Because in a function call we can reference now any argument by name (even a positional argument), we must specify a restriction that the (names of the) keys of the map do not clash with the names of the positional arguments, or to allow in this case a mechanism for disambiguation, something like:
>
This is why I specified that arguments supplying parameters prior to the final map parameter cannot use keywords, they must be specified positionally.

Michael Kay
Saxonica
```

Received on Tuesday, 8 December 2020 16:37:00 UTC