Pre-RFC: Leave auto-trait for reliable destruction

language design
8

It seems to me that enforcing that a section of code can't panic is very difficult.

Yes, that seems more complicated than necessary. I'm not suggesting that - apologies for the noise. Let me clarify: If a panic unwind occurs, and there is a live must-destroy type on the stack, the panic handler can:

  1. Abort the process (my initial proposal)
  2. Call drop (the ImplicitDrop and Leak variations)
  3. New: Add another default destructor for must-destroy types, such as destroy(&mut self)
  4. Some form of deferred expression, although I'm not suggesting this - my defer example was intended for normal (non-unwind) control flow.

How does the compiler know that all values are returned from the iterator? After all, Iterator::next can call arbitrary code.

Great point. Future will have the same problem when destructed after Poll::Ready(..). It must be safely destroyed using a runtime invariant check, through a destructor. Possibly, such a destructor could be the same as for panics, i.e. (2) or (3) from the paragraph above.

1 Like