pnkfelix
All 7 comments
This may be useful to support close methods for I/O objects that need error reporting when being disposed of. See a discussion thread on I/O issues.
mzabaluev
on 27 Feb 2015
Are there any plans for when we take this up again?
523 seems to be related, by the way.
Munksgaard
on 15 Sep 2015
@Munksgaard I've factored some of this RFC out into #1180, and (opened a discussion on internals about another part)[https://internals.rust-lang.org/t/pre-rfc-excdrop-trait-for-different-drop-glue-during-unwinding/2242]. I've been working through an implementation of #1180, but real life is taking too much time to make any progress at all for probably the next month or so.
aidancully
on 15 Sep 2015
Aside from fallible Drop constructors (e.g. closing a file), there鈥檚 another situation where it could come in handy: Sometimes an resource is held by another thread/process/host and dropping would require waiting for for the other side to complete whatever they are doing. Implicit drops would cause cause the program to block, possibly unintentionally (which can further lead to unintended deadlocks). Worse, the protocol might not even offer a way to wait for it, in which case there鈥檚 nothing you can do but panic. In these kinds of cases, it would have been better to have simply caught it as a compile error.
I think linear types are suited for transient, active things that need to be dealt with carefully and explicitly, whereas affine types are more like passive objects that could be thrown away without regard. Which one is more suitable for a particular resource is probably a bit subjective and dependent on the robustness and reliability demands.
It might even be possible to have a rudimentary lint-based implementation of linear types: if an object gets dropped and the destructor unconditionally panics, then that鈥檚 almost certainly a bug and should be warned.
Rufflewind
on 17 Apr 2017
It might even be possible to have a rudimentary lint-based implementation of linear types: if an object gets dropped and the destructor unconditionally panics, then that鈥檚 almost certainly a bug and should be warned.
How would that work? Presumably when people say linear types they don't mean types with values with an infinite lifetime, but rather that you need to pass them to some special destroy function by value when you're done with them. If you have a Drop impl that always panics you can't even do this (safely).
jethrogb
on 17 Apr 2017
How would that work? Presumably when people say linear types they don't mean types with values with an infinite lifetime, but rather that you need to pass them to some special destroy function by value when you're done with them.
It鈥檚 not infinitely long, but the time at which it becomes destructible is not statically known, and may require the user to take certain actions before it becomes destructible.
If you have a
Dropimpl that always panics you can't even do this (safely).
Yes, panicking in drop is really awkward, so I鈥檓 hoping linear types could help obviate the need for such workarounds.
Rufflewind
on 17 Apr 2017
It's been over 5 years now since this was postponed.
LiamTheProgrammer
on 24 Apr 2020
Related issues
Diggsey
路
3Comments
steveklabnik
路
4Comments
mahkoh
路
3Comments
torkleyy
路
3Comments
burdges
路
3Comments
Most helpful comment
Aside from fallible
Dropconstructors (e.g. closing a file), there鈥檚 another situation where it could come in handy: Sometimes an resource is held by another thread/process/host and dropping would require waiting for for the other side to complete whatever they are doing. Implicit drops would cause cause the program to block, possibly unintentionally (which can further lead to unintended deadlocks). Worse, the protocol might not even offer a way to wait for it, in which case there鈥檚 nothing you can do but panic. In these kinds of cases, it would have been better to have simply caught it as a compile error.I think linear types are suited for transient, active things that need to be dealt with carefully and explicitly, whereas affine types are more like passive objects that could be thrown away without regard. Which one is more suitable for a particular resource is probably a bit subjective and dependent on the robustness and reliability demands.
It might even be possible to have a rudimentary lint-based implementation of linear types: if an object gets dropped and the destructor unconditionally panics, then that鈥檚 almost certainly a bug and should be warned.