Next Iteration of “The Rust Programming Language” Book

I feel like you could almost build a rust cheat-sheet poster out of this and few other useful syntax visualizations(traits, generic + lifetime syntax, etc).

When you share something that is not copyable (such as a pen), you give it to the person borrowing it until they return it when done.

When you share something that is copyable (and idea, some software, a joke), you give someone their own copy to do with as they please. There is no return required.

Borrowing, which is from the receiver's perspective, implies returning, while sharing, from the sender's perspective, may or not mat imply a later return of something.

I wonder how much the conceptual baggage of the terminology affects how people learn them.

The reason why the former is not done is because it makes the signature dependent on the body. This means that changing some code could potentially change the signature of the function, which is the kind of silent magic that folks would prefer to be explicit. Also, as the function gets larger, this is harder to deduce by looking at the code. The current elision rules all operate on the signature, so you only need to look at the signature to figure out the lifetimes, elision or not.

The latter is way more controversial. The reason there is similar; folks want it to be obvious from the type name that it is a borrowing type, and changes to the internals shouldn't magically change the signature without an explicit acknowledgement.

Even type arg lifetime elision was controversial. Currently, in Rust, you can write a function like `fn foo(x: &u8) -> Foo`, where `Foo` is actually `Foo<'a>`, and the compiler inserts the lifetimes in the right places. When this was proposed there was a good chance that it would not happen (though as you can see it did happen). So the status quo on lifetime elision is probably not going to change in my opinion, given how hard it was to make the last one happen (of course, you have the "overton window" of acceptable implicitness gradually shifting due to that change, so it might after all)

To me personally, this explicitness is a minor annoyance when dealing with simpler stuff, but is invaluable in codebases making heavier use of lifetimes, like rustc (which avoids reference counting, even though compilers generally need a lot of tricky sharing). And ultimately, I appreciate it even in codebases with fewer lifetimes; I don't like having to peek at a function's code to understand how it's supposed to be used.

Because they're different namespaces? &'x refers to the lifetime x, which has no relation to the local variable x, the global x, the type x or the module x.

However, that has nothing to do with why you have to have a parameter. The parameter is there to make all instances of App track the actual lifetime, e.g. you can tell between App<'foo> and App<'static> (and in the former case, it can keep the borrow that made the &'foo Config alive for as long as the App<'foo> sticks around, and if this is longer than the underlying data lives for, you get an "use after free" error).

Combined with function signatures, Rust can track complex interactions without ever looking at callee bodies, and if you're never reusing a lifetime parameter, you get just as much flexibility as if you were passing the references around directly.

This is something that the C++ attempts at tracking scopes and enforcing a set of rules about them, don't seem to have figure out yet. You need a certain amount of annotations to keep the correct mapping, otherwise you just lose information and have to assume every struct that contains a reference may borrow everything that was borrowed at some point and the borrow may have "escaped" into a struct.

You're either too conservative and thus can't apply the rules to prevent iterator invalidation and data races like Rust can with borrows (Cyclone didn't have borrow-checking either IIRC), or you're ignoring an entire subset of UAF bugs waiting to happen.

Even for the purpose of preventing UAF, such an imprecise aliasing-analysis-like conservative system may be too restricting for many real-world usecases, whereas Rust's, ironically, wouldn't be.

As soon as you are not fighting with lifetimes anymore, it's just a bit more to type. IMHO it actually makes code easier to read, since I don't have to remember a lot of weird rules.

But I have to admit that Rust already has some rules for lifetime elision (e.g. `fn getx(&self) -> &T { &self.x }`. I can only speak for myself but IMHO these rules have a pretty good cost/benefit ratio. For me introducing more rules adds just more cost for diminishing value.

From what I understand, the rust team has scripts that crawls the repos and compiles everything looking for usages of some feature being used that's going to break in the next release, and they will issue a pull request to fix those.

I also got a new computer during that period and rustup has made setup really nice.