What should BufferedWriter do on flush failure in drop?

[alexcrichton]

If #12630 lands, I/O errors from flush() will be ignored when a BufferedWriter is dropped. Is this the right decision, so this trigger a task failure? Should it be dynamically controllable?

This sort of decision will set precedent for future methods such as a manual close(self) method (should close errors be ignored by default?)

[alexcrichton]

Nominating.

[brson]

My uninformed vote: a failed flush should fail the task - if they wanted to have control they should have called it explicitly.

Are you thinking of moving I/O to require explicit close?

[alexcrichton]

I don't want to require an explicit close, but in theory there should be a method close which you can receive errors from. The Drop implementation would close and handle the error via whatever decision is made on this bug.

[sfackler]

The Drop impl would have to be careful to only fail if the task isn't already failing.

Would it make sense to have some equivalent of must_use to warn if a value is dropped by falling out of scope as opposed to being consumed by a method call?

[brson]

I don't think code should generally try to be defensive about preventing double failure.

[sfackler]

What I'm concerned about is that doing something like this will virtually guarantee an abort when an error is encountered for any code that responds to an IO error by failing, which is not an entirely unreasonable thing to do in a lot of cases.

[brson]

@sfackler To be clear, this is because you expect that after the first I/O error that caused the failure, the subsequent automatic flush will also produce an I/O error.

[sfackler]

Yep.

[pnkfelix]

Assigning 1.0, P-backcompat-libs.