Common Rust Lifetime Misconceptions (2020)
1–10 of 89 posts
Re: Common Rust Lifetime Misconceptions (2020)
#2How 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 have to check if it is .is_none()
I think that's about it. I rarely introduce a lifetime to a struct/impl. I try to avoid it honestly (probably for worse). Arc kind of bails you out of a lot (whether that's for good or not I don't know).
edit: Remembered another. I think it's kind of weird/too verbose from the compiler / borrow checker when you have a primitive like u32 and it's borrowed and you had to dereference it or clone it.
Re: Common Rust Lifetime Misconceptions (2020)
#3Once I discovered ‘static was the subtype of all lifetimes rather than the super things began clicking for me.
Re: Common Rust Lifetime Misconceptions (2020)
#4This 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 not true", write "Foo is NOT bar". Or have some consistent and unmistakable typography for the "false statements" (highlighting or color, etc)
Re: Common Rust Lifetime Misconceptions (2020)
#5Other tips for understanding Rust lifetime issues:
- Enable rust-analyzer inlay hints for elided lifetimes, reborrows, etc
- Enable the `elided_lifetimes_in_paths` lint
Together, these should ensure that all lifetimes in your code are clearly visible on the screen.
Re: Common Rust Lifetime Misconceptions (2020)
#6How 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…
This is how my team writes production Rust code. Knowing which one to use and when is important, but there's nothing wrong with using the tools available to you.
Non-lexical lifetimes are, in my experience, pretty uncommon in most non-library code. You don't really need them until you really need them.
Re: Common Rust Lifetime Misconceptions (2020)
#7How 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…
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`).
Re: Common Rust Lifetime Misconceptions (2020)
#8How 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…
For the edit: if you have an idea what the output should look like instead, please file a ticket.
Re: Common Rust Lifetime Misconceptions (2020)
#9How 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…
Good advice, though I'd recommend Rc> instead of Arc> if you're not sharing the data between threads, to avoid synchronization overhead. I use Arc pretty rarely.
Re: Common Rust Lifetime Misconceptions (2020)
#10This is a nice writeup. (5) and (10) are particularly good to know IMO -- (5) makes it pretty easy to design correct-looking APIs that only fail to compile when actually called (versus when defined), and (10) is a significant roadbump in Rust's otherwise relatively smooth (IMO) learning curve.