> If you mean "drop," it's just syntactic sugar for calling a trait that manually deallocates the memory and that you're free to reimplement.

I meant `free` because I'm contrasting with C.

> It feels like people are equating "manual memory management" with "onerous memory management."

Manual memory management is onerous, but I'm very specifically talking about manual. If I can write a whole program without thinking about memory, the language does not require manual memory management. It may support it, but it doesn't require it the way that C or Zig do. You do not "have to explicitly manage memory" as OP claimed.

You can't call Drop::drop for type T at all. Try it if you don't believe me.

It would be unacceptable to allow this because Drop::drop says it only takes a mutable reference &mut T (and indeed it does) but now the thing is destroyed, so, that wasn't just a mutable reference at all!

You can call core::mem::drop<T> but well, look at it, here's the code:

pub fn drop<T>(_x: T) {}

Like, duh, we give it a T and then it doesn't give anything, the T is gone. That's not magic library code by the way, if we make our own:

pub fn vanish<T>(_x: T) {}

Now we can call our vanish function and the same happens.

So yeah, automatic memory management.

To be fair I don't think this is enough to say automatic memory management, otherwise C++ would be automatic memory management too (and maybe it is, just poorly implemented?)

Yes, C++ has automatic memory management.

As with the rest of the language, the automatic memory mangement requires that your program has no mistakes - which requires inhuman amounts of care during implementation and testing. So, that's obviously a spectacularly bad idea, but it's still automatic memory management.