The only counter-argument I've heard was that it has the consequence of making the argument name part of the API (i.e. changing the name would be a breaking change, so all parameter names of exported functions "leak" into the public interface). That always seemed like a very minor drawback to me, I too would appreciate to have named arguments in Rust.
It seems more like a feature to me. Sometimes parameters change slightly and you will never notice it until you re-read the docs. So if the change is explicit I can go look at it during compile time and not be surprised by it during runtime.
Of course there are occasions where the name is unfortunate (typo, ambiguous name or incorrect term) but the docs could mention it and it would not be the end of the world.
I agree, although I haven't done enough work with languages using named parameters to really judge how inconvenient they can become in practice.
It seems like most naming issues could be alleviated by allowing the developer to provide aliases, this way you can change the preferred parameter name while still keeping the old one around for backward compatibility.
You always have some concept of the API leak into the consumer. You either remember explicit names, or remember their positional pseudo-names 'first', 'second', 'third' etc. Unnamed arguments bring up more issues such as ordering consistency (see: PHP's many notorious cases), deprecation leaving 'holes' in argument lists, etc.
In Perl and many other languages we just provide a hash (aka dict) of key/value pairs. This lets the functions decide how to handle breaking changes which involves some annoying boilerplate but overall works fairly well. It's nicer with proper language support though.
