4 ms·

The fact that this is not resolved after over a year is concerning to me. At some point you have to make a decision and implement a solution, even if not everyo

The fact that this is not resolved after over a year is concerning to me. At some point you have to make a decision and implement a solution, even if not everyone agrees 100% on which solution to chose. Letting this slide for this long is a very bad sign. I’ve been a big Rust fan for my hobby projects, but the whole point of Rust is effortless correctness and safety. The more I encounter bugs and issues that have no near term solution planned, the more confidence I must admit I’m losing in their bug vs feature work prioritization scheme. For example, it seems sometimes that Rust management would rather focus on cool new language enhancements / rewrite projects, than fix major bugs (sometimes even major borrow checker bugs, or random segfaults created in correct programs).

steveklabnik 8y ago
> 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 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.
- electrograv 8y 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 https://doc.rust-lang.org/std/fs/struct.File.html [2] https://doc.rust-lang.org/std/io/trait.Write.html https://doc.rust-lang.org/std/io/trait.Write.html
  - steveklabnik 8y 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!
- Animats 8y 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.
  - pcwalton 8y 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.
    - masklinn 8y ago
      A linear resource would require that the resource is explicitly released on all codepaths no?
      - pcwalton 8y ago
        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.
pcwalton 8y ago
It's not resolved because it's (a) tricky and (b) is really just a minor question about naming conventions and mutability. I'm quite comfortable stating that non-lexical lifetimes and async I/O, for instance, are far more important. The number of users who benefit from those two features are multiple orders of magnitude greater than the number of users who care about whether the official opinion of the guidelines subteam is that close() should take &self or &mut self. The Rust team would be doing a disservice to users if it focused on small issues like that—this isn't even a bug we're talking about, it's guidance around conventions!—instead of the biggest complaints that come up constantly.
- electrograv 8y ago
  As I mentioned in my other reply to Steve Klabnik, documenting this edge case would have been a sufficient “resolution” to the bug at hand. I may call it a bug, and you may call it undocumented silent data loss behavior; either way, we’re talking about the same thing. Silent data loss from undocumented behavior is not good, wouldn’t you agree? I certainly was not aware that drops in Rust could throw away potentially serious error codes. Now I have to go re-audit the correctness of all my Rust code that uses the file system (at the very least). If the behavior was documented I would not consider this a bug. That said, perhaps I’m missing something in the documentarion — my apologies if thats the case — but I did just re-read the fs::File docs and see no mentions or precautions about potential data loss when a File is dropped.
  - pcwalton 8y ago
    I mean, I guess it's not documented as well as it could be, but the only alternative to dropping close errors would be panicking, and that would be significantly worse. Destructors aren't supposed to fail.
    - electrograv 8y ago
      > the only alternative to dropping close errors would be panicking, and that would be significantly worse. There are plenty of cases where you'd prefer an application to crash upon an unhanded write error, rather than silently losing data that could be highly important and irrecoverable. (Of course, actually handling the errors is preferred above both.) > Destructors aren't supposed to fail. But isn't the whole point of this discussion is that the destructor of fs::File (and probably any other buffered IO writer) can and does fail in some cases?

steveklabnik 8y ago

> 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 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.

electrograv 8y 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 https://doc.rust-lang.org/std/fs/struct.File.html [2] https://doc.rust-lang.org/std/io/trait.Write.html https://doc.rust-lang.org/std/io/trait.Write.html
- steveklabnik 8y 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!
Animats 8y 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.
- pcwalton 8y 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.
  - masklinn 8y ago
    A linear resource would require that the resource is explicitly released on all codepaths no?
    - pcwalton 8y ago
      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.

pcwalton 8y ago

It's not resolved because it's (a) tricky and (b) is really just a minor question about naming conventions and mutability. I'm quite comfortable stating that non-lexical lifetimes and async I/O, for instance, are far more important. The number of users who benefit from those two features are multiple orders of magnitude greater than the number of users who care about whether the official opinion of the guidelines subteam is that close() should take &self or &mut self. The Rust team would be doing a disservice to users if it focused on small issues like that—this isn't even a bug we're talking about, it's guidance around conventions!—instead of the biggest complaints that come up constantly.

electrograv 8y ago
As I mentioned in my other reply to Steve Klabnik, documenting this edge case would have been a sufficient “resolution” to the bug at hand. I may call it a bug, and you may call it undocumented silent data loss behavior; either way, we’re talking about the same thing. Silent data loss from undocumented behavior is not good, wouldn’t you agree? I certainly was not aware that drops in Rust could throw away potentially serious error codes. Now I have to go re-audit the correctness of all my Rust code that uses the file system (at the very least). If the behavior was documented I would not consider this a bug. That said, perhaps I’m missing something in the documentarion — my apologies if thats the case — but I did just re-read the fs::File docs and see no mentions or precautions about potential data loss when a File is dropped.
- pcwalton 8y ago
  I mean, I guess it's not documented as well as it could be, but the only alternative to dropping close errors would be panicking, and that would be significantly worse. Destructors aren't supposed to fail.
  - electrograv 8y ago
    > the only alternative to dropping close errors would be panicking, and that would be significantly worse. There are plenty of cases where you'd prefer an application to crash upon an unhanded write error, rather than silently losing data that could be highly important and irrecoverable. (Of course, actually handling the errors is preferred above both.) > Destructors aren't supposed to fail. But isn't the whole point of this discussion is that the destructor of fs::File (and probably any other buffered IO writer) can and does fail in some cases?