After upgrading rustc I got this warning:
Dropbounds do not really accomplish anything. A type may have compiler-generated drop glue without implementing the
Droptrait itself. The
Droptrait also only has one method,
Drop::drop, and that function is by fiat not callable in user code. So there is really no use case for using
Dropin trait bounds.`
However, a reliable
Drop bound would actually be super useful for containers to be able to have smarter implementations based on whether they have to worry about
Drop. There is precedent for this in C++ -- the type trait
is_trivially_destructible exists exactly for this purpose. If a C++ type doesn't have an explicitly defined destructor, but has members that have explicit destructors,
is_trivially_destructible is false.
AFAICT this inconsistency only exists because types that don't explicitly
impl Drop are not considered to
impl Drop, even if they have members that are
impl Drop. Is there any reason to not just consider any type that needs code to execute when it drops to be
impl Drop? I believe this would be a edition'able change since using
Drop as a bound currently has no effect.
rustfix would just need to remove all
Drop bounds when porting code from old to new editions.
Rust seems to have the workaround function
std::mem::needs_drop::<T> -- but this will still cause a runtime branch in debug builds. It's also inconsistent with how the language deals with all other traits, e.g. you don't write
std::is_default::<T>(), etc. And finally what lead me down this road is lack of addressing this at the type level prevents you from being able to write stack containers that are either Copy or Drop depending on the type they contain. AFAICT I will need to fork my container code, once for use with types where I can be sure memcpying the container is safe and one not.