On 28.09.2015 01:07, Gavin Lambert wrote:
On 26/09/2015 04:17, Andrey Semashev wrote:
On 25.09.2015 18:55, Marcel Raad wrote:
Andrey Semashev-2 wrote
1. You chose not to provide relational operators for compact_optional because you don't know how to order 'empty' values. I think you don't have to make that decision and simply forward the call to the underlying type. I mean, you always have the stored object constructed in some state and as long as it implements operators you can always use them.
This is exactly the problem I sometimes have with Boost.Optional: in some use cases, I want the compiler to remind me that my special value is special and always has to be checked explicitly instead of assuming it's always the lowest possible value. That doesn't apply to operator== and operator!=, of course.
In my practice most of the time you just want some kind of ordering (e.g. for binary lookup). For these cases it's useful for ordering to just work out of the box. When the actual order matters you can always provide your own operator overloads - something you will have to do either way.
Isn't the solution there to specialize std::less and/or std::hash instead of providing operators? (I vaguely recall there being a nicer way to do this proposed and/or implemented in one of the newer standards, but I don't recall the details.)
That's one alternative, surely. My point is that this should "just work" by default and allow customization when something special is required.