On Sun, May 7, 2023 at 4:01 AM Nikl Kelbon via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> Your arguments may be broken easily with this:
> #include <concepts>
> #include <functional>
> int main() {
> static_assert(std::strict_weak_order<std::equal_to<>, int, int>);
> }
>
> https://godbolt.org/z/3zaKb8cTM
>
> We already have this in standard. Equal to already 'strict weak order'.

Yes, but that doesn't mean that we should encourage this.

> If you are saying ' The code should not compile.'
>
> void foo(strict_weak_order<int, int> auto);
> void foo(std::relation<int, int> auto);
>
> So, if compiler now cannot decide which 'foo' more constrained, then this 'bar' overload set will not be invocable with 'equal_to<>'(ambigious)
> void bar(std::strict_weak_order<int, int> auto);
> void bar(std::equivalence_relation<int, int> auto);
>
> Then i will demonstrate more real case of this problem with user defined concepts.
>
> template<typename T>
> concept A = std::strict_weak_order<T, int, int> && std::copy_constructible<T>;
>
> template<typename T>
> concept B = std::equivalence_relation<T, int, int>;
> bool foo(A auto) { return true; }
> bool foo(B auto) { return false; }
> int main() {
> foo(std::equal_to<>{});
> }
> So, now we now, that compiler cannot decide that strict_weak_order > equivalence_relation or else.
> But here compiler MUST see ambiguity then, because it cannot decide ordering on those concepts. But there are equal, so this code compiles
> https://godbolt.org/z/GKzbxn93b

I don't know what you're talking about here. `A` subsumes `B`, but it
has additional constraints which `B` lacks. Therefore, `A` is "more
constrained" than `B`. So if a type fulfills both, `A` will be chosen.

This *should* compile. And if you put " && std::copy_constructible<T>"
into `B`, it won't compile anymore. We can't make every nonsensical
piece of code not compile. But we don't have to *encourage* this.