-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
require argument names in trait method signatures? #1351
Comments
I’m personally more towards forbidding omission of name in all cases, even if it would be a breaking change, because:
|
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'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?). |
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. |
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. |
A deprecation warning with @nagisa suggestion now and a removal in 2.0 seems the safest strategy. |
Ah, perhaps this is the resolution we wound up with. Except that it On Mon, Nov 02, 2015 at 08:15:32AM -0800, Aleksey Kladov wrote:
|
I agree with @seanmonstar; breaking changes must have substantive benefits to rust and rust users to be worthwhile. |
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). |
Well, nobody is using it without naming the argument anyways. Also, it would make documentation better in some cases (requiring names for parameters). So 👍 |
I've written up a pre RFC here: https://internals.rust-lang.org/t/pre-rfc-deprecating-anonymous-parameters/3710/1 |
RFC: #1685 |
This is now required in edition 2018 per notes in rust-lang/rust#41686. |
imported from the rust repo, PR rust-lang/rust#29406
Description, as originally written by @matklad :
@nikomatsakis notes in followup discussion on #29406 :
The text was updated successfully, but these errors were encountered: