Skip to content

Commit fd38d78

Browse files
committed
Amend rust-lang#911 const-fn to allow unsafe const functions
1 parent 04d8736 commit fd38d78

File tree

1 file changed

+18
-2
lines changed

1 file changed

+18
-2
lines changed

text/0911-const-fn.md

Lines changed: 18 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -172,6 +172,18 @@ const fn arithmetic_ops<T: Int>() -> [fn(T, T) -> T; 4] {
172172
}
173173
```
174174

175+
`const` functions can also be unsafe, allowing construction of types that require
176+
invariants to be maintained (e.g. `std::ptr::Unique` requires a non-null pointer)
177+
```rust
178+
struct OptionalInt(u32);
179+
impl OptionalInt {
180+
/// Value must be non-zero
181+
unsafe const fn new(val: u32) -> OptionalInt {
182+
OptionalInt(val)
183+
}
184+
}
185+
```
186+
175187
# Drawbacks
176188

177189
* A design that is not conservative enough risks creating backwards compatibility
@@ -211,8 +223,6 @@ that a certain method of that trait is implemented as `const`.
211223

212224
# Unresolved questions
213225

214-
* Allow `unsafe const fn`? The implementation cost is negligible, but I am not
215-
certain it needs to exist.
216226
* Keep recursion or disallow it for now? The conservative choice of having no
217227
recursive `const fn`s would not affect the usecases intended for this RFC.
218228
If we do allow it, we probably need a recursion limit, and/or an evaluation
@@ -226,3 +236,9 @@ cannot be taken for granted, at least `if`/`else` should eventually work.
226236
- This RFC was accepted on 2015-04-06. The primary concerns raised in
227237
the discussion concerned CTFE, and whether the `const fn` strategy
228238
locks us into an undesirable plan there.
239+
240+
# Updates since being accepted
241+
242+
Since it was accepted, the RFC has been updated as follows:
243+
244+
1. Allowed `unsafe const fn`

0 commit comments

Comments
 (0)