Named parameters with type overloads

[govorunov]

@Benny

Blue words indicate a link, that particular link goes to an example I wrote for a previous topic.

OK, let’s do this.

@Benny

# calling foo(1, 2) would be ambiguous if k1 could be positional
function foo(p1; k1)
function foo(p1, p2)

Calling foo(1, 2) calls second method as first accepts only one positional argument - no ambiguity here.

@Benny

# matching keywords in a call e.g. foo2(p2=Cat(), p1=Dog()) would be ambiguous
function foo2(p1::Dog, p2::Cat)
function foo2(p2::Cat, p1::Dog)

Same as

function foo2(p1::Dog, p2::Cat)
function foo2(p2::Dog, p1::Cat)

currently creates ambiguity for positional arguments but I don’t hear people complaining. Of course if one really wants to create untractable code one wouldn’t need many tools, simple C would do just fine.
Same as currently with positional arguments - the last defined method hides the previous, it’s a simple pattern-matching.

@Benny

function foo(k1::Dog, k2::Cat)
function foo(k2::Dog, k1::Cat)

function foo(k2::Cat, k1::Dog) # overwrites the 1st method
function foo(k1::Cat, k2::Dog) # overwrites the 2nd method

Methods are not ‘overwritten’ but hidden. It’s a pattern matching against the list. The same logic applies with the proposed change. If you want to create a mess you don’t need many features to do this.

@Benny

Python can allow positional-or-keyword arguments because of its “unimethods,” though it must in turn disallow keyword arguments preceding positional arguments in calls

Does Julia allow keyword arguments preceding positional arguments in calls? Is there any good reason for this?

@Benny

function foo3(x, y)
function foo3(y; x)
# foo3(x=1, 2) calls the latter, would be ambiguous otherwise

This should not be allowed at all.

@Benny

That is conventionally considered a breaking change, yes. Breaking changes are a well-established concept, anyone’s personal opinion on what it should mean instead is irrelevant. That includes the methods HanD highlighted, if you want a clear demonstration:

OK, I admit, the foo(5, K=5;) syntax that shouldn’t currently work works in ambiguous way and you wanna keep it as it is. The question is there anyone really using foo(5, K=5;) syntax now because it has no sense?

@Benny

julia> foo(a; K)="Method 5"
foo (generic function with 1 method)

julia> foo(a, K::Int)="Method 4" # had to fix your typo K:Int
foo (generic function with 2 methods)

julia> foo(5, K=5)
"Method 5"

julia> foo(5, K=5;)
"Method 5"

Same here - shouldn’t currently work, completely useless, but OK, let’s keep the useless ambiguous syntax.