require argument names in trait method signatures?

[pnkfelix]

imported from the rust repo, PR rust-lang/rust#29406

Description, as originally written by @matklad :

Rust currently allows omitting parameter names in trati methods, like this.

trait T {
  fn foo(i32) {  }
}

In all other contexts, except for the fn types, parameter names are
mandatory. This makes argument names in trait methods also mandatory.

This is a breaking language change.

I'm not sure that this is a bug, so feel free to close. I haven't run the tests yet ( they are in progress :( ), so build will likelly fail.

Discussion on the users.rust-lang: https://users.rust-lang.org/t/question-why-does-rust-admit-anonymous-parameters-in-traits/3420

---

@nikomatsakis notes in followup discussion on #29406 :

Huh. I don't believe it was intended that parameter names can be omitted in trait methods with a body -- I know we allowed it in traits initially (before default methods existed), and I guess it is still accepted just because it is a pain to parse otherwise, since you don't know whether the method has a body until later.

That said, I remember us debating about whether to change this due to parsing ambiguities between patterns and types, in particular when parsing something like fn foo(&T -- at this point we don't know if the &T is a pattern or a type. I thought we planned to require parameter names in trait definitions for this reason -- but I guess that never happened?

[nagisa]

I’m personally more towards forbidding omission of name in all cases, even if it would be a breaking change, because:

1. It doesn’t affect me and probably majority of users;
2. It seems to simplify parsing?
3. Change to fix the breakage is trivial: add _: before affected types.

[matklad]

Another thing to note is that patterns in trait method arguments are currently forbidden because of the said ambiguity. That is, the following is not a valid syntax at the moment:

trait M {
    fn at((col, row): (u32, u32)) { }
}

[nrc]

I'm in favour of this change given the simple fix (@nagisa's comment, item 3). As long as we provide a tool to fix this (which should be easy to implement) and a warning cycle or two, then I think the pain is worthwhile. OTOH, the gains seem minor so I understand the resistance to breaking for this (maybe a candidate for when we get to 2.0?).

[seanmonstar]

Seems like a tiny bug (as in, its existence doesn't hurt anyone), so fixing it (and thus causing a breaking change) doesn't seem that warranted, before a major semver change.

[withoutboats]

I often don't declare argument names in trait methods without bodies. I wouldn't mind this going away, but it doesn't seem worth breaking over.

[matklad]

A deprecation warning with @nagisa suggestion now and a removal in 2.0 seems the safest strategy.

[nikomatsakis]

Ah, perhaps this is the resolution we wound up with. Except that it
seems to be inconsistently enforced.

On Mon, Nov 02, 2015 at 08:15:32AM -0800, Aleksey Kladov wrote:

Another thing to note is that patterns in trait method arguments are currently forbidden because of the said ambiguity. That is, the following is not a valid syntax at the moment:

trait M {
    fn at((col, row): (u32, u32)) { }
}

---

Reply to this email directly or view it on GitHub:
#1351 (comment)

[bluss]

I agree with @seanmonstar; breaking changes must have substantive benefits to rust and rust users to be worthwhile.

[munael]

Another thing to note is that patterns in trait method arguments are currently forbidden because of the said ambiguity. That is, the following is not a valid syntax at the moment:

trait M {
    fn at((col, row): (u32, u32)) { }
}

I haven't tested this but it sounds to me like enough benefit for the change (consistency in a feature advertised for functions and usable everywhere else).

[ticki]

Well, nobody is using it without naming the argument anyways. Also, it would make documentation better in some cases (requiring names for parameters). So 👍

[matklad]

I've written up a pre RFC here: https://internals.rust-lang.org/t/pre-rfc-deprecating-anonymous-parameters/3710/1