I've been trying to weed the issues in the RFCs repro, and was reminded of the eternal "should Iterator have .first()?" conversation.
That made me think that maybe it would be nice to have an attribute that could help out the existing "help: there is a _______ with a similar name" diagnostic. Right now that does a great job on typos,
error[E0599]: no method named `lem` found for struct `Vec<i32>` in the current scope
--> src/lib.rs:6:7
|
6 | v.lem();
| ^^^ help: there is an associated function with a similar name: `len`
But different kinds of confusion aren't always handled right now:
error[E0599]: no method named `length` found for struct `Vec<i32>` in the current scope
--> src/lib.rs:6:7
|
6 | v.length();
| ^^^^^^ method not found in `Vec<i32>`
And that would also help point people who try to use first over to next, as it could say something like
error[E0599]: no method named `first` found for type parameter `impl Iterator<Item = i32>` in the current scope
--> src/lib.rs:2:7
|
2 | i.first();
| ^^^^^ help: did you mean `next`?
Prior art: this is similar to the #[doc(alias = "?")] used in rustdoc to improve search results. This could be used there too -- searching for "Iterator::first" currently gives Iterator::fold_first, but I don't see a way for the built-in search to get me to next from any search using "first".
For extra clarity: I would expect this to be used only for diagnostics. It would not emit aliases into the resulting library or anything. And thus it would not be a semver change to add or remove these from anything. It would be up to the user (ideally with some structured help) to put the new method in their code -- it would not allow .first() to compile.
One potential downside: the set of these that people might want in std could be rather large -- do we want searching cons to give you VecDeque::push_front? I don't know.
Hopefully this would have negligible perf impact because normal name resolution could ignore them, and only a second pass once there's known to be an error would have to look for them.
Thoughts?
--
Another use: This could be an amazing way to do rename refactorings. You change fn foo() to #[bikeshed("foo")] fn bar(), compile, and hit "yup, that's what I want" on all the structured suggestions in the errors. Could even leave it in for a bit if you're in a project where merge conflicts are likely, so whomever merges atop your change also gets easy fixes for the new errors and people who don't know about the rename get help.
Oh, and these could be in the autocomplete list in an IDE, too, with it putting in the correct name. (Kinda like how in C# some IDEs let you type Foo.new to get new Foo().)
