For me this is not a good change, as it complicates specification
significantly.
Also if you think your condition might hold just use std::ranges::includes.
For algorithm to check this seems like a bad idea, similarly how std::sort
does not check std::is_sorted before running.
If people think their array might be sorted they can check, not impose cost
on every call.
Beside that qualifying output requirements based on inputs would make every
algorithm much more complex to understand.

For example this can probably work fine, but why would standard bother
enabling that?
std::vector v{1,2,3};
int* dst = nullptr;
std::ranges::copy_if(v, dst, [](int){return false;});

On Sun, Sep 14, 2025 at 3:52 PM Peter Neiss via Std-Proposals <
std-proposals_at_[hidden]> 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(see cppreference for possible
> implementation).
> This would allow inplace execution without memory allocation, which is a
> big plus.
>
> 26.8.7.4 set_intersection (wording)
>
> replace: The resulting range does not overlap with either of the original
> ranges. <https://eel.is/c++draft/set.intersection#2.sentence-2>
> with: result may be equal to first1 or first2, otherwise the resulting
> range does not overlap with either of the original ranges.
>
>
> PS: I am quite sure my statement is correct and I am not making a fool out
> of myself. Still confirmation of my claim would be great.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>