The problem is that A is trivially copyable (memcpy works fine), but it's definitely not trivially relocatable. After copying, b.pn still points to a.n instead of b.n, which breaks the whole point of relocation - the new object should be independent.

I think when the proposal author said "trivially copyable implies trivially relocatable", they were speaking practically rather than formally. In most real code, trivially copyable types don't have these self-referential pointer issues. Standard library types are designed to avoid this trap.

But technically? No, the implication doesn't hold. Your struct proves it. A type can be safely memcpy'd without being safely relocated.

The distinction matters because:

• Trivially copyable = bitwise copy produces valid object

• Trivially relocatable = bitwise copy produces semantically equivalent object

Your example passes the first test but fails the second. So while the rule works as a heuristic for most code, it's not a formal guarantee.