Sorry, I'm trying to do my best with limited free time, and did not communicate as well as I could have. I tried to make more-or-less the same point in the Motivation section (in the second paragraph), but obviously didn't make it clearly enough.
I considered this, but I think there are negative trade-offs for future compatibility with linear types. The linear-types proposal I submitted included a facility for wrapping a linear type with an affine type by implementing Drop on the wrapping type. @hanna-kruppe asked about this design point specifically, and I'll try to answer his question below, but if this is believed to be a good mechanism for putting a linear type inside an affine type (and I think it is), then simply adding a function to the Drop trait won't work.
"Is it decided that linear types need a trait like this?" No. But one of the most common objections I had seen to previous discussion about linear types in Rust is that linear types do not play well with unwinding. This facility was intended to address that concern.
"Is implementing Drop really the best way to mark something as not-linear?" In my opinion, for the linear-types mechanism described in my RFC, yes. That mechanism (originally proposed by @eddyb, though I may not have captured the spirit of his proposal perfectly) has the compiler treat a variable as linear when it contains (or may contain, in the case of enums) a linear component. In that case, the variable goes from linear to affine as the linear component is partially moved out. For an affine type, the Drop hook (or, actually, a better drop hook in which partial moves would be allowed, discussion) provides a natural point in which the linear components could be moved out, allowing the variable to be treated as affine again.
"If linear types end being done differently (or not at all), would this still be a useful trait?" I believe so. This is another reason I wanted to discuss this independently of the linear types proposal: if this facility is not considered generally useful, then it has failed one of my design objectives.
"Useful enough, compared to just branching on thread::panicking?" Yes, I think so. As @arielb1 points out, branching on panicking cannot capture all patterns that this facility allows. Returning to the motivating example, let's say that, on panic, we want to execute some external program to log details about the panic condition:
struct MyStruct {
...
}
impl ExcDrop for MyStruct {
fn exc_drop(&mut self) {
let _ = fork::scoped("/usr/bin/logger goodbye, world");
}
}
If the hypothetical fork::scoped routine branched on panicking, it would immediately issue a signal to the child process as the ForkGuard goes out of scope, even if logger didn't finish its operation. I haven't thought this through far enough to make this claim with confidence, but this is why I raised the point that ExcDrop might be an ingredient to improve our "panic while panicking" story.