I wonder if this should be an issue in julia itself. Perhaps it would be good to require at least one argument?
On Wednesday, April 20, 2016 at 5:00:39 PM UTC+2, Tom Breloff wrote: > > Yes I would say this is dangerous. Assuming there must be at least one > input, the signature should probably be: > > f(firstval::T, rest::T...) = <...> > > > though it certainly doesn't look as pretty. > > On Wed, Apr 20, 2016 at 10:54 AM, Robert Gates <[email protected] > <javascript:>> wrote: > >> Okay, perfect, that answered my question! I thought that at least one of >> the vararg arguments is mandatory. A philosophical thought: isn't this >> use-case kind of dangerous when overloading Base functions in packages? In >> my case, MultiPoly and Lazy both overload Base.+ with a varargs function >> (like the one above). >> >> >> On Wednesday, April 20, 2016 at 4:30:49 PM UTC+2, Robert Gates wrote: >>> >>> I was wondering how this can happen: >>> >>> *julia> **type T1; end* >>> >>> >>> *julia> **type T2; end* >>> >>> >>> *julia> **f(a::T1...) = ()* >>> >>> *f (generic function with 1 method)* >>> >>> >>> *julia> **f(a::T2...) = ()* >>> >>> WARNING: New definition >>> >>> f(Main.T2...) at none:1 >>> >>> is ambiguous with: >>> >>> f(Main.T1...) at none:1. >>> >>> To fix, define >>> >>> f() >>> >>> before the new definition. >>> >>> *f (generic function with 2 methods)* >>> >>> This is a fresh julia 0.4.5 session. I actually encountered this when >>> using two packages and then built this MWE. >>> >>> >
