There definitely is interest. You assume correctly.
Overall, I agree with other posters: this RFC needs to be way more bulletproof. Named arguments are always strongly controversial (I think the civil war on the dlang forums is still ongoing), so any proposal needs to be well defended.
The major contention points I'm aware of are:
Semver implications.
Generally speaking, if you add named arguments to your functions and then change the names, you're breaking semver. This is something some people are very worried about, because they're concerne…
This is my first attempt at an RFC, any feedback is welcome “Wishlist” issue
postponed RFC: keyword arguments
postponed RFC:…
Big detail you've ignored here: how do you facilitate using a "named arguments edition" crate from a "no named arguments edition" crate?
(I believe one of the existing edition requirements is that it should be possible to write code that compiles without warnings on two adjacent editions, so a wholesale switch based on edition wouldn't be allowed per that guideline. But for the sake of the above question, I assume that's a solved problem via using rustfix to update and a system like Swift/ObjC…
opened 10:18PM - 25 Sep 14 UTC
postponed
T-lang
A-syntax
A-typesystem
A-expressions
A portion of the community (and of the core team) sees one or more of the follow… ing features as important for programmer ergonomics:
- keyword-based parameters (as opposed to position-based parameters),
- optional parameters (where one provides a default value for them, usually in the parameter list),
- variable-arity functions (which can be seen as a generalization or variation on optional parameters, depending on how you look at it).
This issue is recording that we want to investigate designs for this, but not immediately. The main backwards compatibility concern is about premature commitment to library API's that would be simplified if one adds one or more of the above features. Nonetheless, We believe we can produce a reasonable 1.0 version of Rust without support for this.
(This issue is also going to collect links to all of the useful RFC PR's and/or Rust issues that contain community discussion of these features.)
rust-lang:master ← iopq:keyword-arguments
opened 10:58AM - 03 Feb 15 UTC
Adds keyword arguments as a separate feature in a backwards-compatible way. The … current functions are unaffected - only arguments declared as keyword arguments can be called this way. Keyword arguments can be mixed with normal arguments. Adds overloading in the general sense without breaking type inference allowing a later addition of sugar for optional or default arguments if this is desired.
I’ve written a review of previous RFCs concerning named & default arguments in Rust. It covers a lot of the considerations of such proposals, reviews the history and then puts forth a more stepwise path to getting named and default parameters into Rust.
I’ve also written a nightly only proc-macro that lets you use write a function, and call it with positional arguments, or calling it in macro form, call it with named arguments. It’s quite limited in scope but I hope to grow it and polish it as …
There's 700+ comments to read there, probably more. As for why things haven't been implemented - there's no consensus on how, or even if they should be implemented. That's why I think macro explorations of this are useful.
I like this summary best of how hairy of a topic this is:
I can't speak specifically about veterans of Swift/ObjC, but requests for named parameters in Rust are certainly nothing new, and there's been loads of detailed discussion in the past. The best place to start is probably:
If the question here is "why haven't we done this yet?" then my personal impression is that the answer is a combination of:
options objects and using enums in place of bools/ints/etc are already good enough for many of the use cases, so the motivation is simply not as pres…
10 Likes