undefined | Better HN

0 pointssteveklabnik7y ago0 comments

> the whole point of Rust is effortless correctness and safety.

Rust has never been about proving correctness. Yes, correctness is a goal, but it is subservient to other goals, depending on details.

Furthermore, it's not clear that this can really be implemented in a reasonable way, see https://news.ycombinator.com/item?id=18175838

> it seems sometimes that Rust management would rather focus on cool new language enhancements

In this comment, you're complaining that we haven't implemented a "cool new language enhancement." This is at odds with your desire stated here.

0 comments

electrograv7y ago

Apologies if it sounded like I demanded a “cool new language enhancement” solution to this issue. On the contrary; if it were just documented that either fs::File [1] or the io::Write trait [2] could silently lose data with no error codes when dropped, that would be one such sufficient solution.

Perhaps I misread this documentation; if so, I don’t think I’d be alone here. I don’t see any particular mention that dropping an fs::File could lead to data loss, and I had generally assumed major edge cases like ‘data loss from a file system library’ would be documented.

[1] https://doc.rust-lang.org/std/fs/struct.File.html

[2] https://doc.rust-lang.org/std/io/trait.Write.html

steveklabnikOP7y ago

It falls out of general principle; destructors may not be called. That said, I would happily accept a PR to make this explicit. Even an issue would be nice!

Animats7y ago

Furthermore, it's not clear that this can really be implemented in a reasonable way

Which is why RAII in a language without exceptions is inappropriate for a resource which has a status on closeout.

pcwalton7y ago

The alternative to closing the file in the destructor is leaking OS resources in the event of unexpected control flow destroying the file object. I fail to see how that is preferable.

1 more reply

j / k navigate · click thread line to collapse