Why not always keyword?

Internals & Design
1

Now that keyword arguments are becoming faster, I was wondering: Why not allow calling positional arguments with keywords? In cases that are not entirely inferred, keyword calling would of course be slower.

The only semantic problem I see are situations like:

f(x;y) = something(x,y)
f(x,y) = something_else(x,y)

The second definition recently became valid in https://github.com/JuliaLang/julia/pull/25830.
These methods are currently non-overlapping. If positional arguments became also keyword arguments, then the second version would overwrite the first. So this would definitely be very breaking in theory, but I don’t think it would be very breaking in practice.

Code that uses names for positional arguments that overlap with keyword-args of different methods are not good style: the names of positional parameters are readily available from the method table, and should serve as minimal documentation, i.e. are almost part of the API already. I am not sure whether there are technical problems with this (new feature would slow down dispatch even if not used?). Has there been a discussion of this approach already?

Python example for how I would imagine things to work out:

>>> def foo(xx, yy):
...     print(xx,yy)
... 
>>> foo(3,4)
3 4
>>> foo(yy=4,xx=3)
3 4
>>> foo(3,yy=4)
3 4
>>> foo(xx=3, 4)
  File "<stdin>", line 1
SyntaxError: positional argument follows keyword argument
2

See Allow use of named-argument syntax for positional arguments?

3 Likes
3

Thanks! Sorry for failing to find this in the archives.

DNF’s point about library authors not wanting to commit on naming makes a lot of sense, imho, as well as his final proposal for mature libraries that are willing to commit to argument names as part of the API, as base / stdlib might eventually do.