@@ -172,6 +172,18 @@ const fn arithmetic_ops<T: Int>() -> [fn(T, T) -> T; 4] {
172
172
}
173
173
```
174
174
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
+
175
187
# Drawbacks
176
188
177
189
* 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`.
211
223
212
224
# Unresolved questions
213
225
214
- * Allow ` unsafe const fn ` ? The implementation cost is negligible, but I am not
215
- certain it needs to exist.
216
226
* Keep recursion or disallow it for now? The conservative choice of having no
217
227
recursive ` const fn ` s would not affect the usecases intended for this RFC.
218
228
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.
226
236
- This RFC was accepted on 2015-04-06. The primary concerns raised in
227
237
the discussion concerned CTFE, and whether the ` const fn ` strategy
228
238
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