[zesterer]

I think that's a retcon. Rust people did not "decide that leaking is safe" all of a sudden, that's cart-before-horse. Rust's memory model was still in its early stages back then and there was a belief (in hindsight, a mistaken belief) that destructors could be used as a means to guarantee memory safety. This turned out to be poorly reasoned and so, to preserve a consistent model of safety for other code, it was decided that having safety rely on the invocation of destructors was unsound. It's not possible to do this without also having leaks be safe, so that's the world as it is.

If "is leaking memory safe?" is an issue of contention for you, I'd suggest that it's a good idea to do some reading on what memory safety is (I mean that in all sincerity, not as a dunk). Memory safety, at least by the specific and highly useful definition used by compiler developers, is intimately entangled with undefined behaviour, but memory leaking sits entirely outside this sphere. This is as true in C and C++ as it is in Rust.

[steveklabnik]

Another example of how your parent isn't really being accurate, memory leaks are also possible in garbage collected languages, yet they have been considered memory safe since well before Rust even existed.

It's not as if Rust invented the term "memory safety" or gets to define it.

[milesrout]

Memory leaks are not possible in garbage collected languages unless you retain references to data, but by definition that isn't a memory leak, that is exactly the behaviour that you want.

Memory leaks are situations where memory is unrecovered despite there being no path to it from any active thread.

[steveklabnik]

This is the same definition game you’re accusing Rust of making. Sometimes, you retain references you do not want, and therefore, leak. It’s something that comes down to programmer intent.

Talking about leaks this way is absolutely normal. Take https://stackoverflow.com/questions/6470651/how-can-i-create... for tons of examples.

[vlovich123]

So for example, if I do:

    static std::weak_ptr<std::array<uint64_t, 125000000>> weak;

    std::shared_ptr<std::array<uint64_t, 125000000>> strong = std::make_shared({0});
    weak = std::weak_ptr(strong);

That retains 1GiB of memory allocated without any ownership path due to implementation details of std::shared_ptr. Is that a memory leak? There’s no active thread that has a path and yet all of the memory is tracked - if you destroy the weak_ptr thee 1GiB of memory gets reclaimed.

[milesrout]

std shared_ptr uses reference counting, not automatic memory management (gc).

[vlovich123]

Reference counting is a form of GC / automatic memory management [1] but it’s ok, it’s a common mistake to make. What’s less ok is this absolute intransigence in persisting to believe that memory leaks aren’t possible in tracing GCs but only when playing the same definitional games you accuse Rust of doing by limiting the types of things you count as leaks. For example, if I implement a cache as Map<String, Object>, that’s a memory leak if you define memory leaks as retaining memory longer than you’d actually need if the goal is to have just a single instance of a value for key live (because it’s not using a weak reference) or forgetting to delete/evict from the cache. Bad software design can result in memory leaks and defining it as not a memory leak because a live reference to an object exists somewhere is just playing the definitions game [2]

[1] https://en.m.wikipedia.org/wiki/Garbage_collection_(computer...

[2] https://stackoverflow.com/questions/4987357/can-there-be-mem...

[milesrout]

You have misunderstood both the concept of a memory lwak and the concept of automatic memory management. Good job!

No, reference counting is not garbage collection. I am fully aware of the ridiculous claim that it is, promoted by people like you. I fundamentally disagree. It has none of the same properties and doesn't work anything like GC.