It's not as if Rust invented the term "memory safety" or gets to define it.
Memory leaks are situations where memory is unrecovered despite there being no path to it from any active thread.
Talking about leaks this way is absolutely normal. Take https://stackoverflow.com/questions/6470651/how-can-i-create... for tons of examples.
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.[1] https://en.m.wikipedia.org/wiki/Garbage_collection_(computer...
[2] https://stackoverflow.com/questions/4987357/can-there-be-mem...
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.
It’s not a “ridiculous claim”, but maybe you think cycle collectors don’t count?
There isn't much more you can do here because you are completely wrong. Instead of facing reality (that Rust, useful as it may be, only prevents a narrow class of correctness issues of varying importance) you double down on its marketing spin that all the things it fixes just happen to be all the important safety-related ones.
Just step back and actually think. I implore you.
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.