### Author:  [@tema2](https://internals.rust-lang.org/u/tema2)
#### Post date: [September 2, 2021, 10:12pm UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/6 "2021-09-02T22:12:41Z")
While this all is also true, my question is more concrete: what if a type will never be implementing `Drop`, how to dispose it then?
e.g do we want drop glue to be a part of `Drop`'s contract? If yes, what to do with `!Drop` types.
If no, do we want it to stay in such a grey, unspecified area, where it is now?
---
### Author:  [@CAD97](https://internals.rust-lang.org/u/CAD97)
#### Post date: [September 2, 2021, 10:58pm UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/7 "2021-09-02T22:58:57Z")
It's not really all that complicated a situation currently.
When a value goes out of scope (or you call `ptr::drop_in_place` on it), its drop glue is run. Said drop glue does two things:
- If the type of the value has an implementation of `Drop`, calls `Drop::drop(&mut value)`
- Recursively runs the drop glue of each of the value's fields
(This can actually sometimes lead to a problematic amount of IR bloat sometimes, in that the fields' drop calls are separate inlining candidates rather than one sharable, outlinable group.)
As an optimization, if `mem::needs_drop` returns false, you know that drop glue is recursively guaranteed to be a noöp, and can skip running any drop glue.
* * *
It's important to note that a type doesn't have to implement `Drop` to be disposed of. In fact, any type which implements `Copy` implicitly has a guarantee to never implement `Drop`.
An important part of the `impl !Trait` proposal is that it's not removing anything. All it's doing is saying you'll never `impl Trait`. It would be correct to say that there's `impl !Drop for T {}` in the standard library.
---
### Author:  [@scottmcm](https://internals.rust-lang.org/u/scottmcm)
#### Post date: [September 3, 2021, 2:04am UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/8 "2021-09-03T02:04:51Z")
> [@tema2](#):
>
> Then any `Drop` impl will be in fact a specialization.
Note that there are a bunch of rules that depend on types _not_ being `Drop`. For example, you can't move out of a field of a type that implements `Drop`, but you _can_ move out of a type which `needs_drop` because of a field but does not have its own `Drop`.
Thus a change like this would be a breaking change.
---
### Author:  [@felix.s](https://internals.rust-lang.org/u/felix.s)
#### Post date: [September 3, 2021, 7:06am UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/9 "2021-09-03T07:06:42Z")
Personally, I would prefer a proposal that removes the need for negative reasoning about `Drop` entirely, such as the one discussed here:
> [@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)…
---
### Author:  [@tema2](https://internals.rust-lang.org/u/tema2)
#### Post date: [September 3, 2021, 1:57pm UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/10 "2021-09-03T13:57:50Z")
Indeed. The solution is either to add more magic - "is there `Drop` specialization for type or not?" - or to go with trait approach. I think of something like `Dropable` auto trait for drop glue, which `Drop` requires. Opting out from this makes (values of) a type to require programmer attention.
> [@felix.s](#):
>
> I would prefer a proposal that removes the need for negative reasoning about `Drop` entirely
What's the problem with it?
---
### Author:  [@felix.s](https://internals.rust-lang.org/u/felix.s)
#### Post date: [September 6, 2021, 8:58am UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/11 "2021-09-06T08:58:32Z")
Some of it is explained in the linked thread, but roughly: I think positive-only reasoning better fits conceptually. It allows you to uniformly think of traits as capabilities that _allow_ you to do certain things: right now `Drop` is the only trait that signals _obligation_. Avoiding negative reasoning makes it possible to soundly make a default assumption that a trait is not implemented for a type until proven otherwise.
---
### Author:  [@system](https://internals.rust-lang.org/u/system)
#### Post date: [December 5, 2021, 8:59am UTC](https://internals.rust-lang.org/t/negative-drop-impls-drop-auto-trait-and-implicitdrop/15267/12 "2021-12-05T08:59:31Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.