# Are Vararg only allowed as a final argument and if so why?
**URL:** https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490
**Category:** General Usage
**Created:** [April 24, 2019, 11:18pm UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490 "2019-04-24T23:18:06Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@musm](https://discourse.julialang.org/u/musm)
#### Post date: [April 24, 2019, 11:18pm UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/1 "2019-04-24T23:18:06Z")
For example
```julia
julia> f(x::Vararg{Int,N}, y::Float64) where {N} = (x, y)
ERROR: ArgumentError: Vararg on non-final argument in method definition for f at REPL[9]:1
```
In principle the method signature is not ambiguous so it’s not clear why this doesn’t work.
Is this just a temporary limitation or more fundamental ?
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 25, 2019, 12:59am UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/2 "2019-04-25T00:59:03Z")
>
>
> This does not work:
>
> \`\`\`
> julia\> (Int,Int,Float64)\<:(Int...,Float64)
> ERROR: type:… subtype: expected Type{T\<:Top}, got (DataType,DataType)
> \`\`\`
>
> however inside \`methods\` a tuple like that does seem to do something, at least when a \`Any...\` is involved:
>
> \`\`\`
> julia\> methods(f, (Any...,Int,IOBuffer))
> 1-element Array{Any,1}:
> f(a::Int64,b::Int64,c::Float64) at none:1
>
> julia\> methods(f, (Int...,Float64))
> 0-element Array{Any,1}
> \`\`\`
>
> I'm not sure how it should work but probably not as above. Allowing several \`...\` inside a type tuple could be useful. Related: #10380, #8974
Quoth the Jeff:
> This is absolutely not supported yet. It would be very useful, but extremely difficult.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [April 25, 2019, 12:59am UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/3 "2019-04-25T00:59:03Z")
It does not work because `Vararg` is defined to work if and only if it is the last parameter.
To pass some varying number of values as your `x`, use a `Tuple` `(1, 2)` `(1, 2, 3)` etc
where `f(x::Tuple, y::Float64)`.
---
### Author:  [@sagartewari01](https://discourse.julialang.org/u/sagartewari01)
#### Post date: [April 25, 2019, 1:00am UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/4 "2019-04-25T01:00:04Z")
It isn’t really a limitation since you can’t have more than one vararg in the method signature, no matter what. Having it in a location other than the end will only add unnecessary complexity.
---
### Author:  [@musm](https://discourse.julialang.org/u/musm)
#### Post date: [April 25, 2019, 1:02am UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/5 "2019-04-25T01:02:04Z")
Actually there are use cases, see for example [https://github.com/JuliaLang/julia/pull/31654](https://github.com/JuliaLang/julia/pull/31654)
the API would be more uniform in that case if the size argument came last, but it seems it is not possible since it would require a vararg as a first argument.
In any case, it should at least be easiest to allow to be either the _first_ or _last_ argument in a method.
---
### Author:  [@musm](https://discourse.julialang.org/u/musm)
#### Post date: [April 25, 2019, 1:02am UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/6 "2019-04-25T01:02:33Z")
The issue is closed, but the problem is not. Maybe accidental?
---
### Author:  [@mbauman](https://discourse.julialang.org/u/mbauman)
#### Post date: [April 25, 2019, 1:11am UTC](https://discourse.julialang.org/t/are-vararg-only-allowed-as-a-final-argument-and-if-so-why/23490/7 "2019-04-25T01:11:49Z")
The issue was closed by fixing the other bug it listed and improving the error message.