Skip to content
This repository has been archived by the owner on Aug 20, 2021. It is now read-only.

Finalize conventions for close #26

Closed
brson opened this issue Mar 28, 2017 · 10 comments
Closed

Finalize conventions for close #26

brson opened this issue Mar 28, 2017 · 10 comments

Comments

@brson
Copy link
Contributor

brson commented Mar 28, 2017

There's no precedent in std for this, and there's been suggestion that the current signature is not correct (preferring &mut self to self).

@brson
Copy link
Contributor Author

brson commented Mar 28, 2017

In this case also the 'close' name may not be descriptive enough, since we're not just closing a resource, but deleting it.

@opilar
Copy link
Contributor

opilar commented May 12, 2017

@brson so close method should be named to remove?

@opilar
Copy link
Contributor

opilar commented May 12, 2017

Seems just drop does what we need. I think it would be better to merge close method into drop.

@brson
Copy link
Contributor Author

brson commented May 13, 2017

@opilar So the issue here is that sometimes it's appropriate to close a resource explicitly, and not let it implicitly drop. Usually this is to handle an error condition, which drop doesn't allow.

Types in std don't generally have close methods, but they should, and the conventions aren't decided, so for this issue we need to decide what we want such 'close' conventions to be, and whether the existing method here conforms to them. Design question. Not sure how to resolve it, but it probably needs to be a broader discussion elsewhere. cc @dtolnay

@dtolnay
Copy link
Contributor

dtolnay commented May 15, 2017

Yep, this came up during our flate2 review where they use a confusing system of finish + flush_finish + try_finish. I filed rust-lang/api-guidelines#61 to follow up with a guideline for checked teardown that would apply to flate2, tempdir, and hopefully everything else.

@brson
Copy link
Contributor Author

brson commented Jul 15, 2017

Still no clear guidelines.

@brson
Copy link
Contributor Author

brson commented Jul 15, 2017

I believe the current definition of Tempdir::close of close(self) -> Result<()> is correct for this crate, per my argument here.

I don't think there is any reasonable case for retrying a failed close here.

@alexcrichton
Copy link
Contributor

I posted a longer comment on the tracking issue, but I'd personally still feel that &mut self is more appropriate.

@brson
Copy link
Contributor Author

brson commented Jul 17, 2017

@alexcrichton's comments in the linked thread about favoring &mut self for close I find fairly convincing in the general case. At least it seems that &mut self composes better if there are lots of fallible destructors in play, at the expense of maintaining more state.

opilar pushed a commit to opilar/tempdir that referenced this issue Sep 22, 2017
@KodrAus
Copy link
Contributor

KodrAus commented Feb 7, 2018

When combining the tempdir and tempfile APIs in Stebalien/tempfile#33 we kept the close method as-is, which is consistent with the equivalent close methods on temporary files.

We still haven't reached much consensus in rust-lang/api-guidelines#61, but can continue the discussion there about the general merits of different approaches to checked teardown.

Thanks all!

@KodrAus KodrAus closed this as completed Feb 7, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants