3 ms·

> the compiler will elide them for you Surely the compiler isn't going to remove or ignore things that you typed. You probably meant to say the compiler will

> the compiler will elide them for you Surely the compiler isn't going to remove or ignore things that you typed. You probably meant to say the compiler will allow you to elide them.

squiguy7 9y ago
Sorry, yes. This page has some documentation on what I meant: https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html
- no_protocol 9y ago
  Thank you for the informative link. I have spent some time reading about rust in the past but rarely actually used it. When reading about rust I am constantly bombarded with what I would describe as lazy terminology. In this case, the same term, `lifetime`, is being used to describe several distinct aspects of a system. Between the link you shared, the "Rust Book" that is available online, the book "Programming Rust", the compiler's error messages, and all the various blog posts, there is a definite lack of clear language. Many of these sources are even inconsistent within themselves. It seems like the clearest, most agreed usage is that "lifetime" in general is very close to a concept many other languages have, usually called "scope". The problem starts when eventually all these sources start talking about these things that look like `'a`. Suddenly they're calling `'a` the `lifetime`. That's a poor reuse of the same term. It appears the compiler's error messages are calling this a `lifetime parameter`. The "Rust Book" at one point calls them `lifetime annotations`. Many sources just continue calling them `lifetimes` over and over again. It would be nice if someone could come up with very precise language to describe each aspect of the system so that anyone writing about it can communicate clearly. This problem is not limited to lifetimes at all. As I mentioned above, almost every time I read about rust I'm finding this reuse of terms, misuse of terms, and lack of precision. It's quite frustrating and a major turn off.
  - always_good 9y ago
    Dunno, that's about as confusing as pointing out something has a string "type" and then using "type" again to refer to generic type parameter T. I'm sure someone out there unfamiliar with types thinks it's inconsistent, but it's not really something you think about once you familiarize.
    - no_protocol 9y ago
      > and then using "type" again to refer to generic type parameter T I was curious enough to grab a nearby textbook on Java. The author very clearly calls these things "type parameters" or "type variables". Imagine trying to write the whole chapter just calling them "types"..... "Your generic type will have two other types T and E and we will fill in Grape as type T and Fred as type E...." It'd be a disaster! Instead he's used clear language, every single time he refers to one of those things, he uses the specific term. Much better experience.
  - iopq 9y ago
    Lifetimes are related to scopes, but are not scopes: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...

> the compiler will elide them for you Surely the compiler isn't going to remove or ignore things that you typed. You probably meant to say the compiler will allow you to elide them.

squiguy7 9y ago

Sorry, yes. This page has some documentation on what I meant: https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html https://doc.rust-lang.org/beta/nomicon/lifetime-elision.html

no_protocol 9y ago
Thank you for the informative link. I have spent some time reading about rust in the past but rarely actually used it. When reading about rust I am constantly bombarded with what I would describe as lazy terminology. In this case, the same term, `lifetime`, is being used to describe several distinct aspects of a system. Between the link you shared, the "Rust Book" that is available online, the book "Programming Rust", the compiler's error messages, and all the various blog posts, there is a definite lack of clear language. Many of these sources are even inconsistent within themselves. It seems like the clearest, most agreed usage is that "lifetime" in general is very close to a concept many other languages have, usually called "scope". The problem starts when eventually all these sources start talking about these things that look like `'a`. Suddenly they're calling `'a` the `lifetime`. That's a poor reuse of the same term. It appears the compiler's error messages are calling this a `lifetime parameter`. The "Rust Book" at one point calls them `lifetime annotations`. Many sources just continue calling them `lifetimes` over and over again. It would be nice if someone could come up with very precise language to describe each aspect of the system so that anyone writing about it can communicate clearly. This problem is not limited to lifetimes at all. As I mentioned above, almost every time I read about rust I'm finding this reuse of terms, misuse of terms, and lack of precision. It's quite frustrating and a major turn off.
- always_good 9y ago
  Dunno, that's about as confusing as pointing out something has a string "type" and then using "type" again to refer to generic type parameter T. I'm sure someone out there unfamiliar with types thinks it's inconsistent, but it's not really something you think about once you familiarize.
  - no_protocol 9y ago
    > and then using "type" again to refer to generic type parameter T I was curious enough to grab a nearby textbook on Java. The author very clearly calls these things "type parameters" or "type variables". Imagine trying to write the whole chapter just calling them "types"..... "Your generic type will have two other types T and E and we will fill in Grape as type T and Fred as type E...." It'd be a disaster! Instead he's used clear language, every single time he refers to one of those things, he uses the specific term. Much better experience.
- iopq 9y ago
  Lifetimes are related to scopes, but are not scopes: http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-lexical-lifetimes-introduction/ http://smallcultfollowing.com/babysteps/blog/2016/04/27/non-...