Yes, this is one of the few things that I think was a big mistake in Rust's language design. I used to do a lot of Scala, and really liked named parameters there.

I suppose it could still be added in the future; there are probably several syntax options that would be fully backward-compatible, without even needing a new Rust edition.

I suppose the sense it is backwards incompatible is that library authors have named their parameters without intended to make them part of the public interface that they commit to maintaining. Perhaps it could be made backwards compatible by being opt in function declarations but that would seem like a bit of a pain.

When there are 3-4 parameters it is too much trouble to write the names.

Not OP, but I imagine he's arguing for something like python's optional named arguments.

> When there are 3-4 parameters it is too much trouble to write the names.

Sorry, I don't agree.

First, code is read far more often than written. The few seconds it takes to type out the arguments are paid again and again each time you have to read it.

Second, this is one of the few things that autocomplete is really good at.

Third, almost everybody configures their IDE to display the names anyway. So, you might as well put them into the source code so people reading the code without an IDE gain the benefit, too.

Finally, yes, they are redundant. That's the point. If the upstream changes something and renames the argument without changing the type I probably want to review it anyway.

Making something longer doesn’t make it easier to read, especially in repetition.

Making something explicit does.

Would it be better if you wrote out the type of every variable every time you used it? That would be more explicit.

They aren't even necessarily redundant. If you have argument names as part of the function name, they can be overloaded on - and this is much more readable than type-based overloading because it's all explicit. Swift uses this to great effect, e.g. here are some different ways to construct a string:

   String(repeating: "foo", count: 42);

   String(cString: zeroTerminatedBuffer); 

   String(42, radix: 16);

   String(contentsOfFile: "foo.txt", encoding: .utf8);

Oooh. Nice. I forgot about the Smalltalk / ObjC / Swift usage of keywords for messages.

Why? In 2025 we have tooling available for most every editor that will annotate that information into the display without needing them present in the file. When I autocomplete a function name, all the parameters are there for me to fill in, and annotated into the display afterwards. It seems like an unnecessary step to reify it and force the bytes to be present in the the saved file.

So those editors could just insert the names for you. The bytes in the source file are not a serious concern, are they?