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@lists.isocpp.org>:

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals