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

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 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.