Incredible. I never held the quoted misconception about `T: '*`, but I didn't understand it. It was a known unknown - I simply applied it when told to do so. This is the first time someone has explained it an understandable way, I guess the implications (it's a ref of that lifetime or an owned) are a better explanation than the technical (T is bounded by the lifetime).
Common Rust Lifetime Misconceptions (2020)
31–40 of 89 posts
Re: Common Rust Lifetime Misconceptions (2020)
#32Incredible. I never held the quoted misconception about `T: '*`, but I didn't understand it. It was a known unknown - I simply applied it when told to do so. This is the first time someone has explained it an understandable way, I guess the implications (it's a ref of that lifetime or an owned) are a better explanation than the technical (T is bounded by the lifetime).
“Applied it when told to do so.”
This is my beginner-level experience with Rust. It’s amazing that the compiler can be so specific about what’s wrong. But taking the error and getting explanations that even I can understand has been tricky.
Re: Common Rust Lifetime Misconceptions (2020)
#33Incredible. I never held the quoted misconception about `T: '*`, but I didn't understand it. It was a known unknown - I simply applied it when told to do so. This is the first time someone has explained it an understandable way, I guess the implications (it's a ref of that lifetime or an owned) are a better explanation than the technical (T is bounded by the lifetime).
“Applied it when told to do so.” This is my beginner-level experience with Rust. It’s amazing that the compiler can be so specific about what’s wrong. But taking the error and getting explanations that even I can understand has been tricky.
This is the kind of thing I like to ask GPT4. It can usually explain what's going on.
Asking different ways usually leads me to understanding it well.
Re: Common Rust Lifetime Misconceptions (2020)
#34Once I discovered ‘static was the subtype of all lifetimes rather than the super things began clicking for me.
`static is actually the superlifetime of all lifetimes, but & is contravariant in its lifetime parameter (and covariant in its type parameter).
Mind expanding on this? The nomicon describes &’a T where both ‘a’ and ‘T’ are covariant. I thought I had a clear picture but now I’m confused.
Re: Common Rust Lifetime Misconceptions (2020)
#35This is very helpful. But I find it cumbersome to mix "misconceptions" with "clarifications". To elaborate, stating "Foo is bar" as a misconception to be clarified, and then following it up with "Baz is quux", makes it very hard to follow and clearly identify what bits of information should be ingrained. In my opinion, information should only be conveyed "in the affirmative". For example, don't write "Foo is bar is n…
> have some consistent and unmistakable typography for the "false statements" (highlighting or color, etc)
THIS ^^
I stopped reading after about paragraph two, when I realized that it was very unclear that the code and table that I was reading was in the "this is a false belief" part of the explanation.
Don't do that.
Communicate more clearly and the article will be useful to more people, longer.
Re: Common Rust Lifetime Misconceptions (2020)
#36Earlier quoted context omitted.
`static is actually the superlifetime of all lifetimes, but & is contravariant in its lifetime parameter (and covariant in its type parameter).
Mind expanding on this? The nomicon describes &’a T where both ‘a’ and ‘T’ are covariant. I thought I had a clear picture but now I’m confused. https://doc.rust-lang.org/nomicon/subtyping.html#variance
Here is the original GitHub issue on the question:
https://github.com/rust-lang/rust/issues/15699
And an RFC by some people that felt frustrated by this arguably implementation-centric view that kind of lost steam:
https://github.com/rust-lang/rfcs/issues/391
Intuitively, the bottom lifetime should the one that is uninhabited, which would be a lifetime with no extent rather than 'static.
Re: Common Rust Lifetime Misconceptions (2020)
#37How I bail myself out of Rust lifetime problems as somebody who probably learned Rust the wrong way (by just trying to build stuff as if it were C/node.js and run into problems instead of slowing down + reading): 1. .clone() / .to_owned() 1. String -> vs &String/&str with & borrow 1. lazy_static / OnceCell + Lazy / OnceLock 1. Arc > with lots of .lock(). What would start off as like NULL in Java/C is Arc >> and you h…
I know there was a thread involving a rust team member saying that clone / to_owned is ok to start with
The memory copying just nags and distracts me from moving on
Re: Common Rust Lifetime Misconceptions (2020)
#38Earlier quoted context omitted.
Using `clone` etc when it's easier is actually common advice, it's perfectly OK to not have borrowing everywhere if you don't need it. My usual starting point / default / rule of thumb is to take references as parameters and return owned values (for example, take `&str` as an argument, return an owned `String`).
IMO stringy data is a good example of where you should think about what you're returning in part because common APIs (e.g. regex) will take a more nuanced approach. If you're creating a new string, then sure return String. But if you have a path where you could just return the original input, consider returning a Cow .
burntsushi actually regrets making regex replace return a Cow: https://github.com/rust-lang/regex/issues/676#issuecomment-6.... I’m glad it does, and wish it took an impl Into> there, for the reasons discussed in the issue, but burntsushi has a lot more experience of the practical outcomes of this. Just something more to think about.
Re: Common Rust Lifetime Misconceptions (2020)
#39How I bail myself out of Rust lifetime problems as somebody who probably learned Rust the wrong way (by just trying to build stuff as if it were C/node.js and run into problems instead of slowing down + reading): 1. .clone() / .to_owned() 1. String -> vs &String/&str with & borrow 1. lazy_static / OnceCell + Lazy / OnceLock 1. Arc > with lots of .lock(). What would start off as like NULL in Java/C is Arc >> and you h…
I know there was a thread involving a rust team member saying that clone / to_owned is ok to start with The memory copying just nags and distracts me from moving on
I'm pretty sure everyone in the teams would endorse that statement :)
Re: Common Rust Lifetime Misconceptions (2020)
#40About #10: > because to unify them at this point would be a breaking change Couldn't they change this in a future edition without breaking older editions?
Wouldn't fixing 10 just mean allowing things that were previously not allowed? That's not a breaking change. What am I missing?