Syntax: clarification on "unused" keyword placement

[burakemir]

Summary of issue:

The accepted proposal PR #2022 Unused Pattern Bindings introduces a new keyword "unused" which should be placed right in front of a name.

Since then, there have been some changes to binding patterns.

Can you confirm that the choice that unused should be right in front of the name (not patterns) still holds?

Details:

The proposal text says only names and not patterns should be in scope of the unused marker.

Is this still our choice?

Consequently:

• one would write ref unused name x: i32 to get a name marked as unused.
• writing unused ref name x: i32 would be a parse error.

An additional minor question:

• When someone uses both markers in a binding, e.g. unused _ : i32, should there be a warning that says that the unused keyword has no effect on _?

EDIT: adding three more clarification questions:

• Question 3 - If I have fn F(o: C) { var _ : o.Inner }, we should still consider o unused, correct?

• Question 4 - There is a check to ensure implementations are the same as interface methods. I believe this check should skip over unused markers. Can you confirm?

• Question 5 - Can you confirm that "unused" markers do not seem to make sense on interface methods, as they should not be part of contract. Should we flag this as error?
  To put it more neutrally: if we do not update the check, then "unused" on an interface of virtual method declaration will force implementations to have unused markers, and thus force the parameters to not be used. This seems undesirable?

Any other information that you want to share?

No response

[zygoloid]

We also need to decide the relative position of unused and each. In that case, I think our position is that each x is effectively the name of the parameter, so each should bind more tightly than unused.

For ref versus unused, I think it's probably useful to consider the behavior of var, which I expect people will think of as the same category of modifier as ref, even though var is a pattern operator and ref is not. Because var is a pattern operator and currently unused is not, var presumably goes before unused, so we have a choice of:

fn F1(var unused a: i32, ref unused a: i32);
fn F2(var unused a: i32, unused ref a: i32);

... and F1 seems like the better choice to me, if we only allow one of those.

So I think I want to narrow the options down to three:

• 1: [ref] [unused] [each] name: type.
• 2: ref and unused can go in either order, but precede each. (unused ref, ref unused, var unused are OK, but unused var is an error.)
• 3a: unused is a pattern operator and applies to all the bindings within it. (unused var, var unused, unused ref are OK, but ref unused is an error.)
• 3b: As 3a, but ref is also a pattern operator and applies to all the bindings within it, so we also allow ref unused. (But see Immutable value semantic returns questions from #5434 #5522 (comment) which argues that ref in a pattern should apply tightly to a binding.)

Of these, I think I prefer 3 and 1 over 2, with a slight preference for 3 over 1. I think it's at least a little useful to allow unused to scope over multiple bindings, even though that will make it harder to see that the bindings are annotated as unused. For example:

base class Turtle {
  virtual fn MoveTo[self: Self](unused (x: i32, y: i32)) {}
}

When someone uses both markers in a binding, e.g. unused _ : i32, should there be a warning that says that the unused keyword has no effect on _?

I think we should diagnose if an unused keyword does not apply to any bound names (either because the binding specifies _ or because we're in case 3 and there are no binding patterns in the subpattern). I'm not sure whether we want that diagnosed as an error or warning or some kind of lint; I don't think we've established a policy for that yet (though I wrote a proposal [edit: updated link to point to our public docs] a few years back).

[zygoloid]

Another argument in favor of option 3: ref being closer to the name than unused seems appropriate to me, because ref is determining the category of the binding, which is closely connected to its type. So I prefer unused being outside ref, and for consistency I'd like to also put unused outside var in similar contexts. Making unused a pattern operator allows unused var x: i32, unused ref y: i32 while still allowing var unused x: i32 = 0; as a declaration.

[burakemir]

Thanks. I have encountered three more questions (Question 3, 4, 5), which I have added above since they seem very related.

[zygoloid]

Question 3 - If I have fn F(o: C) { var _ : o.Inner }, we should still consider o unused, correct?

My inclination is to consider o used if it is ever named, or put another way, if replacing o with _ would not be trivially correct.

I think it could be reasonable to have a more lenient check for names that are declared unused but that are nonetheless used, and not diagnose if they're only used in non-essential ways such as the above, but I wouldn't consider that a high priority.

Question 4 - There is a check to ensure implementations are the same as interface methods. I believe this check should skip over unused markers. Can you confirm?

Yes. This is discussed in proposal #3763 which specified the check.

Question 5 - Can you confirm that "unused" markers do not seem to make sense on interface methods, as they should not be part of contract. Should we flag this as error?
To put it more neutrally: if we do not update the check, then "unused" on an interface of virtual method declaration will force implementations to have unused markers, and thus force the parameters to not be used. This seems undesirable?

Per proposal 3763, unused is only permitted on a definition, and does not need to match when checking two declarations are the same. So unused would be allowed on a virtual fn declaration if that declaration is a definition, and would not require the corresponding marker to appear on overrides; similarly, it would be allowed on a default fn declaration in an interface if that declaration is a definition, and would not require the corresponding marker to appear in impls.

[burakemir]

Thanks for the quick and thorough answers. I have incorporated these into PR #6460.