29
Changing the rules of Rust
(without.boats)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 Sep 2023
29 points (100.0% liked)
Rust
5926 readers
17 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
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!