I’d love to see a language with structural types where functions are always unary and tuples don’t exist. Every function call would look like either f () (no args), f 1 (one arg) or f (foo: 1, bar: 2) (multiple args, names mandatory).

I started building a language like this but I haven’t worked on it in a while.

Who is even the target audience of this post? Beginners (which included all of us once) ask for all sorts of things. But these features didn’t happen in Rust for a reason.

Named parameters are not needed in the age of LSP hints, where this exists as an editor feature (including (neo)vim).

But if you really want named parameters AND optionals/defaults, rust always allowed the args struct pattern:

struct Args<'a> {
  a: &'a str,
  b: u64,
  c: Option<u64>,
}

impl<'a> Default for Args<'a> {
  fn default() -> Self {
    Self {
       a: "hi", // default
       b: 3, // default
       c: None, // optional default
    }
  }
}

takes_args(Args{a: "not hi", ..Args::default()})

The builder pattern is more about valid initialization, but does interact with the arg struct pattern when you have non-default (forced) arguments, although even then, you can not use it by having:

struct Args<'a> {
  forced_arg1: &'a str,
  forced_arg2: u8,
  defaults: DefaultArgs, // implements Default
}

So mentioning the builder pattern is out of place.

Overloading is not used because we have traits (and the sound subset of specialization for when that’s needed).

So all in all, those “features” didn’t make it to Rust not because of the backlog, or for simplicity’s sake, but because idiomatic Rust (and even modern tooling in general, a la LSP) have alternatives that give you what you want and more.

Everything mentioned above should be known by anyone who knew Rust for more than a month.

Steve doesn’t really elaborate on the drawbacks to the features he listed, just kinda says he doesn’t like them. I’ll do some of that here:

• Function overloading: overload resolution adds a ton of complexity to the language for a feature with API-friendly workarounds (use different names, builders, etc).
• Default/optional arguments: can be confusing when the default value is initialized. For example, in Python, default values are static and reused across calls, meaning you can technically have def foo(a=[]), append to a on each call, and use that data on future calls to foo since the same list is provided as a default each time. In C#, default values are compiled into the caller’s code, meaning if the caller’s code was developed for an older version of a library and you use it with an updated version that has a new default, the caller will still use the old default. And so on, languages all handle defaults differently.
• Named parameters: the article covers some of the biggest issues. There’s also the issue that API designers may not want their parameter names to be part of the API (consider the function is generated by a macro or build script, for example). Also, named parameters imply to new Rust devs that the parameters can be reordered, and it’s odd to have them without optional arguments as well. Then there’s the issue of code inspection (via macro or tool) if you can reorder parameters since you can only inspect source tokens, not query semantic information, so if parameters are reordered then it can become difficult to know which value goes to which parameter from the macro/tool.
• Varargs: to be honest, I don’t really have a drawback for this in mind beyond them just being a fair bit complicated to implement. The C# params Foo[] args equivalent wouldn’t be very useful, but varargs with variadic types would be powerful, just I assume very difficult to implement (for example fn foo<...Ts>(blahs: Ts...) or something, where Ts is a variadic tuple). In any case, that’s a feature many libraries would take advantage of (axum, bevy, etc).

I’m used to named arguments from other languages, and that makes me fairly partial to them. Having to tool around with builders feels a lot more complex and clunky.

That said, I do wonder at how many of the usecases aren’t workarounds for long argument lists that are either stringly typed, or something similar. As in, with a signature of (i32,i32,i32,i32) -> whatever, named arguments seem like a way of getting the compiler to catch errors in confusing {x,y}_{position,length}; but if the signature were newtypes like Rect(Origin(i32,i32), Size(i32, i32)) -> whatever, then the felt need for named arguments drops considerably.

No.

This greatly depends on language design and implementation.

For example, Clojure has all of these and much more, and it’s still much simpler and hassle free than rust. The functions are just functions, but the forms and lists that are very powerful.

functions are just

(defn foo [a b] (print "do thing"))

(foo 1 2)

With the power of destructuring that maps provide us, we can have named arguments:

(defn foo [a & {:keys [b c]}] (print a b c))

(foo 1 {:b 2, :c 3})

and for multi-arity functions, there’s no special syntax. It’s still just plain functions and forms

(def foo
  ([a] (print "I only have one" a)
  ([a b] (print "I have two" a b)))

It also has more advanced ways of polymorphysm with methods and protocols.

It depends on the design of the language.