gnzlbg

> If the initializer involves non-transient allocations, @gnzlbg said above that they would become run-time allocations. If the initializer involves non-transient allocations, the content of the allocation is put into...

> then the copy constructor is invoked AFAICT I'm not 100% sure about this, and it is kind of implicit in the proposal, but AFAICT there is no other way...

> But what if I use that to initialize a `constinit`? None of these proposals has been merged into the standard (the heap-allocation one has the "good to go", but...

> So how about we start with getting that done? +1. Those seem very uncontroversial and deliver instant value. It makes no sense to block that on solving how to...

Could we change the semantics of using a `const` ? Right now, a `const` is copied on use, but could we make it so that if a `const` is `!Copy...

> But also, I don't feel great about calling Clone automatically... Doesn't feel great to me either. I don't see any reasons why the following code would be unsound and...

> The contortions needed to make const V: Vec work, not to mention backwards compatible, don't seem worth it with so many potential alternative solutions. @rpjohnst Are there cases where...

@mtak- > Desugaring this: [...] into this [...] is safe. I agree, but I don't know what value does allowing this add. If we require `const V: &Vec = alloc_at_compile_time();`...

> There may be a simpler way. If I remember correctly, at some point all heap code in the standard library will be generic over the heap, although default that...

There is a solution proposed for C++20 (I am not sure if it has been merged - EDIT: It was accepted LEWG and sent to LWG and CWG) called `is_constant_evaluated`...