I feel like, in 10 or so years, there needs to be a breaking edition addresses some of these concerns.
Maybe 10 years would be enough time to figure out how to release a new version (not edition) of Rust, with older versions being external to the new one with some ABI guarantees! That is if the problems accumulate to a level where it would be felt that this needs to be done.
Leaking might be safe, but not knowing that somewhere in the stack you’re forgetting values is so hard to know when you want to build very long running programs
Apologies if I 'm missing something obvious, but…
What do you mean? How do you not know about forgetting values? Wouldn’t you have literally called mem::forget() on them?
Or do you mean values that stayed alive longer than you expected? That’s a whole nother story. But these are not forgotten. They are still alive because they need to be. And the onus will probably still be on you to figure out why, because these new additions, if implemented, will only be of use in limited applicable scopes.
Or maybe new/better build-time and/or run-time analysis tools will be of help. But those shouldn’t be dependant on these new language additions either!
As a user of any higher level data structures there’s no way for you to know what happens to values passed though. You’re absolutely right that if you were using nothing but the stdlib you always know (mostly) that you are explicitly calling forget.
The problem is that you don’t know that to be the case as the consumer of a library without a thorough audit of the library. Especially when dealing with ffis things get very muddy very fast.
Especially when dealing with ffis things get very muddy very fast.
True. But an ffi biding API leaking resources (memory or otherwise) is a bug in that binding. This holds true for any RAII-using language, including C++. I don’t think faulty Drop implementations have anything to do with the subjects covered by the article!
