On Wed, Oct 29, 2025 at 3:27 PM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> sort was just an example.
>
>
>
> Should generic algorithms prefer swap, when possible?

If it makes sense. The two aren't in competition. One exchanges two
objects that already exist; the other translocates an object to a
different piece of storage, creating a new object in the process.
They're pretty different operations.

> -----Ursprüngliche Nachricht-----
> Von: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet: Mi 29.10.2025 20:02
> 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 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
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals