What do we do with "unconst" operations?

[oli-obk]

Spawned off https://github.com/rust-lang/rust/pull/55009#issuecomment-433211317 (a PR making raw pointer to usize casts unsafe and making raw pointer operations unsafe.

These unconst operations are explained in https://github.com/rust-rfcs/const-eval/blob/master/const_safety.md

There is the question of whether we should overload unsafe to also mean unconst in const environments or whether we should create a new keyword like unconst, const unsafe or similar. The PR linked above uses the unsafe keyword (but all operations still require feature gates).

My view is that unsafe allows you to do things that the compiler can't prove as sound but are still sound. If you mess that up, your code is unsound. Adding another keyword like unconst which means essentially the same thing (but for a different set of operations), feels like it does not add any gains.

[oli-obk]

Further datapoint: we could use unconst in the future to mark functions explicitly not meant to be const. then, in a future edition we can remove the need to mark things as const.

[oli-obk]

Adding another keyword like unconst which means essentially the same thing (but for a different set of operations), feels like it does not add any gains.

The counterargument is that ppl might be confused why something is unsafe in const functions but not in regular functions. This would further complicate the unsafe coding guidelines.

Would it make sense to also make raw pointer to usize casts unsafe in regular code? What about raw pointer operations like <? The result is unspecified but not undefined per se. So no nasal demons if the optimizer figures out that you are using < on two pointers that are from different allocations. It's still very funky that let x = 42; let y = 55; let a = &x as *const i32; let b = &y as *const i32; assert!(a < b || a > b); can theoretically panic.

[RalfJung]

In the const lang-team meeting with @rust-lang/wg-const-eval we did make some plans towards unconst operations, but nothing has happened since then I think. See the meeting notes. The first step would be an RFC specifying what "UB during CTFE" means.

[carbotaniuman]

Would it be possible for unsafe blocks to be a superset of unconst blocks, so if you don't need unsafe you can just use unconst?

[oli-obk]

There is now an RFC with a way to permit arbitrary unsafe (if there is an impl for it): https://github.com/rust-lang/rfcs/pull/3016

I'm going ahead and close this issue

[RalfJung]

Well, that RFC is mostly about unsafe, not unconst. Using this RFC to enable unconst operations is listed as a "future possibility":

This RFC provides an easy way forward for "unconst" operations, i.e., operations that are safe at run-time but not at compile-time. Primary examples of such operations are anything involving the integer representation of pointers, which cannot be known at compile-time. If this RFC were accepted, we could declare such operations "definitely detected UB" during CTFE (and thus naturally they would only be permitted in an unsafe block).