Is there any plan to constrain `std::iter_swap`?

[frederick-vs-ja]

Currently P2602 doesn't remove the "poison pill" for iter_swap, but it seems that @CaseyCarter has been considering constraining std::iter_swap for a long time (see ericniebler/stl2#264 and https://github.com/microsoft/STL/pull/2799#issuecomment-1159164197).

So should we consider constraining it in next revision of P2602?

[brevzin]

I'd rather handle that separately from this.

[brevzin]

Actually. I started working on this and I don't think it's worthwhile.

Right now, the iter_swap poison pill doesn't prevent any iter_swap customizations (those presumably would use the same iterator twice, so automatically more specialized), so there's nothing to gain from removing it - unlike the other cases.

But adding a constraint to iter_swap isn't trivial either. If you just add requires { swap(*lhs, *rhs); } (as the literal this-is-what-it-does constraint), then you suddenly start allowing std::ranges::iter_swap to work on std::optional<int>. If you add a slightly narrower constraint, like:

template <class F1, class F2>
    requires requires (F1 const lhs, F2 const rhs) { swap(*lhs, *rhs); }
void iter_swap(F1 f1, F2 f2);

Then I think you probably avoid doing damage to std::ranges::iter_swap, at the cost of possibly breaking some code that uses std::iter_swap. Now, such code is (library) UB - so maybe the answer to that is "meh."

But ultimately I'm not sure the potentially benefit (i.e.: approximately none?) is really worth it.