Let two foos:
This compiles:
#include <concepts>
#include <functional>
template<typename A, typename B>
bool foo(std::strict_weak_order<A, B> auto) {
    return true;
}
template<std::copyable A, typename B>
bool foo(std::equivalence_relation<A, B> auto) {
    return false;
}
int main() {
    return foo<int, int>(std::equal_to<>{});
}
You say i hide ambiguity, but in fact equality of this two concepts now
hides it.
https://godbolt.org/z/bqePq7hcv

сб, 6 мая 2023 г. в 20:03, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]>:

> On Sat, May 6, 2023 at 10:12 AM Nikl Kelbon via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Now (for compiler) std::strict_weak_ordering<...> is same as
> std::relation<...>, and std::equivalence_relation is same as std::relation
> > This produces amgibuity:
> >
> > #include <concepts>
> > #include <functional>
> >
> > bool foo(std::strict_weak_order<int, int> auto x) { return true; }
> > bool foo(std::relation<int, int> auto x) { return false; }
> >
> > int main() {
> > foo(std::less{});
> > }
> >
> > I propose create a two different implementation concepts
> strict_weak_order_sematic_requirement<R, T, U>
> > and
> > equivalence_relation_semantic_requirement<R, T, U>
> >
> > #include <concepts>
> > #include <functional>
> > // Must be different for equivalence_relation
> > template<typename...>
> > concept always_true = true;
> > template<typename T, typename A, typename B>
> > concept strict_weak_order_semantic_requirement =
> > always_true<T, A, B>;
> > template<typename T, typename A, typename B>
> > concept strict_weak_order = std::relation<T, A, B>
> > && strict_weak_order_semantic_requirement<T, A, B>;
> >
> > bool foo(strict_weak_order<int, int> auto x) { return true; }
> > bool foo(std::relation<int, int> auto x) { return false; }
> >
> > int main() {
> > foo(std::less{});
> > }
> >
> > They must be different, such that strcit_weak_order !=
> equivalence_relation, this solves ambiguity in overload resolution(
> https://godbolt.org/z/n7ovccf9n) and explicitly in code declares our
> intensions.
> > May be in future implementation of this semantic concepts will be
> possible.
>
> This doesn't actually *fix* the ambiguity; it just hides it. In your
> new version, the `relation` overload will never be called. All types
> that satisfy `relation` also satisfy `strict_weak_ordering`, but the
> latter is "more constrained".
>
> So long as there is no syntactic difference between these two
> concepts, it is wrong to write two overloads where the only difference
> is the constraint between those concepts. Your fix does nothing to
> address that, and therefore it is not *meaningful* code to write.
>
> When a programmer does something they shouldn't do, it's better for
> the language to say "no" than to silently accept it.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>