Rust team member signals work on default field values feature
3 Yesterday 4:49 PM · 19h ago · 9 comments · 1 source · development 3 of 6
An ekuber, identified as a Rust contributor, comments that default field values are being stabilized and should ship before year-end, with only one semantic blocker being actively worked on. This development suggests the language may address one of the workarounds discussed in the essay.
“I plan on stabilizing that before the end of the year. There's only one blocker around semantics and it is being actively worked on.”
ekuberitamarst Rust developer / authorSteve Klabnik Rust contributor (referenced)ekuber Rust team member
The whole story postscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 8 voices · best of 9 · verbatim
-
Back when I was first implementing restructuring assignment in JavaScript I realised that it made named arguments* really nice: function f({x, y, z}) { … } That said I’m not super keen on the struct based approach in strongly typed language as it means _every_ function starts needing its own type specified. I don’t think the argument that the type…
-
My IDE that shows me parameter names at any call site. Whatever "friction" the author is depending on to enforce their idea of good taste isn't there with the right tooling. It would still be nice if Rust directly supported named parameters. In both posts, it also seems assumed that if Rust gets named parameters then argument defaults and function…
-
Right - the examples in the article (things like Size, etc) are reasonable, but in many cases that's not what you have so you litter your API surface with myriad single use structs. The more I think about it, the more I realize is that the problem is the labeled parameters are seen as a property the parameter, rather than as part of the _function…
-
I do many/most of these things all the time. Is that not normal? Actually, when I first opened Steve’s article I expected it to read more like this one!
-
I've written something similar years ago
-
> An optional argument is, to some extent, an argument which may or may not exist. Rust has a type for that. A thing I’m missing is to have a mix of required and optional fields in a struct. When you mark it Default ALL fields must provide a default and that also makes those types less useful (fewer guarantees). Or you end up having to wrap things…
-
It’s not about parameter names. It is about semantics. Are these functions operate on the same semantical entity? If yes — share!
-
> every function starts needing its own type specified Vulkan API does that and it's kind of OK.
All 6 developments of Rust dev argues structs beat named arguments for API design →
LobstersHacker News