3 ms·
Regarding lifetimes: they're severely overused by people new to Rust. Types like struct <'a,'b,'c,'d> are not for storing data, but are temporary views into da
by pornel 5y ago
Regarding lifetimes: they're severely overused by people new to Rust.
Types like struct <'a,'b,'c,'d> are not for storing data, but are temporary views into data stored elsewhere. If such struct didn't have to be forced to be temporary, or wasn't a view into pre-existing data that can't be moved, then it wouldn't need the lifetime annotations. Such lifetime salad can happen in very specific scenarios, but they're rarely needed in most programs.
It's very unfortunate that the Rust's feature for temporary, scope-limited loans, AKA references, looks so similar to general-purpose features that other languages have for referring to objects or storing data by reference. It's not the same thing!
Rust has a few other constructs for referring to objects, like Arc which is a shared reference, but it's not temporary, or Box which is a pointer for storing data by reference, but doesn't have a lifetime attached. When you start taking ownership into account when designing your data structures, it often turns out that Rust references are not the right tool to use. In 99% of structs references are a mistake (but they exist, because there is that 1% of legit cases).
- sph 5y ago> Types like struct <'a,'b,'c,'d> are not for storing data, but are temporary views into data stored elsewhere. Thanks. As someone that still has a hard time with appreciating the complexity of Rust and its lifetimes, this explanation of yours is illuminating and should be prominently featured in the documentation. It makes a lot of sense and answers a lot of doubts I had.
- cweagans 5y agoAs someone who has tried to like Rust repeatedly, I found that a collection of "gotchas" like this extremely offputting. Is it better for people to unlearn a common thing to do it the "rust way"? Or for Rust to make itself a bit more ergonomic to prevent a common mistake? I understand the importance of thoroughly learning one's tools, but this seems a lot like the ol' "you're holding it wrong" argument. I will also acknowledge the possibility (and likelihood) that I don't understand Rust well enough to dissect the nuance here, but I'll also point out that I really didn't have to dig in that far to gain a working understanding of Go.