Named parameters with type overloads

[govorunov]

Thanks!

Please see my answers below:

[quote="HanD, post:25, topic:18860] I would honestly find the semantics you suggest very confusing and error-prone.[/quote]

I intentionally made the example complex to cover as many edge cases as possible. Normal use would not require any of this.

[quote="HanD, post:25, topic:18860] Specifically, having two methods with exactly the same type signature would be strage [/quote]

Yet this is exactly how Julia operates now - you can have two methods with the same signature. The one defined the last will hide previous ones. I just demonstrated this logic remains the same.

@HanD

especially considering that in Julia, typically, the order in which methods of a function are defined is irrelevant, it has no effect on the runtime behavior.

AFAIK it has and exactly how it works now. No changes here at all.

@HanD

# Why Method 5, why not Method 1? What's the purpose of the default value for b in Method 1?
foo(1) # Method 5 as before 

Same reason as previous - method 5 hides method 1, exactly as it works now.

@HanD

# Method 1 or Mathod 4? Why?
foo(1, 1) ?

Method 4, exactly as it works now - the longest signature wins. Actually, method 5 cannot be called by foo(1, 1) at all as it does not match the signature (second argument is a keyword argument and takes no part in dispatch). Again no change here.

@HanD

Furthermore, this would be also very-very confusing:

foo(5, K=5) # Method 5
foo(5, K=5;) # Method 4

This is just to demonstrate solution for the main problem - disambiguation between keyword and ‘positional’ arguments. In this case foo(5, K=5) is the same as foo(5; K=5) which calls method 5 exactly as it is now. foo(5, K=5;) calls method 4 because semicolon clearly indicates separation between positional and keyword arguments. This is the only new part, but because syntax foo(5, K=5;) is currently invalid in Julia it introduces no breaking changes.

@HanD

Not to mention that it would be a breaking change. In Julia, having a semicolon at the end of the parameter list doesn’t change anything. There are no keyword arguments? Fine.

In this design semicolon works exactly as before - separating keyword arguments from arguments that participate in dispatch. The only difference is if one is to reference ‘positional’ (or let’s call it dispatch) arguments by their names, one SHOULD use semicolon to disambiguate from keyword arguments.

@HanD

kwargs = (K = 5,) # Same as before
f(1, kwargs...) # Same as before
f(1; kwargs...) # Same as before
f(1, kwargs...;) # Same as before

kwargs = (;) # The hell is this? :)

@HanD

If you wan’t to handle various combinations of named parameters in your methods, I suggest you introduce auxiliary structures.

Sorry but ugly and unintuitive. Mos other languages have ‘passing arguments by name’ feature. See no point why Julia can’t.

@HanD

And I’m sure there are many more ways to achieve what you are aiming for in a very Juliaesque way.

Probably the very reason why Julia struggles to gain traction even though it is such an elegant language. Being proud and unique doesn’t really work that well, people generally don’t care and just want convenient and friendly tools.

But again, with the proposed design I see not a single breaking change. If anyone sees a breaking change I’ll admit my defeat, I otherwise see no reason why this can’t be done. Implementation should be rather straightforward too, although the complexity of the method pattern-matching algorithm has to be increased.