Coming from Python I agree that the lack of keyword/default arguments is initially conspicuous, though in practice it seems that library authors seem content to implement builder patterns to work around their absence. While ideally I do think that the builder pattern is less elegant than supporting keyword arguments, in practice it does avoid the unfortunate pattern I've seen in some Python APIs to just cry #yolo and cram a hundred parameters into a single function call. I've never seen a good interface that requires "like 50 different function parameters"; call me zealous, but if I were to design my own programming language, I'd make it a hard compiler error to have more than four parameters to a function. :P
Saying library authors are content with their absence is probably a bit too strong. There's not really another option, and I doubt many folks would choose not to author libraries for this reason alone. I personally have found their absence annoying when writing Rust libraries.
I'd probably be in favor of a hard cap on # of function arguments. :)
But there is another option: a configuration struct, potentially combined with an implementation of Default. Indeed, part of the reason this conversation has gone on so long is that there's one camp who just wants to emulate keyword arguments via additional sugar for structs and Default.
(There's also another another option, which is to have a different function for each combination of parameters. This obviously doesn't scale in the large, but it's perfectly acceptable for functions that take only a single optional parameter, which IME is a plurality of APIs that want optional parameters).
While you can misuse a feature, you don't have to. My example is extreme and you probably don't run into something like that often depending on what you do. There could be other solutions. There surely are other solutions that are neither more clear nor better in any way. Sometimes you just got to do what you got to do. What surprised me about Rust is that it has all those cool features but lacks a very basic one that most programming languages have.
While they may seem basic as a user, designing a language means you need to think about edge-cases. Methods in Rust have some special rules around dispatch, and in order to implement one or both of these features, all of that stuff needs to be considered and designed.
In other words, a lot of work goes into new features, even ones that are easy to use.
In Rust's case, we haven't ruled out adding these features completely, but nobody has put in that work to come up with a proposal. Part of that is that while people tend to see the lack of these features as a mild annoyance, it's not enough to prioritize over other work. We'll see how it all shakes out.
> nobody has put in that work to come up with a proposal.
Features like this mainly need a champion who really cares about getting it into the language & can work with the language & compiler teams to complete that process.
My example of misuse is not to forswear the issue entirely, only to demonstrate that there do exist philosophical objections to keyword arguments. Trust me, I've long been an advocate of keyword/default arguments for Rust. :P The last time that anyone made a push for them was in the run-up to 1.0, when it was decided there were more pressing issues than keyword/default args (alongside a bevy of other features), and the decision to implement them was officially postponed. I might get around to submitting an RFC to revive them sometime this year, though I'm still unsure about some of the semantic details that we might want to consider.
Additional note to static_noise: would you like me to contact you if I eventually revive one of the postponed RFCs for keyword/default arguments, so that you can weigh in? Twitter, Github, etc.?
When a feature is present, without strong disincentives, it will be misused; consider for example matplotlib: many functions have over 10 possible default arguments, and discoverability is almost nil (stack exchange is the place to look for answers).
