https://github.com/sam-mccall commented:
I'm in favour of this, but we should have someone less-attached to it sign off on at least the basic design. One question this doesn't explicitly address: after memcpying, does user code need to bless the bits somehow to start the new object's lifetime? I think the answer should probably be yes, even if blessing is a no-op for now. https://github.com/llvm/llvm-project/pull/82776 seems suitable. `__is_trivially_copyable` doesn't require this, but the types it applies to are pretty limited in terms of lifetime concerns, so I think it's OK to draw a distinction. One argument for this is with no "bless" barrier, I don't understand exactly where the line is drawn for strict-aliasing purposes: - if we can memcpy an object A into a buffer B - then surely we can copy it ourselves byte-by-byte - and we can then immediately copy it back from B to A, if the destructor is trivial - now we get to treat it as a different type Here A's bytes didn't change - is the write to B important? Do we have to write the bytes sequentially for this transmutation of A to work, or can we reuse a single byte variable? This all seems weird and like we're reinventing implicit-lifetime types. That's by necessity a weird feature, but the weirdness is not needed here. https://github.com/llvm/llvm-project/pull/86512 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
