As I've been reading Rust code and learning how to write it, I've become frustrated with one detail that's been driving me a little crazy from time to time.

How do other developers know when some side-issue management is necessary? In my specific case, it's about Drop.

In two different contexts, I've now seen highly specialized Drop implementations that, quite honestly, I don't understand how the developer knew they were going to be necessary.

The first is in Beingessner's Too Many Lists. It's obvious, in hindsight, that a list with ten thousand entries would fit just fine on the heap, but the stack would get blown up by the recursive drop, so an iterative, hand-written drop was necessary. Which is great, but how did Beingessner know it was necessary without experiencing the blowup? I've written code for decades, much of it in C or C++, and I've never experienced a circumstance where I had to care about blowing the stack with a recursive unroll. Maybe I've never worked with tens of thousands of objects, but that seems unlikely given that I work in a big data field.

The second is in Jerome Froe's LRU Cache. I was writing an LRU cache for Rust with some specific needs (basically, my ejection rule was based on an arbitrary scale provided by an object with a functor, whereas Jerome's uses a standard volume-based rule. I struggled for days with my drop rule until I finally cheated and looked at his and... I don't get it. I mean I get what it is and how it works, but I'm still bothered by... how did he know how to do that? The mem::forget trick is nifty: those head and tail values point to cache items that are going to be dropped automatically, so we need to not drop them. But I still don't know how Froe knew that.

I know it seems... I dunno, petty, I guess. But I always feel as if there's a detail missing that I'm not getting, which is really odd because I'm considered a "thorough" developer according to my peers. But maybe only within a safe space, and Rust these days is a very new, and very awkward, territory for me to be crossing.