-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify definition of "input positions" in lifetime elision RFC. #166
Conversation
Explicitly note that lifetimes from the `impl` (and `trait`/`struct`) are not considered "input positions" for the purposes of expanded `fn` definitions. Added a collection of examples illustrating this. Drive-by: Addressed a review comment from @chris-morgan [here](rust-lang#141 (comment)).
r? @aturon |
result types. So `fn foo(s: &str) -> (&str, &str)` has elided one lifetime in | ||
input position and two lifetimes in output position. | ||
Note that the input positions of a `fn` method definition do not | ||
include the lifetimes that occur in the method's `impl` header | ||
`impl` (nor lifetimes that occur in the trait header, for a default |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
arg, typo here, "impl
header impl
" probably should be just "impl
header". (I was originally going to spell out which components of the impl
header I am referring to here, but then decided mid-stream not to bother.)
This looks good to me! Thanks for adding these clarifications. |
(I don't have the rights to merge, however.) |
Also fixed mistake from previous commit (I moved an example up a few lines but forgot to delete the original).
Clarify definition of "input positions" in lifetime elision RFC.
Added the missing }}
Explicitly note that lifetimes from the
impl
(andtrait
/struct
) are not considered "input positions" for the purposes of expandedfn
definitions.Added a collection of examples illustrating this.
Drive-by: Addressed a review comment from @chris-morgan here.
Fix #165.