On Wed, Oct 29, 2025 at 1:58 PM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> 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?

Would a sorting algorithm need to care about relocation, though? Can
you make a type for which relocation is noexcept but swapping can't be
noexcept? Since the sorting algorithm is operating on a group of
objects in-situ, it shouldn't need to relocate anything at all.

> -----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.
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals