Skip to content

Commit caea9b4

Browse files
committed
const impl Drop for 🎤
1 parent a27e208 commit caea9b4

File tree

1 file changed

+17
-5
lines changed

1 file changed

+17
-5
lines changed

const-generic-const-fn-bounds.md

Lines changed: 17 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -63,6 +63,23 @@ const impl Hash for MyInt {
6363
}
6464
```
6565

66+
## Drop
67+
68+
A notable use case of `const impl` is defining `Drop` impls. If you write
69+
70+
```rust
71+
struct SomeDropType<'a>(&'a Cell<u32>);
72+
const impl Drop for SomeDropType {
73+
fn drop(&mut self) {
74+
self.0.set(self.0.get() - 1);
75+
}
76+
}
77+
```
78+
79+
Then you are allowed to actually let a value of `SomeDropType` get dropped within a constant
80+
evaluation. This means `(SomeDropType(&Cell::new(42)), 42).1` is now allowed, because we can prove
81+
that everything from the creation of the value to the destruction is const evaluable.
82+
6683
# Reference-level explanation
6784
[reference-level-explanation]: #reference-level-explanation
6885

@@ -213,11 +230,6 @@ This would go in hand with the current scheme for const functions, which may als
213230
at runtime with runtime arguments, but are checked for soundness as if they were called in
214231
a const context.
215232

216-
## Drop
217-
218-
Should we also allow `(SomeDropType, 42).1` as an expression if `SomeDropType`'s `Drop` impl
219-
was declared with `const impl Drop`?
220-
221233
## Require `const` bounds on everything inside a `const impl` block?
222234

223235
Instead of inferring `const`ness on all bounds and functions inside a `const impl` block,

0 commit comments

Comments
 (0)