Skip to content
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

Merged
merged 1 commit into from
Mar 31, 2015
Merged

Explain why 'elision' #23558

merged 1 commit into from
Mar 31, 2015

Conversation

steveklabnik
Copy link
Member

No description provided.

@rust-highfive
Copy link
Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@Gankra
Copy link
Contributor

Gankra commented Mar 20, 2015

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?

@steveklabnik
Copy link
Member Author

@gankro to me, elision is a passive thing, while inference is an active thing.

@Kimundi
Copy link
Member

Kimundi commented Mar 27, 2015

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 &T in a function signature uses the ellision-inference algorithm to figure out what 'a to pick, while &T in the body of the function use the local-inference algorithm.


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.

@steveklabnik
Copy link
Member Author

What do you think of that version, @gankro ?

@Gankra
Copy link
Contributor

Gankra commented Mar 27, 2015

👍 that's a great explanation, @Kimundi!

@steveklabnik
Copy link
Member Author

@gankro updated to use @Kimundi 's wording. r?

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/in/on?

Copy link
Member Author

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.

@Gankra
Copy link
Contributor

Gankra commented Mar 30, 2015

r=me with nits

@steveklabnik
Copy link
Member Author

I agree with one nit, but disagree with the other. :)

@steveklabnik
Copy link
Member Author

@bors: r=gankro rollup

@bors
Copy link
Contributor

bors commented Mar 30, 2015

📌 Commit 8f0c952 has been approved by gankro

Manishearth added a commit to Manishearth/rust that referenced this pull request Mar 31, 2015
bors added a commit that referenced this pull request Mar 31, 2015
@bors bors merged commit 8f0c952 into rust-lang:master Mar 31, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants