Commenters highlight tooling and alternative solutions to argument confusion
3 Sep 22 8:55 AM · 1d ago · 8 comments · 1 source · development 3 of 3
Several commenters raised practical counterpoints: lpil noted that language servers like Gleam's can automatically fill labels; cceckman argued that IDE inlay hints already provide the readability benefits Klabnik seeks; pushcx suggested newtypes could prevent bugs from positional integer arguments.
“language servers can handle labels for you. Gleam has labelled arguments, and I rarely write them. Instead I run the "fill labels" code action”
lpilSteve Klabnik Programming language designer, Rust community member
The whole story postscomments the bright band is this development · numbered dots are the others · click one to jump
What people said 24 voices · best of 38 · verbatim
-
I wonder how much of the "improved readability" would go away if review interfaces supported LSP inlay hints as something you could toggle on. I write Rust in my day job. When writing code, or reviewing in my editor, I am rarely confused by "which argument is this" because `rust-analyzer` tells me; in fact, it uses the same `parameter: ` syntax as…
-
> The defaults for these are different: get is checked, split_at is unchecked. `split_at` is not unchecked, and “checked” and “unchecked” aren’t opposites here, because there are two types of checked. The three types are: checked non-panicking (returns `Option`), checked panicking (returns `T` or panics), and unchecked (returns `T` and is…
-
Or newtypes. I haven't done graphics programming for a long while, but looking at this call I remember how easy it was to introduce bugs when function calls had positional arguments that were all the same integer type, even though one pair is position and another is dimension. If this wasn't in a generic graphics library but a desktop GUI library…
-
> For the simple cost of “write two different names for your functions,” you get to keep the rules very simple: there is one function definition, and you invoke it by name. Done. There's a hidden cost to these things: name confusion and discoverability. Rust has this explosion of functions that do slightly different things with also slightly…
-
Excellent post. Some remarks: > But it can be common to break truly complex examples down into variables that we end up forwarding to the function, and then it becomes verbose and redundant. As an example from inside FastAPI where get is invoked directly with all of those options: > > ``` > self.router.get( > path, > response_model=response_model…
-
Agreed, not a substitute for good code. "More readable" is relative and contextual, though; an argument name may be sometimes-useful and sometimes-noisy, depending on my state of mind when I'm reading it. As an analogy: I don't necessarily want to litter my code with type annotations that could be inferred, because sometimes it's obvious / doesn't…
-
> [labelled arguments do] really increase readability, no question about it. But for me, typing all of that out just isn’t really super worth the squeeze. But when Claude is gonna write it? I care a lot less. AI aside, language servers can handle labels for you. Gleam has labelled arguments, and I use them often, but I rarely write them. Instead I…
-
In my opinion, the only fully orthogonal, consistent, way to implement default arguments would be to introduce an args type for every fn type, so that `fn foo(a: i32)` introduces a `struct { a: i32, b: f32}`, that could be named via `::Args`. Then the second part would be to allow implementing traits through type aliases: `impl Default for…
-
Having done all these over the years with Python, C, Fortran, Kotlin, Swift, Elixir, I still like the Smalltalk keyword syntax best (https://book.gtoolkit.com/understanding-smalltalk-message-syntax-w9fc37am75ozp0rrdb5xftjo). It communicated the best (imo), because it weaves the parameterargument binding without the overhead of a function name as…
-
Agreed on +named -optional, personally. I've wished for named a few times. Never needed optional, and personally hope they don't land.
-
> but get can take 23 different keyword arguments, and so this could get quite, quite long. I noticed that only the named argument side with 23 parameters was shown. The unnamed version might be more concise but is less understandable. You could argue that IDEs will annotate your code, at which point “concise” is no longer a virtue. > But what you…
-
Edit: I missed that you said "anonymous". Honestly the code below doesn't bother me, even if it's more verbose. I do think that being able to omit the struct name would be fine though. Doesn't Rust have this? It's just more verbose. ```rust let cropped = crop_imm(CropImg { x: 10, y: 20, width: 200, height: 100, ..Default::default() // brings in…
-
> I think Rust could be okay with named parameters, but not optional or default ones. Interesting position. That would certainly prevent the dreaded "god functions" like Python's process spawning, or the `get` example from the post. OTOH, omitting a sequence of pointless `None` would be very useful. Maybe optional arguments should be *required* to…
-
Yes, that was a conscious constraint, although there are many people that (rightly!) are annoyed by that restriction. Bevy for example would love to have arbitrary expressions be auto-inserted. I am considering restricting the default values to always be surrounded by `const { ... }` before we stabilize, as a way to keep the syntax open for…
-
> Would you agree that if this inferred default .. works on anonymous structs, it should also work on named structs for consistency? https://doc.rust-lang.org/unstable-book/language-features/default-field-values.html Structs will be able to be constructed with `Foo { .. }` if `struct Foo { field: i32 = 42 }`. It makes sense that structural structs…
-
I see. It's not an unreasonable feature to ask for, although I don't think it's necessary. Maybe a middle ground would be to default-import `Default::default` in the prelude, such that `..default()` is enough. Would you agree that if this inferred default `..` works on anonymous structs, it should also work on named structs for consistency?
-
I think one implicit assumption is that no one will create such a monstrosity with required/positional parameters (I say, an hour or two after seeing an MR where someone added a 20th parameter to a Java method).
-
Ah, I didn't know about this feature being worked on, thanks. I like that it requires the default field values to be `const`, this means that `SomeStruct { .. }` won't execute arbitrary code, IIUC.
-
This is fair. At the same time, every syntax was novel at one point in time, but people can and do learn it.
-
> self.router.get( > path, > =response_model, > =status_code, > // ... > ) The problem with syntax like that is that there's *nothing else* in Rust that uses that syntax, so it is confusing when seen for the first time and won't be discoverable by someone extrapolating what they already know of the language's syntax and semantics.
-
Yeah, I think the piece doesn’t do enough to acknowledge that some form of builders/optional/default arguments ends up being a requirement for certain types of libraries where “just upgrade and change every call site” is a bad idea.
-
> A little syntax sugar you can add is to allow omitting the argument name if the value is a identifier expression with the same name, like: I love this feature in ocaml and would really like to see it added to python some day.
-
Honestly the lack of named arguments is **probably** the thing I dislike about rust the most. I love rust, but I miss named arguments all the time.
-
Rust has been shaped by an explicit focus on producing a language that remains approachable to people who have nothing more than a dumb text editor (possibly with syntax highlighting). Pointing to coding agents is an expression of a "the IDE can pick up the slack" sentiment that Rust was explicitly designed to *avoid*. (And, to be honest, given I…
All 3 developments of Steve Klabnik on Rust's resistance to fancy argument… →
Hacker NewsLobsters