So the aim would be that there is as few code as possible to rely on type 2. Most code with relocatibility should be generic enough not to care about it.   However, for algorithms one would want to estimate the cost.   For example let's sort some objects of type T with small size <= 8. Should we move around indices or pointers, or should we directly sort the objects?   -----Ursprüngliche Nachricht----- Von:Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.10.2025 18:17 Betreff:Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct An:std-proposals_at_[hidden]; CC:Jason McKesson <jmckesson_at_[hidden]>; On Wed, Oct 29, 2025 at 12:50 PM Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> wrote: > Note that "type 1" represents types that can't be relocated at all. So such code should fail to compile. But yes, the same interface that's used to relocate type 3&4 should also be performance-friendly for type 2 cases. The only time you need to care about type 2 as a distinct possibility is if you're relying on low-level bit fiddling.