Better convention for ignoring function params

[fengb]

When working with function pointers, it is often necessary to conform to an existing signature without needing to use the parameters.

Currently we have 2 options:

fn foo(_: []const u8, _: []const u8) void {
}

There's a few problems with this approach:

1. Declares a real _ variable that shadows the throwaway variable. Possibly resolved by #1802
2. Hides the intent of the variable. In more generic codebases like build tools, this often becomes a problem when argument names are not readily available.

Another approach is explicit ignoring:

fn foo(name: []const u8, signature: []const u8) void {
    _ = name;
    _ = signature;
}

1. If this variable is used later, this hint is now misleading. Fixed by #9238
2. If there are lots of unused arguments, there will be lots of superfluous lines. This hides intent instead of exposing it, especially if some arguments are used and it takes a matching game to locate the specifics.

Solution

I propose a new convention to solve both usecases of documenting the consumer behavior and indicating non-usage:

fn foo(_name: []const u8, _signature: []const u8) void {

[andrewrk]

I veto identifier names having any semantic meaning.

[ghost]

I veto identifier names having any semantic meaning.

Then how about this:

fn foo(_(name): []const u8, _(signature): []const u8) void {}

That is, once _ becomes a keyword, allow it to take an optional name in parentheses for purposes of documentation and introspection.

[ekipan]

Currently _ is permitted as a parameter name. This seems like a bug, since you can only use it once and it cannot be referred to within the function.

Personally I'm not convinced having a name for an unused parameter that you have to _ = name is useful enough to tolerate the potential bugs, but unless that changes perhaps _ in a parameter list should be a compile error.

[bb010g]

#1802 (comment) (and #6062) establish that _, an identifier name, has a semantic meaning of "discard" when written without raw identifier syntax, i.e. @"_" does not have that special semantic meaning. _ is also not a keyword.

_foo could also have a semantic meaning of "discard" due to its being prefixed by _, and @"_foo" could not have that special semantic meaning, just like with _. _foo would also not have to be a keyword. If this was implemented, _ becomes the shortest example of the rule that non-raw identifiers with a first byte/character of _ invoke discard semantics, while raw identifier syntax (@"_…") avoids invoking discard semantics. There will still only be one rule to learn for identifiers that mean discard.