# \[Pre-RFC\] Early drop trait

**URL:** <https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678>\
**Category:** language design\
**Created:** [January 27, 2017, 6:58pm UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678 "2017-01-27T18:58:37Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![kkimdev](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kkimdev](https://internals.rust-lang.org/u/kkimdev)\
**Post date:** [January 27, 2017, 6:58pm UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678/1 "2017-01-27T18:58:38Z")

</div>

# Summary

Extending `std::ops::Drop` trait so that user can specify whether the object should be dropped at the end of the enclosing block(the current behavior) or as early as possible.

# Motivation

There are types that it’s almost always preferred to drop as early as possible, e.g., `Mutex`, `RwLock`. Those will have optimal behavior automatically.

# Detailed design

Ideally I think dependent type is the best way to express this, which Rust doesn’t have yet though.

```rust
impl std::ops::Drop for Foo {
    let DROP_STRATEGY : DropStrategy = DropStrategy::Early;
    // let DROP_STRATEGY : DropStrategy = DropStrategy::Late; // Or this.
    fn drop(&mut self) {
        // ...
    }
}

```

The dropping timing will be controlled by `Foo::DROP_STRATEGY` enum value.

# How We Teach This

TBA

# Drawbacks

Complicating `Drop`.

# Alternatives

Using blocks `{}` to control drop timing.

# Unresolved questions

None.

---

<div class="post-metadata">

**Author:** ![sfackler](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sfackler/32/9_2.png) [@sfackler](https://internals.rust-lang.org/u/sfackler)\
**Post date:** [January 27, 2017, 7:20pm UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678/2 "2017-01-27T19:20:06Z")

</div>

It is a breaking change to make standard library lock guards drop earlier than they currently do.

---

<div class="post-metadata">

**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:** [January 28, 2017, 2:40pm UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678/3 "2017-01-28T14:40:14Z")

</div>

Ignoring the breaking change issue for a moment…

In general, if I wanted a mutex to be released earlier, I would much rather type some more curly braces to make it explicit exactly when the release should happen.

Do you have a concrete example where “more curly braces” is not an option, but a “best effort drop-early policy” would help?

---

<div class="post-metadata">

**Author:** ![sfackler](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/sfackler/32/9_2.png) [@sfackler](https://internals.rust-lang.org/u/sfackler)\
**Post date:** [January 28, 2017, 6:10pm UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678/4 "2017-01-28T18:10:39Z")

</div>

Mutex guards can be explicitly dropped wherever you want them to:

```rust
let x = foo.lock();
// do stuff with x
drop(x);
// foo is now unlocked.
...

```

---

<div class="post-metadata">

**Author:** ![kkimdev](https://avatars.discourse-cdn.com/v4/letter/k/d6d6ee/32.png) [@kkimdev](https://internals.rust-lang.org/u/kkimdev)\
**Post date:** [January 28, 2017, 8:39pm UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678/5 "2017-01-28T20:39:59Z")

</div>

Related eager drop discussion in the past: [https://github.com/rust-lang/rfcs/pull/239](https://github.com/rust-lang/rfcs/pull/239)

---

<div class="post-metadata">

**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:27am UTC](https://internals.rust-lang.org/t/pre-rfc-early-drop-trait/4678/6 "2019-03-25T08:27:47Z")

</div>

Closed on March 25, 2019, 8:27am UTC

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.