That certainly poses an issue. Perhaps change it to require the
pointer not be valid a pointer constant expression for the first one,
so the pointer doesn't actually appear at runtime. This wouldn't
affect the usefulness of the proposal, as the use-case is in computing
hashcodes, and if known at runtime then it could be computed at
runtime (even only once in the case of a static or constexpr
variable). I don't believe the second part suffers from the same
issue, though it might be possible in some situtations to encounter
issues when the pointer leaks into runtime, but I can't think of any
where the pointer would have different value representation from its
validly reintepret_casted counterparts (when there is a
pointer-interconvertible) object.

On Thu, 31 Oct 2019 at 10:23, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]> wrote:
>
> On Thu, Oct 31, 2019 at 10:14 AM connor horman via Std-Proposals <std-proposals_at_[hidden]> 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:
>
> // https://godbolt.org/z/Xd48ZV
> 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`?
>
> –Arthur