Implement proper file closing

[tbu-]

If you don't want to panic in the destructor, you can implement a wrapper
struct that logs the error or similar. By making the explicit error the
default, the user is forced to make an active decision about how they deal with
errors on file closing.

[tbu-]

I guess this is an API-related pull request, so I'm asking @atuoron.
r? @aturon

[rust-highfive]

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

[brson]

I imagine there was a reason for not having explicit close in the original design. One I can think of is that handling close errors is hard to impossible - it's common practice to ignore errors when closing I/O handles because there's not much that can be done.

I do tend to think that there should be an explicit close since not having it loses information.

This implementation though puts a panic in the destructor, which one should never do, since a panicking destructor can abort the process. In this case the destructor should ignore the error.

[tbu-]

Yes, a panicking destructor can cause havoc. That's why this design encourages the parent struct of a file to implement a destructor that can handle a failed file close, e.g. by logging it.

I think that an error on close is not harder to handle than an error on write, so I think not making this explicit is against the spirit of "no implicit error squelching".

Since the destructor cannot guess an appropiate measure on file close, just logging is error squelching, the destructor opts to panic instead, making it very explicit that you need to handle errors on close.

[alexcrichton]

I agree with @brson that the standard library should strive to never panic in a destructor as it's too easy to trigger a panic. This area of closing I/O objects is also under active design and I do not think that it is time to make a PR to pre-emptively implement changes.

I recommend continuing discussion on the related RFC on this topic or opening a more targeted RFC issue. We are definitely aware that of this aspect of I/O, but we currently believe that any modification we make will be a backwards-compatible addition so it isn't the most pressing.