I’ve never disputed that more code would be generated when this facility is used… My point is more that, by using this facility, a developer indicates that she wants different code to be executed during unwinding. Allowing multiple paths can mean more code, but that shouldn’t surprise anyone. @arielb1 identified a way to allow types that only implement Drop to avoid having multiple drop-glues generated, even when they contain fields that implement ExcDrop (thank you for that!), is this still a concern?
(I’m not sure I follow your point regarding trait objects - I didn’t think it was possible, or ever will be possible, for drop-glue to be called against a trait object? Even with &move pointers, allowing ownership to change hands along with the trait object, the drop-glue would probably need to be inserted by the caller, and invoked after the function that took ownership of the &move pointer returns… Am I wrong about that? How would the called function know that the concrete type implements Drop?)
I consider this part of that effort. I don’t expect linear types to be accepted in the language without addressing the concern that linear types don’t play well with unwinding. I’m trying to address that concern.
This is right. Well, to be more precise, embedded code will (probably) not use unwinding. Panics and assertions are critical in debug builds, but they will probably just stop the program from running, and enable post-mortem debug facilities. But in any case ExcDrop isn’t likely to be useful in embedded environments. (For what it’s worth, I’d prefer to use the word “freestanding” - i.e. talking to bare metal, no OS support - over “embedded” to describe this domain. The term “embedded” has more to do with how much control the user has over the software environment than it does with software capabilities directly…)
