> Now, let us go one level up and look at the const type system. We have seen that comparing raw pointers can raise a CTFE error, so this is actually not a const-safe operation. Similar to casting pointers to integers, we have to make the const type system reject code that compares raw pointers. However, it seems like a shame to not even allow comparing two references for equality, after converting them to raw pointers! After all, references never dangle, so this is a perfectly const-safe operation.<p>> Lucky enough, Rust already has an answer to the need to side-step the type system in controlled ways: unsafe blocks. Comparing raw pointers is not allowed by the const type system because it is not const-safe, but just like we allow run-time-unsafe operations to be performed in unsafe blocks, we can allow const-unsafe operations as well. So, we should be able to write the following:<p><pre><code> const fn ptr_eq<T>(x: &T, y: &T) -> bool {
unsafe { x as *const _ == y as *const _ }
}
</code></pre>
If this is ever introduced, I hope that one would be able to mark whether an unsafe block is used because a const-safety restriction (like comparing two pointers for equality) or runtime-safety restriction (all other uses of regular, runtime unsafe)<p>Like this:<p><pre><code> const fn ptr_eq<T>(x: &T, y: &T) -> bool {
unsafe(const) { x as *const _ == y as *const _ }
}
</code></pre>
edit: this same point was made in the Rust internals thread when the article was written, <a href="https://internals.rust-lang.org/t/thoughts-on-compile-time-function-evaluation-and-type-systems/8004" rel="nofollow">https://internals.rust-lang.org/t/thoughts-on-compile-time-f...</a>