Remove outdated info about impl Trait in parameters and generics in the same function #1495
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.
When
impl Trait
in function parameters was added, it was not allowed to specify generics at all when any of the function parameters usedimpl Trait
. That is no longer the case. This restriction was lifted in 1.63.0 by rust-lang/rust#96868, but this instance in the reference was missed. I've removed the outdated sentences.The original last line:
would be correct, but even in the old version, it didn't explain how converting
impl Trait
to generics could be a breaking change, and I can't think of any way it would've been. It is now, so I've added a short explanation that should be sufficient for understanding.I have some more thoughts about breaking changes, but I don't think they belong in this part of the reference. I've included them as context for the change, and in case someone wants to incorporate them elsewhere.
These are the situations I know to be breaking changes:
impl Trait
, and a caller is specifying genericsimpl Trait
parameter is changed to a generic, and a caller is specifying genericsThis assumes the trait bound is the same for the generic and its corresponding
impl Trait
. If a caller isn't specifying generics, any change can be made without causing a break. If a function had no generics and animpl Trait
is changed to a generic, this is also fine, since an empty turbofish::<>
seems to be equivalent to complete omission instead of "exactly zero generics". This would only realistically occur in macro expansions. However, I'm unsure if it's intended as part of the language, and I didn't see any mention of it elsewhere in the reference.