Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk