Rust blog post on missing named/optional arguments sparks language-design debate
A developer essay comparing Dart, C#, TypeScript and Rust argument syntax draws a detailed Lobsters thread on how Rust might add the feature.
What to know
- Rust currently has no native named or optional function arguments; common workarounds use verbose Default-implementing structs that only work when every parameter has a default.
- A blog post comparing Dart, C#, TypeScript, Python and Rust's handling of the feature drew a large Lobsters discussion after a quieter Hacker News posting the day before.
- Commenters largely agree Rust's situation is weak and cite Swift, Objective-C, Gleam and OCaml as languages with well-designed separation of internal parameter names and external call labels.
- The main point of contention is whether parameter names should automatically become part of a function's public API (risking breaking changes on rename) or require an explicit, opt-in design.
The dispute Whether parameter names should automatically become part of a function's public API (Python-style) or be explicitly opt-in per argument (Swift/Gleam/ObjC-style), given the breaking-change risk of the former. · positions read across 40 posts and comments
Rust should get named/optional arguments; current struct-and-Default workarounds are painful
-
“I would be so happy if this rfc got implemented. I regularly wish for named and optional parameters in my own code, and I get extremely tired of wading though dozens of similar-but-not-quite functions on docs.rs to find the one that I need.”
drmorr · Lobsters ↗
Other languages already show good models — Swift, ObjC, Gleam and OCaml separate internal names from call-site labels
-
“Swift's approach to this is pretty neat, it separates internal parameter names and external argument labels, so you can rename the parameter without affecting the argument, and the other way around.”
masklinn · Lobsters ↗
Named parameters as public API should be opt-in, not automatic, to avoid fragile breaking changes
-
“I would certainly not want any functions currently written suddenly be callable with named args because then all of a sudden changing an argument's name is a breaking change for crate authors. This would have to be explicit on the part of…”
ekuber · Lobsters ↗
Existing crates like bon already cover much of this need without a language change
-
“https://crates.io/crates/bon Is a good option for some of these use cases. But it's not a thing I would build a public crate interface on/with.”
schneems · Lobsters ↗
botahamec Blog authorekuber Lobsters commenterschneems Lobsters commenter
How it unfolded 5 developments, newest first · click a bar or a number to jump postscomments
-
5
Thread compares named-argument designs in Swift, ObjC, Gleam and OCaml
Commenters describe how Swift, Objective-C, Gleam and OCaml separate internal parameter names from external call-site labels, offering possible models for a future Rust design.
“Swift's approach to this is pretty neat, it separates internal parameter names and external argument labels, so you can rename the parameter without affecting the argument, and the other way around.”
— masklinn -
> it makes parameter names part of the public API of the function, I really like the way gleam (and swift too I believe) goes about this. The public parameter name has to be picked explicitly rather than all arguments being named automatically. ```gleam pub fn replace( in string: String, each value: String, with replacement: String, ) -> String {…
2 more of the top 3 · 34 posts in this stretch
-
I'm unsure why the parameter names being part of the API is presented as a problem? It's literally the point of feature. You just need to make sure that the syntax permits the implementation to use a different name, because it's the implementation - this is something that objective-c and swift both support, which means APIs are often written as…
-
> it makes parameter names part of the public API of the function, After using Python's equivalent (keyword arguments) and Ada's equivalent (named parameter associations) quite a bit, I went from "parameter names being part of the API is bad" to "perhaps this isn't a bad idea." You're forced to think more about clear parameter names, which…
-
-
4
Commenters debate API-stability risks of named parameters
Some argue making parameter names part of the public API would turn renaming into a breaking change, and suggest any such Rust feature should be explicit and opt-in for API designers rather than automatic.
“I would certainly not want any functions currently written suddenly be callable with named args because then all of a sudden changing an argument's name is a breaking change for crate authors.”
— ekuber -
OCaml’s [labeled & optional arguments](https://ocaml.org/docs/labels) using `~` + `?` sigils is pretty novel in the functional space. I ended up liking it quite a lot ergonomically since a) you can easily forward along arguments, but also the labels can be alias for the scope meaning you don’t need to come up with argument names! A trivial…
2 more of the top 3 · 4 posts in this stretch
-
THIS. (And Swift also does named/optional parameters well, IMO.) This has been one of my pain points in moving from Swift to Rust.
-
I like ObjC's solution: ``` example(named: 1, arg: 2) ``` desugars to something like: ``` example_named_arg(1, 2) ``` The arg order is fixed, but Rust's syntax error can suggest autofix. Lack of support for all the possible permutations is a plus: makes it harder to go wild with overly configurable methods. It doesn't need any new object types. It…
-
-
3
Commenters cite existing Rust workarounds like the bon crate
Lobsters users note that crates such as bon already provide builder-style named arguments for Rust, though some are wary of exposing them in public crate interfaces.
“https://crates.io/crates/bon Is a good option for some of these use cases. But it's not a thing I would build a public crate interface on/with.”
— schneems -
https://crates.io/crates/bon Is a good option for some of these use cases. But it’s not a thing I would build a public crate interface on/with.
1 more of the top 2 · 2 posts in this stretch
-
I would be so happy if this rfc got implemented. I regularly wish for named and optional parameters in my own code, and I get extremely tired of wading though dozens of similar-but-not-quite functions on docs.rs to find the one that I need. On the flip side, as soon as you introduce optional parameters you open the floodgates for something like…
-
-
2
Essay resurfaces on Lobsters
The same essay is submitted to Lobsters a day later and generates a much larger, more technical comment thread comparing language designs.
-
1
Essay submitted to Hacker News
The post appears on Hacker News with a small early discussion (2 comments).
“Whenever someone asks what my least favorite part of Rust is, my answer is always the same: it doesn't have named or optional arguments.”
— botahamec, blog author · source -
background
botahamec publishes essay on Rust's missing named/optional arguments — The post argues Rust is the hardest of several tolerated languages to get named arguments out of, and walks through how Dart, C#, TypeScript and Rust each handle (or fail to handle) named and optional parameters.
What people are saying 16 voices from 1 site · best of 40 · verbatim
- Would a hypothetical Rust RFC for named arguments apply automatically to existing functions or require explicit opt-in?
- Which existing-language model (Swift/ObjC label separation vs. OCaml's ~/? sigils vs. Python-style keyword args) would fit Rust's stability guarantees best?
- Yesterday
-
*This* is what I mean when I talk about "syntax has to be orthogonal, one should be able to extrapolate from one language feature how another will work". I don't think it is the nicest syntax, but it *fits with the rest of the language*. It honestly looks like a sensible way of going about this. I suspect that it will be hard to actually get named…
- Sep 22
-
The author highlighted the exact "function which takes arguments of types that can be confused" case! Examples were given of, for example: ```rust // Without named arguments: what are these numbers? solar_elevation(1787517098.0, 38.897957, -77.036560) // With named arguments, it's obvious solar_elevation(timestamp: 1787517098.0, latitude…
-
enum Bold { Yes, No }; enum Italics { Yes, No }; enum Underline { Yes, No }; fn print(text: &str, bold: Bold, italics: Italics, underline: Underline) { ... } print("asdf", Bold::No, Italics::No, Underline::Yes);
-
> Parameter names being part of the API isn't so bad, but default values being part of the API can result in some unexpected behavior. For example, if you have some sort of compute(a, b = 10) function where b = 10 indicates an optional argument with the default value of 10, changing that default to e.g. 20 could produce unexpected results. I don't…
-
In my reply to @masklinn I realized that if the named parameters are optional - e.g the same function can be called with or without named parameters that is a giant - and real - footgun. In swift, objc, smalltalk the named parameters are not the variable names - swift allows that as a short hand (and has syntax for no parameter name). E.g func…
-
> When it’s implicit / opt out / default it is a routine problem because you declare an API without knowing it. That's not my experience in the context of objective-c and swift: it's well understood that the parameter names are part of the function name. It may be more difficult if you start from a PoV that the parameter names are simply…
-
I fully agree that named and (named) optional arguments would be awesome to have in Rust. I do not have a strong preference for what that syntax should look like. (I generally care much more about semantics than syntax.) But that `spawn` example reminds me of Python, and it's not a good memory. Every time I need to spawn a process in Python I…
-
> I'm unsure why the parameter names being part of the API is presented as a problem? When it’s implicit / opt out / default it is a routine problem because you declare an API without knowing it. It’s a relatively common problem in Python where the default argument mode is that they can be passed by position or keyword, and people routinely do not…
-
> I'm unsure why the parameter names being part of the API is presented as a problem? I think the problem is when the label is the internal name. Then, if you don’t have a way to choose which ones are public and which private, changing a parameter name breaks the public API.
-
I think comparing with dynamically-typed languages is not optimal. With dynamically-typed languages, named parameters are nearly mandatory otherwise things are too error-prone. With statically-typed languages, I think any function which does not take arguments of types that can be confused is automatically fine. And functions with many arguments…
-
Although it looks exactly like just a language shortcoming, and the typical golang excuse "it's by design", I have to admit that I think that rust is okay without named nor optional arguments. Less god functions. It also forces you to think twice before bolting on (yet) another optional variant.
-
It takes a little bit of getting used to but I cannot understate how much it improves code readability. I have never had to consult the docs when reading someone else’s Objective-C code to see what the parameters meant to a function. I can’t say that about most other languages.
-
I'm not sure I buy that it's so terrible to wade through n different functions with all the variations of input parameters. If, instead, it were one function with behavior dependent on something like kwargs, one still has to mentally wade through the implicit variations of the function. I'd much rather go through an explicit list produced by the…
-
[Gleam has the same feature.](https://tour.gleam.run/functions/labelled-arguments/) Not sure whether it's inspired by or independent of Swift's.
-
In ObjC, the name and the label are separate, so you things like: - (NSString *) stringByPaddingToLength:(NSUInteger) len withString:(NSString *) pad startingAtIndex:(NSUInteger) idx; which you'd call something like: [str stringByPaddingToLength: 123 withString: @" " startingAtIndex: 10] the variables inside the function are named `len`, `pad`…
- Sep 21
-
If Rust ever gets this I'd rather it used an anonymous struct as an argument instead. I would certainly not want any functions currently written suddenly be callable with named args because then all of a sudden changing an argument's name is a breaking change for crate authors. This would have to be explicit on the part of the API designer instead.