These are chat archives for boostorg/hana

19th
Aug 2016
Louis Dionne
@ldionne
Aug 19 2016 15:44
^ yeah, I think that was the idea when I initially wrote that.
I’m running the tests with && right now, just to see what would fail.
Might remind me of another reason why it’s ||
hia3
@hia3
Aug 19 2016 16:18
Right, but even if apples and oranges are both orderable, this doesn't mean they can be directly compared. I don't care about this (I'm fine with just &&), but may be you do. :smile:
Louis Dionne
@ldionne
Aug 19 2016 16:22
Well, you most likely want hana::int_<1>{} < std::integral_constant<int, 2>{} to return hana::true_, right?
For this, I believe you need exactly what’s done right now.
hia3
@hia3
Aug 19 2016 16:27
Will it stop working with &&? Why?
Jason Rice
@ricejasonf
Aug 19 2016 16:36
Perhaps require also that both operands be hana::Orderable. It ends up checking that eventually anyways.
@hia3 You could also consider implementing hana::less, and you would get the operator for free when used with hana::string.
:P
I don't have is_base_of_v yet :/
hia3
@hia3
Aug 19 2016 18:29
Thank you, Jason, it is very helpful. But I'd prefer to have all my operators in one namespace for consistency (for example, I can overload >>= and , for hana::string no problem and I will have explain why I did > differently). Also doing static_assert in my operator > gives much cleaner error message (static_assert in less_impl::apply will expose all those hana layers).
Jason Rice
@ricejasonf
Aug 19 2016 18:51
Then the only thing I can think of is to specify the namespace when it is ambiguous.
n::operator>(""_s, m);
Louis Dionne
@ldionne
Aug 19 2016 19:41
Overloading these operators for your own type and any Hana type seems like a smell to me.
Why do you want to do this? What are you trying to achieve? In general, it is quite difficult for any library to provide operators that can be extended by users in a safe manner. Reasons include the fact that ADL is tricky, the need for types to interoperate (I need hana::int_ and std::integral_constant to interoperate), the need for the set of types that can interoperate to be open (I don’t want to enumerate all thing with which hana::int_ may be compared, so that users may add new ones just by defining hana::less).
hia3
@hia3
Aug 19 2016 20:28
Sorry, but I don't quite understand how "own type and any Hana type" is smell, but std::integral_constant and hana::int_ is not smell. How about std::istream, operator >> and own type? Are you sure those operators can't be sfinaed-away by checking that there is no hana::less (or less_impl, whatever) for given pair? I think there should be C++ defect report describing that it is hard for a library to do things.
Louis Dionne
@ldionne
Aug 19 2016 20:31

Sorry, but I don't quite understand how "own type and any Hana type" is smell, but std::integralconstant and hana::int is not smell

You're right, nevermind that.

Are you sure those operators can't be sfinaed-away by checking that there is no hana::less (or less_impl, whatever) for given pair?

Yes, because we provide a default implementation of hana::less based on the presence of operator<, which creates a circular dependency.

I’ve spent a fair amount of time thinking about how to make Hana operators more extensible, and I never found a satisfying solution.