Rust: 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 [e-mail]
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
https://github.com/rust-lang/rust/issues/36235#issuecomment-265336435,
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."

[stevematdavies]

Its an interesting issue, however, personally I believe a common ground would be maintain the current nomenclature, but perhaps update the documentation.

Its always a good thing for non native English speakers to make comments to the documentation as it really illustrates any problem areas. However, In this particular case, despite being a native English speaker, I'd never come across elision or its derivatives before, thus its also useful for native speakers!

Clear and understandable documentation for all, is indeed a rewarding and satisfying goal of any project!

[Jaspi10]

As a non native speaker, who just read the section of the book again. I think it is pretty clear from context, what is meant with 'lifetime ellision' and I dont see a reason to change it.

As for connotation omitting to me is something one does purposefully and therefore here probably not fitting.

[whoisj]

The entire concept of lifetimes and ellision just makes my eyes roll up in my head. It is, honestly, one of the dryer yet more important things needed to understand Rust. Anything that can help the documentation not induce comas in readers is a good start. :laughing:

In all seriousness, this is a tough topic. Making the docs less terse and difficult to consume is a good idea, regardless of language skills.

[steveklabnik]

Yes, after giving this some thought, this is the name of the feature, so changing it isn't something we can do in docs. And it's also chosen very specifically. Sometimes, this is a thing that happens.

As such, I'm going to give it a close. Thank you! ❤️