Proposal: Replace _ with unused keyword

[SpexGuy]

Zig currently uses _ in five places:

• marking a parameter as unused (fn foo(_: u32) void)
• marking an expression value as unused (_ = func();)
• marking a named variable as unused (_ = variable;)
• marking an enum as extensible (enum (u8) { _ })
• declaring a padding field (_: u6,)

This proposal is to replace the first three uses with a new keyword, unused. It behaves as follows:

• On parameters, fn foo(unused index: u32) void

Allowing a name here can improve documentation, and make it easier to notice if the parameter is actually needed. However, sometimes names are not needed, so we could also allow the syntax fn foo(unused: u32) void. Since unused is a keyword, this is not shadowing and can be properly identified by the parser.

• On locals, unused can be used in the place of const or var. As in,

unused result = func(); // result can be named for better documentation
unused = func(); // name is optional
unused result: u32 = func(); // type annotations are also allowed
unused: u32 = func(); // even without a name

unused = variable; // this could be a compile error if `variable` is a local or parameter, unused should instead be placed on the declaration of variable.

As you might expect, attempting to use a variable declared as unused is a compile error.

This change is breaking, but zig fmt would be able to perform most of the update correctly.

After this change, _ would be used exclusively for extensible enums and padding fields.

[ikskuh]

I like this very much.

[andrewrk]

unused = func(); // name is optional
unused = variable;

can you share more about why this and not:

unused func(); // name is optional
unused variable;

edit: ah I see it's kind of like a variable declaration without the type.

[SpexGuy]

Yeah I think that might be ambiguous, but if you think it's cleaner I'm open to it.
Edit: The specific case of unused variable; could be a compile error, which would resolve the ambiguity from a reader's perspective. Whether it's ambiguous for the parser is a different question.

[spenczar]

I suggest that other variable modifiers should be illegal when in front of unused. That is, const unused = func() should result in an error during parsing. Same with var.

This would make it clearer to users that they shouldn't use unused as a plain variable name. It would help clarify that something like this is totally forbidden:

const parking_spaces = ...
const unused = checkForVacancies(parking_spaces);

[spenczar]

I think it would be clearer for unused to be a modifier, and not an identifier. If it's just a modifier, then things like unused result = func() are allowed, but not unused = func().

Identifiers have tons of places where they are normally legal, but it's not clear how they'd work with unused:

• return unused
• val == unused
• array[0..unused]
• unused => 10 in a switch

These all seem like they clearly should be illegal. unused isn't really like a normal identifier, and making it one seems a little inconsistent. That inconsistency could be avoided by making it a modifier like const.

[ifreund]

The _ = foo; syntax is also used to reference decls so that they get analyzed for unit tests. I think this change would make this use case read much worse. I do think it is an improvement for function parameters though.

[iddev5]

I generally like this idea but don't like the suggested syntax.

Under the current syntax, you just do _ = foo and _ = bar(). It just simply means that you don't care about what it returns, let alone what type it is. I do not get why "optional name and type" is suggested here. It makes it look like the same keyword is being used as an identifier as well as a modifier. My preferred syntax is the one andrew was talking about, i,e

unused foo;
unused bar();

which makes it more familiar and similar to the current syntax. Yes it does not allow tagging the type or having a name, but I don't see what benefits it provides. Let me know.

[Mouvedia]

This has the added advantage of freeing _ for #5893
see @Rocknest's proposal

[raulgrell]

Does this also affect the capture syntax?

for (values) |_ , i| print(i); ->
for (values) |unused , i| print(i);

if (maybe) |_| "Not null" else "Null"; ->
if (maybe) |unused| "Not null" else "Null";

if (trySomething()) |_| "Success" else |_| "Error"; ->
if (trySomething()) |unused| "Success" else |unused| "Error";

[apppppppple]

imo this change would make code harder to read - I feel like personally I'd be more likely to miss yet another key word when reading over code compared to something that looks more like a symbol, and the behavior of _ seemed pretty logical (but that might just be me).

[nektro]

unused as a word has no effect on control flow. I don't particularly see the problem with leaving things as _, particularly when adding another keyword for this might make it look like part of the variable name.

also seems odd this got the accepted label even when there were open questions