crazy idea: dispatch on return type

[martinholters]

I couldn't find any discussion of this idea, so I thought I'd bring it up.

The idea is to introduce special syntax for the "desired return type" argument present in some functions along with special handling in dispatch. I haven't completely thought this through, but would like to stir up some discussion. Let me explain by example. I'll abuse function return type/type assert syntax, so please ignore the present meaning for now. (Syntax up for debate, of course.)

function foo()::Int
    return 1
end
function foo()::String
    return "bar"
end
x = foo()::Int # returns 1
x = foo()::Integer # returns 1, too
x = foo()::String # returns "bar"
x = foo()::Array # MethodError (no such method)
x = foo()::Any # MethodError (ambiguous)

Note the reversed subtype matching compared to argument types, in that foo()::Integer invokes foo()::Int.

That is, a function definition including ::T promises that the function will return a value of (any subtype of) type T (and may well imply wrapping the return value in convert(T,...)::T to ensure that). A function call including ::T will invoke a method annotated with ::S such that S<:T. If there is more than one such method, the least specific (in the return type) one will win. So continuing the example:

function foo()::Number
    return 2.0
end
function foo()::Any
    return nothing
end
x = foo()::Number # returns 2.0
x = foo()::Any # now returns nothing

A function call without ::T annotation is equivalent to ::Any. For function definitions I see two options, i.e. bar() = 0 could be equivalent to

• bar()::Any = 0
• bar{T}()::T = 0.

With the first option, bar() returns an Int, while bar()::Int disappointingly errors. With the second option, bar()::Int would work (and bar()::Float64 could either fail a typeassert in 0::Float64 or do convert(Float64, 0)). Dispatch involving type parameters as the return type would require more thought than I have invested up to this point, though.

What would be the benefits? IMO, a dedicated syntax for the desired return type is much clearer than the current "return type or return type's element type or function that could be a constructor as first argument" convention:

map(Float64, 1)
map(Float64, (1, 2))
rand(Float64)
rand(Float64, 1)
zeros(Float64)
zeros(Float64, 1)

(Yes, two of those do return a Float64.) Also, reversing the subtype relation in dispatch for the return type seems logical, although I'm not too sure this translates into any real benefits, as the current return type as argument approach does work.

Note that I am not proposing to automagically infer the required return type of a function depending on the context where it is called.

[jw3126]

One less "always first" argument makes also #19150 a bit cleaner.

[stevengj]

See also #10269 and @JeffBezanson's thesis discussion of arrow types.

[vtjnash]

c.f. OpaqueClosures

[jonas-schulze]

c.f. OpaqueClosures

Do you have a specific issue we could we more about?

[o314]

From #37849 one can read :

Passing an opaque closure to a high order function will specialize
on the argument and return types of the closure, but not on the
closure identity

Any information is welcome :)

[bc0n]

I certainly don't appreciate the challenge of automagic output type inference, but that would be a great and natural feature. My particular case is writing functions where the user may provide basic types or Unitful and needs particular return types to avoid type errors in later calculations. Ignoring any performance benefits from #37849, C-style overloading on input and output types keeps implementation details in the function definition and avoids subjecting users to unnecessary arguments or function name permutations for type consistency. imho.

For clarity @vtjnash, is this closed because it is judged the same as #37849, blocked by it, it's old (2016), or just not on any roadmap?