In ["Arguing about arguments"][klabnik], Steve Klabnik is open to labels on
existing parameters, `foo(x: 5, y: 6)` for `fn foo(x: i32, y: i32)`, but not to
optional or default arguments, because they hide what a call passes. They also
list what makes named arguments hard in Rust specifically. Parameters are
patterns and may not have a name, `fn` pointers erase names, trait impls can
rename parameters, reordering arguments raises the question of evaluation order,
and every parameter name quietly becomes part of the API.
Klabnik's objection to defaults is fair, and the answer is that making names
explicit is what lets defaults be safe. Fields are named only because the
function put them in a struct, and they can only be passed by name, so there's
no positional form to swap and no argument left out of the middle of a list,
`f(a, c)` for `f(a, b = 0, c)`. Defaults are owned by the function
(by the trait, for a trait method), and a call that relies on them says so
with `..`, with or without the [sugar](#defaults-fa-x-1-). Adding a parameter
is also safe, since a new field with a default doesn't break callers that wrote
`..`.
Where Botahamec opts parameters in with `pub`, Klabnik doesn't opt them in at
all, and that's the bigger difference. If every parameter can be labeled, the
function's author can no longer decide how an argument is passed. Labels would
have to be optional for existing calls to keep compiling, so `copy(a, b)` still
compiles, and there's no way to require names for arguments that are confusing
by position, like `from` and `to`. That's the whole point of naming them. With
anonymous structs the author decides. Positional parameters are passed by
position, fields are passed by name, and the signature shows where one ends and
the other begins, so `copy(_ { from: a, to: b })`, or `copy(from: a, to: b)`
with the sugar, is the only way to call `copy`.
The other problems are secondary. Every parameter name in every published crate
would become API after the fact, including names chosen only for the function
body, like `buf`, `_x`, hygienic macro names, and bindgen's `arg1`, so renaming
any of them would break someone. Each parameter would also get two APIs, since
reordering breaks positional callers and renaming breaks labeled ones, and
mixed calls would need new rules for which slot a positional argument fills
after a label.
The rest of Klabnik's list already has answers, because each has an existing
struct rule. None of these are new to Rust. Here's how anonymous structs handle
each one.
#### Evaluation order
{:.no_toc}
Fields are evaluated in the order written at the call site, as in any struct
literal. So this compiles:
```rust
fn consume(struct { data: Vec, length: usize }) { .. }
consume(_ { length: data.len(), data: data });
```
and swapping the two is a use-after-move error, exactly as it would be for a
named struct:
```rust
consume(_ { data: data, length: data.len() });
// error[E0382]: borrow of moved value: `data`
```
#### Patterns as parameters
{:.no_toc}
Klabnik points out that a Rust parameter is a pattern, not a name.
`fn foo((x, y): (i32, i32))` introduces two bindings, so there's no single name
to label the argument with, short of inventing separate external and internal
names.
Anonymous structs don't need either. Only fields are passed by name, and a
field always has one, which is its label at the call. With an [elided
pattern](#elided-struct-patterns) it's also the binding in the body, and when
the body wants a different name, an explicit `_ { .. }` pattern renames it like
any struct pattern. Positional parameters keep their patterns, since they're
never passed by name.
```rust
fn foo((x, y): (i32, i32), struct { scale: i32 = 1 }) -> i32 { .. }
fn bar((x, y): (i32, i32), _ { scale: s }: struct { scale: i32 = 1 }) -> i32 { .. }
foo((1, 2), _ { scale: 2 });
foo((1, 2), _ { .. });
```
#### Defaults
{:.no_toc}
Defaults are RFC 3681 defaults. They're declared on the field, and used when
the caller writes `..`. They can use the function's type and const parameters
(`fn foo
(struct { bar: usize = A })`), and associated consts
through their bounds (`fn foo(struct { n: usize = T::N })`).
#### Renaming hazards
{:.no_toc}
A field's name is part of the function's API, the same as a public struct field
([Section 1](#api-evolution-and-semver)). Positional parameters are unaffected,
so a function opts in, one parameter at a time, by moving it into the struct.
Nothing becomes API by accident, and a typo like `widht` gets the same error,
with the same suggestion of `width`, as it would in any struct literal.
#### Trait impls
{:.no_toc}
An impl can't rename fields. It repeats the trait's fields by name, in any
order, and a renamed field is an error ([Section 2](#traits)). It has to be
that way, since callers through generics and `dyn` only see the trait, so the
trait's field names are the ones they write.
#### `fn` pointers
{:.no_toc}
A function used as a value keeps its anonymous structs as parameter types, so
names survive through the pointer, and so do defaults:
```rust
fn foo(struct { a: i32, b: i32 = 10 }) -> i32 { .. }
let g: fn(_) -> i32 = foo;
g(_ { b: 2, a: 4 });
g(_ { a: 5, .. });
```
Two functions with the same fields don't share a pointer type ([Section
5](#function-types)), though the upcoming [follow-up
post][follow-up-function-types] will sketch one way they might.