In mathematics and in computer programming, a variadic function is a function of indefinite arity, i.e., one which accepts a variable number of arguments. Support for variadic functions differs widely among programming languages.
The term variadic is a neologism, dating back to 1936/1937. The term was not widely used until the 1970s.
There are many mathematical and logical operations that come across naturally as variadic functions. For instance, the summing of numbers or the concatenation of strings or other sequences are operations that can be thought of as applicable to any number of operands (even though formally in these cases the associative property is applied).
Another operation that has been implemented as a variadic function in many languages is output formatting. The C function and the Common Lisp function are two such examples. Both take one argument that specifies the formatting of the output, and any number of arguments that provide the values to be formatted.
Variadic functions can expose type-safety problems in some languages. For instance, C's , if used incautiously, can give rise to a class of security holes known as format string attacks. The attack is possible because the language support for variadic functions is not type-safe: it permits the function to attempt to pop more arguments off the stack than were placed there, corrupting the stack and leading to unexpected behavior. As a consequence of this, the CERT Coordination Center considers variadic functions in C to be a high-severity security risk.
In functional programming languages, variadics can be considered complementary to the apply function, which takes a function and a list/sequence/array as arguments, and calls the function with the arguments supplied in that list, thus passing a variable number of arguments to the function. In the functional language Haskell, variadic functions can be implemented by returning a value of a type class ; if instances of are a final return value and a function , this allows for any number of additional arguments .
A related subject in term rewriting research is called hedges, or hedge variables. Unlike variadics, which are functions with arguments, hedges are sequences of arguments themselves. They also can have constraints ('take no more than 4 arguments', for example) to the point where they are not variable-length (such as 'take exactly 4 arguments') - thus calling them variadics can be misleading. However they are referring to the same phenomenon, and sometimes the phrasing is mixed, resulting in names such as variadic variable (synonymous to hedge). Note the double meaning of the word variable and the difference between arguments and variables in functional programming and term rewriting. For example, a term (function) can have three variables, one of them a hedge, thus allowing the term to take three or more arguments (or two or more if the hedge is allowed to be empty).
To portably implement variadic functions in the C language, the standard header file is used. The older header has been deprecated in favor of . In C++, the header file is used.
This will compute the average of an arbitrary number of arguments. Note that the function does not know the number of arguments or their types. The above function expects that the types will be , and that the number of arguments is passed in the first argument (this is a frequent usage but by no means enforced by the language or compiler). In some other cases, for example printf, the number and types of arguments are figured out from a format string. In both cases, this depends on the programmer to supply the correct information. (Alternatively, a sentinel value like or may be used to indicate the end of the parameter list.) If fewer arguments are passed in than the function believes, or the types of arguments are incorrect, this could cause it to read into invalid areas of memory and can lead to vulnerabilities like the format string attack. Depending on the system, even using as a sentinel may encounter such problems; or a dedicated null pointer of the correct target type may be used to avoid them.
declares a type, , and defines four macros: , , , and . Each invocation of and must be matched by a corresponding invocation of . When working with variable arguments, a function normally declares a variable of type ( in the example) that will be manipulated by the macros.
C# describes variadic functions using the keyword. A type must be provided for the arguments, although can be used as a catch-all. At the calling site, you can either list the arguments one by one, or hand over a pre-existing array having the required element type. Using the variadic form is Syntactic sugar for the latter.
The basic variadic facility in C++ is largely identical to that in C. Prior to C++26, the comma before the ellipsis could be omitted. C++ allows variadic functions without named parameters but provides no way to access those arguments since <code>va_start</code> requires the name of the last fixed argument of the function. C++ also allows variadic functions without named parameters (for example, <code>void f(...);</code>). However, until C++26 there was no portable way to access those arguments, because <code>va_start</code> required the name of the last fixed parameter of the function. Since C++26, C++ adopts the one-argument form of <code>va_start</code>, matching C23 and allowing access to the arguments even when the function has no fixed parameters.
Variadic templates (parameter pack) can also be used in C++ with language built-in fold expressions. Variadic templates are the only type-safe way to have variadic functions/parameters in C++, as C++ lacks Java-style non-template variadic parameters.
The CERT Coding Standards for C++ strongly prefers the use of variadic templates (parameter pack) in C++ over the C-style variadic function due to a lower risk of misuse. Variadic templates are the only way to achieve Java-style type-safe variadic parameters.
Since the Fortran 90 revision, Fortran functions or subroutines can accept optional arguments: the argument list is still fixed, but the ones that have the attribute can be omitted in the function/subroutine call. The intrinsic function can be used to detect the presence of an optional argument. The optional arguments can appear anywhere in the argument list.
Variadic functions in Go can be called with any number of trailing arguments. is a common variadic function; it uses an empty interface as a catch-all type.
Output:
<pre> The sum of [1 2] is 3 The sum of [1 2 3] is 6 The sum of [1 2 3 4] is 10 </pre>
As with C#, the type in Java is available as a catch-all.
In Java, a parameter can be variadic using the ellipsis notation. This is essentially equivalent to an array, however it does not require wrapping as an array. For example, <code>String... args</code> and <code>String[] args</code> would be essentially identical.
JavaScript does not care about types of variadic arguments. The variadic argument is denoted with <code>...</code>, which denotes a "rest parameter" which collects the arguments into an array.
It is also possible to create a variadic function using the arguments object, although it is only usable with functions created with the keyword.
Note that in TypeScript, because the rest parameter is an array, this is denoted as so:
TypeScript also allows forcing the rest parameter to have an exact number of elements (i.e. a tuple):
Lua functions may pass varargs to other functions the same way as other values using the keyword. tables can be passed into variadic functions by using, in Lua version 5.2 or higher , or Lua 5.1 or lower . Varargs can be used as a table by constructing a table with the vararg as a value.
Pascal is standardized by ISO standards 7185 (âÂÂStandard PascalâÂÂ) and 10206 (âÂÂExtended PascalâÂÂ). Neither standardized form of Pascal supports variadic routines, except for certain built-in routines (/ and /, and additionally in /).
Nonetheless, dialects of Pascal implement mechanisms resembling variadic routines. Delphi defines an data type that may be associated with the last formal parameter. Within the routine definition the is an , an array of variant records. The member of the aforementioned data type allows inspection of the argumentâÂÂs data type and subsequent appropriate handling. The Free Pascal Compiler supports DelphiâÂÂs variadic routines, too.
This implementation, however, technically requires a single argument, that is an . Pascal imposes the restriction that arrays need to be homogenous. This requirement is circumvented by utilizing a variant record. The GNU Pascal defines a real variadic formal parameter specification using an ellipsis (), but as of 2022 no portable mechanism to use such has been defined.
Both GNU Pascal and FreePascal allow externally declared functions to use a variadic formal parameter specification using an ellipsis ().
PHP does not care about types of variadic arguments unless the argument is typed.
And typed variadic arguments:
Python does not care about types of variadic arguments.
Keyword arguments can be stored in a dictionary.
In Raku, the type of parameters that create variadic functions are known as slurpy array parameters and they're classified into three groups:
These parameters are declared with a single asterisk (<code>*</code>) and they flatten arguments by dissolving one or more layers of elements that can be iterated over (i.e, Iterables).
These parameters are declared with two asterisks (<code>**</code>) and they do not flatten any iterable arguments within the list, but keep the arguments more or less as-is:
These parameters are declared with a plus (<code>+</code>) sign and they apply the "single argument rule", which decides how to handle the slurpy argument based upon context. Simply put, if only a single argument is passed and that argument is iterable, that argument is used to fill the slurpy parameter array. In any other case, <code>+@</code> works like <code>**@</code> (i.e., unflattened slurpy).
Ruby does not care about types of variadic arguments.
Rust does not support variadic arguments in functions. Instead, it uses macros, which support variadic arguments. This is essentially why <code>println!</code> is a macro and not a function, as it takes variadic arguments to format.
Rust is able to interact with C's variadic system via a feature switch. As with other C interfaces, the system is considered to Rust.
Swift cares about the type of variadic arguments, but the catch-all type is available.
A Tcl procedure or lambda is variadic when its last argument is : this will contain a list (possibly empty) of all the remaining arguments. This pattern is common in many other procedure-like methods.