@nalimilan By telling Julia what method I’m referring to. It boils back to having missing typed arguments - or making arity and the corresponding types (let’s call this arity+type) an integral part of a method’s signature.
With typed missing arguments,
bar() would be
bar(::Any). Which would be different from
bar(::String, ::Symbol). It could be invoked as
bar(::String) or as
With arity+type notation it could be
bar<String,Symbol>() corresponding to
bar(a::String = "", s::Symbol = :s). With invocations looking like
I prefer the esthetics of the 2nd form, which would resemble the current
bar<T,N> and would allow
@Tamas_Papp Sorry, my example was too convoluted. I’m basically suggesting what’s above: that the original method signature (arity+types) stays “sticky”. And can be invoked explicitly; versus the current behavior where Julia takes a higher-arity-more-specific method and generates lower-arity-less-specific methods, losing track of what was the original method and creating overwriting methods. Makes sense?
Indeed, I’ve read the issue referenced by @nalimilan - I assume you’re referring to the
_hidden_f_ approach. Not sure how this would work with the examples we discussed, when higher-arity-more-specific methods generate less-specific-lower-arity methods?
It seems to me that
bar(s::String = "moo")
bar(i::Int = 2)
bar() = _hidden_bar_("moo")
bar() = _hidden_bar_(2)
which would still be overwriting implementations.
Unless we go back again to my suggestion:
bar(::String) = _hidden_bar_("moo")
bar<String>() = _hidden_bar_("moo")
But of course, if we have
bar<String>() we don’t need
@yuyichao I understand. My point is no longer about the initial question (thank you all for clearing that out, btw), but rather about “can we think of a better way of doing this?”. In the end, the decision belongs to the core team - I just hope to offer a different (fresh?) perspective.
It took a bit of a detour but I’d say that the above defines my view of a possible implementation. Tagging method definitions with arity+type information which would allow the simultaneous definition of multiple methods without overwrites and would also allow disambiguation and explicit invocation. A possible syntax would be:
f<T,N>(x::T = T(), y::N = N()) = ...
bar(s = "", i = 42) = # ...
Julia would generate the tagged methods
bar(s = "", sy = :s) = :x
Julia would generate
For disambiguation, where necessary, we could invoke the desired method as
The tagged invocation would be optional and only required for disambiguation, plain
bar() would still work if no ambiguities.
How other languages deal with this is indeed quite intriguing - I’ll do a bit of research into that, I’m curious too. If anything useful comes out, I’ll report back.