Do you need to say `= {}` on the last syntactic parameter default to make it entirely optional?

[lnihlen]

Summary of issue:

Context in this proposal and the 2026-07-16 open discussion minutes. See the proposal for a working definition of syntactic parameters (vs. semantic).

Also please note the syntax of the default values for de-structured member variables is discussed in the proposal and also in leads question #7530.

Given this function that provides default values for fields inside the de-structured second parameter:

fn A(index: i32, {key: i32 = 0, value: i32 = 0});

The question is if a call that omits the second argument entirely, such as:

A(1);

Should compile without error, or should we require the programmer to specify that we accept an absent struct with an additional = {} as a default value on the second parameter, as in alternative B here:

fn B(index: i32, {key: i32 = 0, value: i32 = 0} = {});

Also note that the B alternative presupposes we would accept {} as a valid match to a struct function parameter with default values for every indicated member, meaning that this call would compile successfully:

A(2, {});

Details:

Note that we do not allow, currently, the following:

A(3, {.something_else = 42});  // ERROR

With the reasoning that there is already syntax to allow other members in the struct, using the , _ from in the parameter:

fn C(index: i32, {key: i32 = 0, value: i32 = 0, _});

Which would then allow example 3 to compile.

Any other information that you want to share?

No response

[lnihlen]

From my perspective, this question is about the interaction with the additional fields specifier , _ and if the various options create any meaningful distinction if we do not presume the = {} is the default behaviour.

Assuming we require the = {}, these are examples of some of the possible combinations:

// Requires a struct with exactly 2 members, named `key` and `value`.
fn D(index: i32, {key: i32, value: i32});

// Requires a struct with 2 or more members, two members must be named `key` and `value`.
fn E(index: i32, {key: i32, value: i32, _});

// Requires a struct with zero to two members, names must match `key` and `value`.
fn F(index: i32, {key: i32 = 0, value: i32 = 0});

// Requires a struct with any number of members and names.
fn G(index: i32, {key: i32 = 0, value: i32 = 0, _});

// Invalid syntax, default values are not specified for `key` or `value`.
fn H(index: i32, {key: i32, value: i32} = {});  // ERROR

// Invalid syntax, default values are not specified for `key` or `value`.
fn I(index: i32, {key: i32, value: i32, _} = {});  // ERROR

// Accepts an optional struct with zero to two members, names must match `key` and `value`
fn J(index: i32, {key: i32 = 0, value: i32 = 0} = {});

// Accepts an optional struct with any numbers of members and names.
fn K(index: i32, {key: i32 = 0, value: i32 = 0, _} = {});

The question of requiring the = {} boils down for me to the question of if there's a useful distinction between F and J, as well as G and K, and if that distinction is useful enough to tolerate the possibility for the author to write fail states H and I, which would not be possible to write if we always presume a default initializer for any struct that has all members defaults specified.

My personal opinion is that this is not a useful distinction and that we should always accept an omitted struct argument for any function with a struct parameter whose members all have default values.