Rust

5953 readers

11 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

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

[email protected]

Changing the rules of Rust (without.boats)

submitted 1 year ago by [email protected] to c/[email protected]

4 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 6 points 1 year ago (1 children)

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

[–] [email protected] 2 points 1 year ago (1 children)

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!

[–] [email protected] 1 points 1 year ago (1 children)

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.

[–] [email protected] 1 points 1 year ago

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!