Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-11-26 10:45:46

On 11/25/2014 10:44 PM, Vladimir Batov wrote:
>
> On 11/26/2014 02:33 PM, Edward Diener wrote:
>> On 11/25/2014 10:20 PM, Matt Calabrese wrote:
>>> On Tue, Nov 25, 2014 at 5:27 PM, Edward Diener <eldiener_at_[hidden]>
>>> wrote:
>>>
>>>> On 11/25/2014 7:18 PM, Vicente J. Botet Escriba wrote:
>>>>>
>>>>> Following your reasoning, I will suggest to remove the implicit
>>>>> construction from T to optional<T> and/or remove the
>>>>> operator<(optional<T>, optional<>). If we can not live without
>>>>> them, we
>>>>> could always try to do whatever is better.
>>>>>
>>>>
>>>> I do not understand why anyone feels that the less than operator for
>>>> boost::optional<T> is wrong.
>>>
>>>
>>> I can MAYBE see not having them as long as std::less and family are
>>> still
>>> specialized accordingly (specializing std::less is [correctly, IMO]
>>> in for
>>> the proposed standard optional now anyway, thanks to Tony Van Eerd).
>>> Ultimately, though, I really don't think there's a problem with also
>>> having
>>> the operators overloaded. I simply don't buy the "gotchas."
>>
>> If the C++ standard says that associative container of std::optionals
>> is fine but some programmers believe that manually comparing them via
>> the less than operator is not fine, I think we have a real conceptual
>> problem here, even outside of the mere non-orthogonality of the
>> situation.
>
> The discussion is not about
>
>      op<(optional<T>, optional<T>)
>
> but rather
>
>      op<(T, optional<T>)

You have types A, B. There is an implicit conversion from A to B.

op<(A,A) is defined.
op<(B,B) is defined.

but you object if

op<(A,B) or op<(B,A) is defined.

I am sorry but this is too clever for me and I do not get the point. If 
it is purely to protect the programmer from his own error in not 
understanding the relation between A and B I do not agree with this. 
There must be a strong, other valid reason. If in this particular case 
you document the ordering of values in A and B there is no strong case 
that I can see. Misuse of a class by a programmer too lazy or unaware to 
understand how it works is not a valid reason to remove functionality 
for everybody else. If you want coddling, use some other language ( like 
Java for instance ). In C++ we either know what we are doing or we don't 
use what we don't know. It is the same whether it is the language or a 
library.

I am certainly not against an alternative class related to optional if 
that is what others want to develop. But please don't call it 
'safe_optional'. And leave optional itself alone in this respect. It is 
fine the way it is for me.