Allow destructors on a structure that does not satisfy Send, but can't have cycles

[kornelski]

struct Foo<'a> { foo: &'a u8 }

impl<'a> Drop for Foo<'a> {
    fn drop(&mut self) {
    }
}

This gives a very surprising error:

cannot implement a destructor on a structure that does not satisfy Send

use "#[unsafe_destructor]" on the implementation to force the compiler to allow this

The problem is not really about ability to send between tasks — a destructor on a structure that can't be shared should be even safer than a destructor on a shared structure, so the message is confusing/misleading.

I've been told that Send is used to declare that the object has no cycles, but this seems like a hack/wart in the language:

• I would expect the compiler to be able to detect that cycles are impossible in trivial cases like this
• "Send" is a poor name for "guaranteed not to have reference cycles".

[alexcrichton]

Closing as a falling under the purview of #8861.

This is most certainly a very real problem, and I would love to see it fixed as well! The error message is quite outdated and is much less relevant at this time. The real problem is that our current analysis of lifetimes allows destructors to reference dangling pointers (see #13246 for an example).

The work planned for #8861 will lift this restriction with more sophisticated analysis, allowing you to safely implement a destructor for a struct with a borrowed pointer, and the compiler will then likely disallow constructing a struct which would result in an unsafe pointer.