Improve Extend trait's generic param name some other generics, too - #161379
Open
steffahn wants to merge 5 commits into
Open
Improve Extend trait's generic param name some other generics, too#161379steffahn wants to merge 5 commits into
Extend trait's generic param name some other generics, too#161379steffahn wants to merge 5 commits into
Conversation
rustbot
added
S-waiting-on-review
Collaborator
|
r? @JohnTitor rustbot has assigned @JohnTitor. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Okay, first some context:
When talking about the
Extendtrait in a recent meeting, it got really confusing to talk about properties of theExtendtrait for a moment because the naming convention on the trait was so weird. It's defined asExtend<A>and has a methodextend<T>. But most generic implementations of it look likeimpl<T> Extend<T> for …iterator-type…, calling the item typeT.I think
Tis quite sensible for the item type here, so let's change it in the trait definition as well!That means that
<T>for theextendmethod must go away.. what is that anyway? Yes, it't theIntoIteratorparameter that you extend with. Why isn't that justIanyway? Let's choose that! It will be more consistent with existing things likeimpl<I: Iterator> IntoIterator for Ifor instance. Or e.g. all of these… 🦀I've then also noticed
FromIteratorhas the same problem of calling the itemAand usingT: IntoIterator. Let's change that, too.....and then of course, there are a “handful” of implementations of these methods that did just copy the signature for
fn extend<T>orfn from_iter<T>, so I guess I'm fixing these as well.TL;DR:
Change
to
(first commit)
then do the basically the same thing for
FromIterator<A>→FromIterator<T>as well(second commit)
Finally, address
a fewa lot of cases of these parameters in trait impls for the above(third commit)
These obviously don't change behavior, but improve the way the documentation renders (the improvement is the more sensible and more consistent names for the parameters). The only downside I'm aware of (besides touching quite a few files.. though I don't feel quite as strongly about all those impls needing change as about the trait definition itself) is that this does affect some link anchor names in some cases. E.g.
would mean that doc.rust-lang.org/core/iter/trait.FromIterator.html#impl-FromIterator<Option<A>>-for-Option<V> no longer works, as it changes to …#impl-FromIterator<Option>-for-Option