As much as I’d love for this to happen, I’m uncertain if editions are robust enough for this to happen. I feel like, in 10 or so years, there needs to be a breaking edition addresses some of these concerns.
It’s super hard to get everything right the first time and I think rust has done an excellent job of ensuring that we’re moving forward incrementally but a leak trait makes things so much nicer in the long run.
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
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!
As much as I’d love for this to happen, I’m uncertain if editions are robust enough for this to happen. I feel like, in 10 or so years, there needs to be a breaking edition addresses some of these concerns.
It’s super hard to get everything right the first time and I think rust has done an excellent job of ensuring that we’re moving forward incrementally but a leak trait makes things so much nicer in the long run.
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
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.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.
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
Dropimplementations have anything to do with the subjects covered by the article!