Are _symmetric_ multimethods worth it?

Internals & Design
2

I’m not sure what exactly you mean by a symmetric or asymmetric multimethod, but some googling suggests that it’s a strategy whereby method ambiguities are resolved in some asymmetric way, usually left right ordering E.g. if I define

f(x::Int, y) = 1
f(x, y::Int) = 2

in julia, this would result in ambiguities:

julia> f(1, 1)
ERROR: MethodError: f(::Int64, ::Int64) is ambiguous. Candidates:
  f(x::Int64, y) in Main at REPL[1]:1
  f(x, y::Int64) in Main at REPL[1]:1
Possible fix, define
  f(::Int64, ::Int64)

but in a system with asymmetric multiple dispatch, it might say break ties by going left to right in the arguments, so in this case, since f(x::Int, y) = 1 is more specific in the first argument, this is the method that gets called.

Is this what you meant?

I think this is an interesting approach to resolving method ambiguities and it makes some sense to me as a general strategy for approaching this. I could definitely imagine it can lead to some undesirable effects though even if I don’t have a concrete example in mind.

I think currently, due to single inheritance, method ambiguities aren’t a gigantic problem in julia, they’re annoying, but not show stoppers. However, many people would like a native trait based dispatch system and with that I’m sure we’d almost immediately end up in ambiguity hell without a way to resolve them.

3 Likes