Date: Sat, 6 May 2023 12:02:51 -0400
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_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.
Received on 2023-05-06 16:03:03