Hello Phil,
i disagree with the inplace_set_intersection solution. I read up on weak
ordering. If the input ranges overlap, the intersection is part of this
overlap which either does not change or is already read before overwritten
in a good algorithm.
I think we can just improve the std::set_intersection preconditions and
stuff that already works also becomes legal and is not arbitrarily illegal
in the standard.
Regards,
Peter

Am So., 14. Sept. 2025 um 19:22 Uhr schrieb Phil Endecott via Std-Proposals
<std-proposals_at_[hidden]>:

> Peter Neiss wrote:
> > The std::set_intersection algorithm forbids overlap of the input ranges
> > with the output range, but if first1 or first2 and result would be equal,
> > the algorithm could still work
>
> I suggest a new name and signature, rather than changing
> std::set_intersection:
>
> template <class It1, class It2>
> It1 inplace_set_intersection(It1 first1, It1 last1, It2 first2, It2
> last2);
>
> Range first2...last2 is read from sequentially and not modified;
> I guess It2 is an InputItrator.
>
> Range first1...last1 is read from and modified; the result is the range
> from first1 to the returned iterator. Maybe It1 needs to be a
> ForwardIterator? Not sure.
>
> There are a couple of choices for how the range between the end
> of the result and last1 is left; the elements can either be moved
> or swapped. I guess this range should be left valid-but-undefined.
>
> I'm not sure if this is worth having in the standard library; anyone
> could write it themselves in a few minutes. Maybe its value would
> be to prevent people from wrongly assuming that std::set_intersection
> can already be used in this way!
>
>
> Regards, Phil.
>
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>