Re:Rust RAII is better than the Haskell bracket pattern
by electrograv on Tuesday October 09, 2018 @12:57PM
(#18177633)
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.
Re:Rust RAII is better than the Haskell bracket pattern
by steveklabnik on Tuesday October 09, 2018 @01:04PM
(#18177708)
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!
Re:Rust RAII is better than the Haskell bracket pattern
by Animats on Tuesday October 09, 2018 @01:24PM
(#18177916)
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.
Re:Rust RAII is better than the Haskell bracket pattern
by pcwalton on Tuesday October 09, 2018 @01:28PM
(#18177970)
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.
Re:Rust RAII is better than the Haskell bracket pattern
by masklinn on Tuesday October 09, 2018 @02:14PM
(#18178409)
A linear resource would require that the resource is explicitly released on all codepaths no?
Re:Rust RAII is better than the Haskell bracket pattern
by pcwalton on Tuesday October 09, 2018 @02:21PM
(#18178474)
Not in Rust, and not in any language where you can put resources in objects with shared ownership (i.e. any remotely popular general purpose language).
Throwing exceptions isn't a particularly good solution either, for the same reason. Exceptions are hard to reliably handle when you can't easily reason about where they will be thrown from.
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.