I said this during my stream of 4.2 (I think): reading about the explicit "Flow" permission was a wonderful validation of my own internalized representation of how variables/lifetimes behave with regards to function calls. Things "flow" into functions, and the only things that "flow out" are what is part of the explicit return value. Deriving this base set of assumptions gives you why you can't just return, from a function, a reference/borrow of data created / memory allocated inside the function call: you need to have the referenced data "flow out" as well.

Persistent gripes

So much time is spent talking about double frees, use-after-frees, and pointers in general yet we never stop to acquire or review what they definitively look like in practice. It feels to me like The Book ends up specifically assuming you have some prior knowledge of low-level/assembly and/or experience implementing a compiler(s), despite it claiming to be agnostic as to your prior programming language in its intro:

Who This Book Is For

This book assumes that you’ve written code in another programming language but doesn’t make any assumptions about which one. We’ve tried to make the material broadly accessible to those from a wide variety of programming backgrounds. We don’t spend a lot of time talking about what programming is or how to think about it. If you’re entirely new to programming, you would be better served by reading a book that specifically provides an introduction to programming.

I understand if the rust internals are too complex to serve as support for introducing lifetimes, but I wish we got equivalent C code or maybe were shown the compiled output for examples illustrating each part of the chapter. For example, if we could be shown how function calls result in stack frames being pushed & popped beyond just the (more abstract) diagrams we already have, or see some malloc() and more importantly free() calls. Or, at least, see some example memory addresses used in the diagrams so that we can figure out for ourselves which pointers are invalid when, instead of having the arrows in the diagrams keep track of the addresses for us.

tried and true tips

• when you're designing an algorithm to solve a given problem, start with doing as many repeated linear passes over your data collections as you need. Copy/clone/recreate separately anytime you would reach for mutating the original data set. Never [have your code] do more than 1 thing at a time. Only once you have a working implementation of your entire algorithm should you then think about reducing the amount of work your code makes the CPU do to arrive at the same result.

^ this really seems to keep ownership problems: to a minimum, and non-existant during exploratory coding / brainstorming phases.

hard learnt lessons

I am not smart enough to expect to be able to write, first try, rust code that does 0 superfluous copies of data. Attempting to do so always results in going in circles fighting the borrow checker for up to an entire day, before I give up and take the approach I mention above [and often enough end up solving the problem in under half an hour].