dispatch behavior of optional arguments

[nalimilan]

Since empty arrays [] are of type Vector{None}, it will sometimes happen that people do mistakes like this:

julia> function f1(x::Vector{Int} = [])
           true
       end
f1 (generic function with 3 methods)

julia> function f2(; x::Vector{Int} = [])
           true
       end
f2 (generic function with 1 method)

julia> f1()
ERROR: no method f1(Array{None,1})
 in f1 at none:2

julia> f2()
ERROR: no method __f2#3__(Array{None,1})

At least, in the second case, the function name is a bit weird. In the first case, the line number doesn't correspond to anything interesting. If it's possible, it would be great to print a more explicit message, like "default argument value is of an incorrect type".

[JeffBezanson]

Unfortunately this would be extraordinarily difficult to do, odd as that may sound. Default arguments are exactly equivalent to arguments; the system makes no distinction, so treating default arguments specially is not natural. A check could be done at definition time, but that only works for constant types. For example f{T}(x::T, y::Vector{T} = Int[]) works for some arguments but not others.

[vtjnash]

it can certainly lead to some odd behaviors:

julia> f(::Any) = 1
f (generic function with 1 method)

julia> f(x::Int="HI") = 2
f (generic function with 3 methods)

julia> f()
1

[JeffBezanson]

Yes, that's a nice piece of obfuscated code :)

I think it's ultimately a good thing that default arguments are not a special feature, and just reduce to dispatch. You don't need to learn extra rules about how default arguments behave. In this example, it doesn't matter which definition contains ="HI"; everything works the same either way. Giving an error to force you to put the ="HI" on the first definition is fiddly and artificial.

[nalimilan]

I see, it's indeed good that default arguments are handled like others. Though I disagree with your statement:

In this example, it doesn't matter which definition contains ="HI"; everything works the same either way. Giving an error to force you to put the ="HI" on the first definition is fiddly and artificial.

It may be artificial, but it would really make sense (if easy to implement): there's no point in defining a default argument in a method which only applies to another one (apart to obfuscate code). In general, many checks are artificial: why doesn't + broadcast by default, if not just to make things more predictable? So it would already be nice if you can make basic checks at definition time, to catch a few common mistakes.

There are still the two issues that in the first case a line number appears and does not correspond to anything; and that in the second case the function name is weird.

[StefanKarpinski]

I agree that it's good that default arguments are just a shorthand for defining the appropriate additional methods. But it's pretty hard to view this example as anything but problematic. Currently, we have

f(x::Int="HI") = 2

meaning

f(x::Int) = 2
f() = f("HI")

How about making it mean this instead:

f(x::Int) = 2
f() = f(convert(Int,"HI"))

It's not a compile-time error, but at least it ensures that either the expected method gets called or you get a runtime conversion error, which seems much better than the current behavior. If the default is already of the expected type, then the conversion compiles down to a no-op. If we include type-checking and linting into base, enabled via julia -w or something like that, then people will automatically get a warning in the case that no conversion exists for the given default argument type and value.

[JeffBezanson]

I can imagine a case like

# defined in a library
foo(x::Int, y::Int) = ...

You might want to extend this function outside the library as follows

foo(x::Int, y::Float64=1) = ...

Note that it's perfectly valid to write

foo(x::Int, y::Float64) = ...
foo(x::Int) = foo(x, 1)

The default argument form is just a rewrite of that, so why should it be disallowed?

The convert idea is pretty good, but I'm afraid it will create confusion about whether conversion is involved in finding matching definitions, which right now it never is. typeassert would be better, but both that and convert fall apart a bit with abstract types:

foo(x::Real = 1) = ...

If foo(x::Int) is defined later, it will be called instead of this definition. To fully address this, we could use invoke (which also checks for type mismatches of course). But I can't shake the feeling that it's odd to stuff more behaviors into this really simple feature.

[nalimilan]

The default argument form is just a rewrite of that, so why should it be disallowed?

Because approximately nobody is going to understand how such a declaration is going to work? :-)

But I can't shake the feeling that it's odd to stuff more behaviors into this really simple feature.

This is not "stuffing more behaviors", on the contrary this is limiting the complexity of the feature to make it more "simple".

I don't think calling convert is a good idea, it makes things even more complex and might hide mistakes (like writing 1 instead of 1.0). People should write default values in the correct type directly. Just asserting the type should be enough.

[StefanKarpinski]

I don't think the convert business is as bad as the current behavior. If we can ensure that convert(T,x) where isa(x,T) is just returns x for both concrete and abstract types, then it should be fine. Problems can then only arise if you supply a default argument of the wrong type and the conversion doesn't exist. That seems perfectly reasonable to me. Perhaps it could explicitly expand to something like this:

f(x::Int) = 2
f() = let x = "HI"
  isa(x,Int) ? x : convert(Int,x)
end

[StefanKarpinski]

I would be ok with the type assert as well but it does seem a little finicky.

[JeffBezanson]

The issue with abstract types is that a later definition can be more specific, and "intercept" your default argument. There are really 4 options here:

1. Default values must be of the corresponding argument's type.
2. Default values are implicitly converted to the argument's type.
3. The definition containing the default values is always called when trailing arguments are missing, via invoke.
4. When an argument is left out, the default value is supplied instead, and method dispatch happens as normal. (What we do now.)

This is one of those "easy" vs. "simple" things. I'm not sure which of these is easiest, but I think (4) is objectively simplest.

I believe the current rewrite that default arguments do is obvious, and is what everybody would write in the absence of the feature. The alternatives involve generating more code, forcing you to avoid the feature if you don't want the extra code. More stuff happening behind your back is not simpler.

[JeffBezanson]

By the way, I think my (3) above is highly defensible. However I don't like it that much. If you write f(x::Real = 1), and somebody later implements a better version specialized for Int, it's great that the specialized version is called for f() in the future, with no further changes.

[nalimilan]

Yeah, that's why simply asserting sounds like a better solution to me.

[JeffBezanson]

The good thing about asserting is that it's "what we do now but with more errors". So there are no silent behavior changes.

[vtjnash]

The bad part about simply asserting, is that it is "what we do now but with more errors". And it still doesn't necessarily call the function that it "looks" connected to.

I'm actually in favor of the current behavior, and just fixing the backtraces for inline functions, so it is more clear what is happening.