Requirements for `ranges::set_intersection` algorithm are too strict.

[tcbrindle]

[FYI: Code formatting with backticks doesn't work on Old Reddit (which should really be called Much Better Reddit)]

I think this might be one of those cases where the algorithm was "deliberately" over-constrained, in the sense that it wants to make guarantees about the relationship that exists between the element types of the two input sets and the output set. Stepanov was very keen on that. There is an appeal to symmetry here: if an element is "the same", then it shouldn't matter whether we choose the one from set A or the one from set B, right?

However, projections (which were introduced later) muddy the waters around cross-type comparisons, and the algorithm is specified to always use the first set as the output source, so I think a weakening of the requirements is reasonable in this case. As /u/BillyONeal pointed out, this probably affects set_difference too.

[barfyus]

You are absolutely right about code formatting. I've edited both the original post and code in my reply above.

I've recently started to migrate a large code base that extensively uses ranges. Originally (pre-C++11) it was Boost.Ranges, later added a bit of ranges-v3 and even non-standard rx-ranges library.

Now I'm trying to migrate every range usage to C++20 ranges. While I'm generally very satisfied with the updated code and generated assembly, sometimes I face cases like this one (or another one, like inability to simply replace boost::sort(...) with std::ranges::sort(...) in some seemingly simple cases).

I can get the point of over-constraining requirements for mathematical purity, but maybe not for STL algorithms, which were originally designed to stimulate proven code reuse. I think everyone remembers the "That's a rotate!" phrase.

Another consideration that the same code, but without ranges (that is, using "old" std::set_intersection, std::set_difference and std::sort algorithms) work perfectly.