# Pre-Pre-RFC: Forget trait **URL:** \ **Category:** Uncategorized\ **Created:** [July 25, 2017, 7:27am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606 "2017-07-25T07:27:18Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![canndrew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/canndrew/32/1676_2.png) [@canndrew](https://internals.rust-lang.org/u/canndrew)\ **Post date:** [July 25, 2017, 7:27am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/1 "2017-07-25T07:27:19Z")
As we’re all probably aware, `Drop` is an anti-trait. Adding a `Drop` impl for a type actually removes functionality (rather than adding it) and further restricts where the type can be used. A solution to this that I don’t remember seeing proposed before would be to change the rules around `Drop` and add another trait which gives the behaviour we want. The idea is to add another marker trait, let’s call it `Forget` which indicates that a type can be dropped without running any drop glue. `Forget` inherits from `Drop`, so we have `Forget: Drop`. What’s more, all types now implement `Drop`. The relationship between `Drop` and `Forget` mirrors that between `Clone` and `Copy`. `Clone` indicates that a type can be copied. `Copy` indicates that a type can be copied _trivially_, without running any extra code. Likewise, `Drop` indicates that a type can be dropped. `Forget` indicates that a type can be dropped trivially, without running any extra code. All the restrictions that current apply to types that implement `Drop`, now instead apply to types that don’t implement `Forget`. Making this backwards-compatible would be a bit messy, but maybe not undoable. If a type doesn’t give an explicit impl for `Drop` then the default impl is derived, as is an impl for `Forget` so long as all of the type’s fields implement `Forget`. If a type does give an impl for `Drop`, then the `Forget` impl isn’t derived. In the future we could add a way to opt-out of implementing `Drop` in order to support truly linear types. So, would something like this be possible? Or is there a deal-breaker here I’m not seeing? ---
**Author:** ![oli-obk](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/oli-obk/32/3168_2.png) [@oli-obk](https://internals.rust-lang.org/u/oli-obk)\ **Post date:** [July 25, 2017, 7:41am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/2 "2017-07-25T07:41:16Z")
> [@canndrew](#): > > If a type doesn’t give an explicit impl for Drop then the default impl is derived, as is an impl for Forget. If a type does give an impl for Drop, then the Forget impl isn’t derived. That formulation doesn't work 100%. Correct would be If a type doesn't give an explicit impl for `Drop` and all fields implement `Forget`, the type implements `Forget`. ---
**Author:** ![canndrew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/canndrew/32/1676_2.png) [@canndrew](https://internals.rust-lang.org/u/canndrew)\ **Post date:** [July 25, 2017, 7:43am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/3 "2017-07-25T07:43:28Z")
Ah yes, that’s the meaning I intended ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [July 25, 2017, 7:56am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/4 "2017-07-25T07:56:05Z")
Could you explain the motivation in more detail? Just from your first paragraph I have absolutely no idea why Drop’s current behavior is a problem and what sort of code a Forget trait would enable. ---
**Author:** ![glaebhoerl](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/glaebhoerl/32/1978_2.png) [@glaebhoerl](https://internals.rust-lang.org/u/glaebhoerl)\ **Post date:** [July 25, 2017, 8:07am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/5 "2017-07-25T08:07:02Z")
I keep linking this old reddit comment: [https://www.reddit.com/r/rust/comments/4l4wjl/a\_report\_on\_regions\_and\_linear\_types/d3lygjn/](https://www.reddit.com/r/rust/comments/4l4wjl/a_report_on_regions_and_linear_types/d3lygjn/) (your `Forget` is my `DropIsForget` - of course, that’s an extremely provisional name) ---
**Author:** ![Gankra](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gankra/32/6002_2.png) [@Gankra](https://internals.rust-lang.org/u/Gankra)\ **Post date:** [July 26, 2017, 12:25am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/6 "2017-07-26T00:25:27Z")
I describe this proposal, its motivation, and its problems more in detail here: [https://gankro.github.io/blah/linear-rust/](https://gankro.github.io/blah/linear-rust/) (this is specifically the “trait” section) I stand by my analysis in the post: linear types really aren’t worth it. And certainly, making a move to introduce this distinction isn’t worth it without an actual proposal to introduce linear types. The compiler team already has a good backlog of like three years of stuff to implement… ---
**Author:** ![canndrew](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/canndrew/32/1676_2.png) [@canndrew](https://internals.rust-lang.org/u/canndrew)\ **Post date:** [July 26, 2017, 4:54am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/7 "2017-07-26T04:54:30Z")
Ah, I'm not surprised to see that ideas like this have come up before. > [@Ixrec](#): > > I have absolutely no idea why Drop’s current behavior is a problem and what sort of code a Forget trait would enable. For example you can't implement `Drop` for a static value. You also can't implement both `Copy` and `Drop` for a type. With the `Forget` trait you could require that all statics implement `Forget` and also have `Copy: Forget`. > [@Gankra](#): > > The compiler team already has a good backlog of like three years of stuff to implement… Well yeah, there's that. ---
**Author:** ![Ixrec](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/ixrec/32/6754_2.png) [@Ixrec](https://internals.rust-lang.org/u/Ixrec)\ **Post date:** [July 26, 2017, 8:06am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/8 "2017-07-26T08:06:34Z")
> [@canndrew](#): > > For example you can’t implement Drop for a static value. You also can’t implement both Copy and Drop for a type. With the Forget trait you could require that all statics implement Forget and also have Copy: Forget I believe [RFC - Allow Drop types in statics/const functions by thepowersgang · Pull Request #1440 · rust-lang/rfcs · GitHub](https://github.com/rust-lang/rfcs/pull/1440) allows static Drop types. I don't recall any RFCs for allowing Copy and Drop types, though it's also not clear to me why we need a Forget trait to change that. ---
**Author:** ![notriddle](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/notriddle/32/14082_2.png) [@notriddle](https://internals.rust-lang.org/u/notriddle)\ **Post date:** [July 26, 2017, 9:09pm UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/9 "2017-07-26T21:09:39Z")
This pre-pre-rfc isn’t proposing linear types. It’s basically asking for the ability to use specialization to pick different code for types that have no drop glue. ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 25, 2019, 8:28am UTC](https://internals.rust-lang.org/t/pre-pre-rfc-forget-trait/5606/10 "2019-03-25T08:28:48Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.