# Edition idea: Should any type that has drop glue be considered to impl Drop? **URL:** \ **Category:** Uncategorized\ **Created:** [March 7, 2021, 6:51pm UTC](https://internals.rust-lang.org/t/edition-idea-should-any-type-that-has-drop-glue-be-considered-to-impl-drop/14195 "2021-03-07T18:51:30Z")\ **Posts on this page:** 1\ **Showing post:** 2
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [March 7, 2021, 7:03pm UTC](https://internals.rust-lang.org/t/edition-idea-should-any-type-that-has-drop-glue-be-considered-to-impl-drop/14195/2 "2021-03-07T19:03:43Z")
Previously > [@Fixing the \`Drop\` trait bound](https://internals.rust-lang.org/t/fixing-the-drop-trait-bound/9458): > > What would I intuitively expect the Drop trait to behave like: When copying values, there are three categories of types: Cannot be copied (no traits) Can be copied using used-defined code (implements Clone) Can be trivially copied with mem-copy (implements Copy which derives from Clone) For dropping the situation should be similar, with the equivalent categories: Cannot be dropped (linear types). Those currently do not exist in Rust. Can be dropped using user-defined code (implements Drop)… And I _know_ this was discussed in the context of `const Trait` (as we would like `const Drop` to be useful to mean "can be dropped in a const context," even including drop glue), but I can't find where it was discussed. The lint for using `Drop` as a trait bound does seem a really good candidate for upgrading to an error in edition 2021 in preparation for "fixing" the bound. Unfortunately I don't think `Drop` meaning "has nontrivial drop glue" is going to ever be the case, because we want `const Drop` to be "has `const` drop glue," which includes "has no drop glue." --- _[View the full topic](https://internals.rust-lang.org/t/edition-idea-should-any-type-that-has-drop-glue-be-considered-to-impl-drop/14195)._