On Thu, Oct 31, 2019 at 9:23 AM Arthur O'Dwyer via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Thu, Oct 31, 2019 at 10:14 AM connor horman via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I propose to allow reinterpret_cast from pointer to integral, as well as the no-op/identity reintepret_cast in constant expressions. This particular version is useful in implementing hashcode algorithms at compile time, and to my knowledge bit_cast does not work for pointer types at compile time.

I think this is a non-starter. Consider:

const int i = 42;
constexpr int is_64_aligned(const int *p) { 
    return reinterpret_cast<intptr_t>(p) % 64 == 0;
}
constexpr bool x = is_64_aligned(&i);
int main(int argc, char **argv) {
    bool y = is_64_aligned(argc ? &i : nullptr);
    assert(x == y);
}

How is the compiler supposed to know at compile time what bits are in the runtime bit-pattern of `p`?

Calling a constexpr function is not guaranteed to yield a constant expression. That being said, I agree with your point. I can't think of any case where reinterpret_cast from pointer to integer could be forced to yield a constant expression, except perhaps in the case of a null pointer (and even then, the integral value would be implementation-defined---it might not be 0).

As for static_cast from void* to T* in constant expressions, it seems like it should be allowed, but I think it was mentioned at some point that this would be difficult to implement in current compilers, but I can't find the thread. Hopefully someone else will chime in 
 

–Arthur
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals


--
Brian Bi