Le mercredi 20 avril 2016 à 08:50 -0700, Robert Gates a écrit : > I wonder if this should be an issue in julia itself. Perhaps it would > be good to require at least one argument? There has been some discussion about syntax to specify a minimum and maximum number of arguments. But nothing has been decided yet. See https://github.com/JuliaLang/julia/pull/10691#issuecomment-88509128
Regards > > 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] > > > 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). > > > > > > > > > > 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. > > > > > > > > > >
