-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Explain why 'elision' #23558
Explain why 'elision' #23558
Conversation
r? @brson (rust_highfive has picked a reviewer for you, use r? to override) |
I'm not clear if there's a rigorous distinction between elision and inference. Both will put different values based on context. Inference fails out if it's ambiguous, elision fails out if what is picked doesn't work? Inference is also more best-effort, while elision is about certain if-then rules? |
@gankro to me, elision is a passive thing, while inference is an active thing. |
Well, technically lifetime elision is a very restricted secondary type inference algorithm that only applies in item signatures, where the primary one is forbidden. That is to say, Rust might be a bit weird in that regard because it has more than one type inference algorithm. (Other languages that claim to infer types have also different algorithms, but I'm not aware of a case where there are multiple ones) It probably makes sense to keep telling them apart as "inference" vs "ellision" as a shorthand, but the fact that both automatically infer some types without needing to write them down should not be glossed over. The best example here is that For the docs, maybe an approach that makes both the distinction and similarity clear would work? "Rust supports powerful local type inference in function bodies, but it's forbidden in item signatures to allow reasoning about the types just based in the item signature alone. However, for ergonomic reasons a very restricted secondary inference algorithm called "lifetime elision" applies in function signatures. It infers only based on the signature components themselves and not based on the body of the function, only infers lifetime paramters, and does this with only three easily memorizable and unambiguous rules. This makes lifetime elision a shorthand for writing an item signature, while not hiding away the actual types involved as the full local inference would if applied to it. |
What do you think of that version, @gankro ? |
👍 that's a great explanation, @Kimundi! |
e81a800
to
56c2191
Compare
lifetime, and so if you elide a lifetime (like `&T` instead of `&'a T`), Rust | ||
will do three things to determine what those lifetimes should be. | ||
Rust supports powerful local type inference in function bodies, but it’s | ||
forbidden in item signatures to allow reasoning about the types just based in |
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.
s/in/on?
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.
I would say 'in' here, but can see 'on' too.
r=me with nits |
56c2191
to
8f0c952
Compare
I agree with one nit, but disagree with the other. :) |
@bors: r=gankro rollup |
📌 Commit 8f0c952 has been approved by |
No description provided.