Use easier word: elide -> omit

[bangzek]

Just reading The Book and because I'm not a native English speaker I've a bit difficulty understanding the word elide.

Ownership, borrow and lifetime is hard enough concept, so why you make it harder by using uncommon word like elide and elisions? Why don't you use much more common word like omit and omission?

[abonander]

It's not that it's a "difficult" word, it's just that it's hard to tell what it means from context. The book could really use a glossary.

When a lifetime is elided, it's not simply omitted, it's more like it's assumed or inferred. This concept needs some more explanation, for sure.

[caipre]

FWIW, the Rustonomicon has a more detailed explanation of lifetime elision: https://doc.rust-lang.org/nomicon/lifetime-elision.html

[joshtriplett]

An "omission" can suggest something missing, and usually has a negative connotation. An "elision" suggests something intentional and acceptable, with no negative connotation.

That said, the term needs a clearer explanation up front.

[frewsxcv]

An "omission" can suggest something missing, and usually has a negative connotation. An "elision" suggests something intentional and acceptable, with no negative connotation.

For what it's worth, Merriam-Webster defines 'elision' using the term 'omitting' in the definition

Would it be incorrect for the Rust documentation to use the term 'omit' instead of 'elide' in the context of 'lifetime elision'? I was under the assumption that: omit : omission :: elide :: elision.

[steveklabnik]

The name of the feature is "lifetime elision", so I'm not comfortable changing terminology unless we more broadly decide to change the name of the feature.

…

On Tue, Dec 6, 2016 at 4:21 PM, Corey Farwell ***@***.***> wrote: An "omission" can suggest something missing, and usually has a negative connotation. An "elision" suggests something intentional and acceptable, with no negative connotation. For what it's worth, Merriam-Webster defines 'elision' using the term 'omitting' in the definition <https://www.merriam-webster.com/dictionary/elision> Would it be incorrect for the Rust documentation to use the term 'omit' instead of 'elide' in the context of 'lifetime elision'? I was under the assumption that: omit : omission :: elide :: elision. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#36235 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsip3YX-TGLnwQ6o0bvXjiqnnaLtRnks5rFhg4gaJpZM4J0NTw> .

[cgag]

I don't know why it's not called lifetime inference. I've never heard the term type elision, nor do I think omit has any generalized negative connotation. If the feature had been called omission, and someone proposed changing it to elision, I think most people would think it were a bad idea.

However, I have no idea if changing it is worth the cost in effort and making it harder to google existing resources that use the current name. Do you (@bangzek) think it'd be good enough if the book said something like Rust allows lifetimes to be elided (omitted) in function signatures.?

[abonander]

Lifetime inference is actually its own thing already. You could call it lifetime parameter inference, but I think that would be even more confusing.

Elision is not an unfit word, it just needs to be explained a little better.

[steveklabnik]

"inference" implies more complexity than "elision", this does not attempt to figure out, aka infer, how lifetimes should work. It just takes some patterns and allows you to elide, aka omit, the explicit lifetime if it fits the pattern.

[caipre]

@steveklabnik : I might have this wrong, but doesn't elision imply inference? Meaning, if the lifetimes are not explicitly written out (ie, are elided), then compiler must be able to infer them. When inference isn't possible, neither is elision.

[steveklabnik]

This is inference:

fn foo(v: Vec<i64>) {}

let v = vec![1, 2, 3];

foo(v);

Here, the Rust compiler looks at v, and says "oh, I don't know what the type is yet." But once you use v by passing it to foo, rust says "oh, foo takes a vec so that must be the type of v."

Elision on the other hand does no such thing. It only allows you to elide/omit things that fit into a pattern. In other words:

fn foo(x: &i32, y: &i32) -> &i32 {

This function has two trivial implementations:

fn foo(x: &i32, y: &i32) -> &i32 {
    x
}

// or

fn foo(x: &i32, y: &i32) -> &i32 {
    y
}

If Rust did "lifetime inference", either of these would be valid. These would be what it would infer:

fn foo<'a, 'b>(x: &'a i32, y: &'b i32) -> &'a i32 {
    x
}

fn foo<'a, 'b>(x: &'a i32, y: &'b i32) -> &'b i32 {
    y
}

Depending on which one you wrote.

However, it does no such thing: it says "hey, foo doesn't fit any known pattern for the elision rules, you must type this out explicitly."