C++ Logo


Advanced search

Re: [std-proposals] DR: concepts std::strict_weak_ordering / std::equivalence_relation must be resticted by semantic requirements

From: Jason McKesson <jmckesson_at_[hidden]>
Date: Sun, 7 May 2023 11:33:08 -0400
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.

Received on 2023-05-07 15:33:20