Finalize conventions for close
#26
Comments
In this case also the 'close' name may not be descriptive enough, since we're not just closing a resource, but deleting it. |
@brson so |
Seems just |
@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 |
Yep, this came up during our |
Still no clear guidelines. |
I believe the current definition of I don't think there is any reasonable case for retrying a failed close here. |
I posted a longer comment on the tracking issue, but I'd personally still feel that |
@alexcrichton's comments in the linked thread about favoring |
When combining the 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! |
There's no precedent in std for this, and there's been suggestion that the current signature is not correct (preferring
&mut self
toself
).The text was updated successfully, but these errors were encountered: