Pre-RFC: Named arguments

language design
35

I really would just like to make a bit of a meta remark at just how refreshing it is to see such a well-written RFC written by somebody who has clearly read all of the past discussion, and who has new ideas to bring to the table on a topic that has been mostly running around in circles for years.

The proposal here is extremely cohesive and has a well-defined scope. I can see how each design decision and limitation (e.g. lack of reordering, forced usage at callsites) makes sense in the context of the rest of the design. At first I was unsure why overloading is a part of it, but as I read through it became clear that this was necessary to allow backwards-compatible adoption by existing APIs. You've certainly found a local maximum in the design space, and I don't think any small part of it can be easily tweaked without changing a bunch of the rest.

There are not any concrete criticisms I have been able to come up with which are not already at least acknowledged by the proposal. (For instance, the fact that callers may be forced to write name: name.)

So, about the proposal itself? Well, considering the fairly limited scope of the problems it is designed to solve (especially in comparison to other named argument proposals):

  • Providing library authors with an easier (for the author and for the user) alternative to newtypes/builders for a function which faces the problem of, "it can be unclear what this bool parameter is at callsites."
  • Letting a library author provide ::new(bar: ...) and ::new(foo: ...) rather than ::new_bar and ::new_foo

I feel the benefits are unlikely to outweigh the costs in additions to the language:

  • Addition of parameter names to the type system (in particular to fn types and Fn traits).
  • Argument names playing a role in function name resolution.
  • Syntax for:
    • defining named parameters
    • using named arguments
    • qualifying overloaded functions

and thus, I generally wouldn't expect to see it accepted in its current state.

The idea of "named arguments" brings with it a lot of baggage and expectations from other languages, and I get the feeling that many users would be excited to hear "rust is getting named arguments" only to then be frustrated and confused by the restrictions here. "Overloading via named parameters" is perhaps a more direct description of the idea.

22 Likes