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

2014-11-24 9:34 GMT+01:00 Andrzej Krzemienski :

2014-11-24 7:42 GMT+01:00 Vladimir Batov :

...

...

... User defining its own function

...

void f(optional

<T> , optional <T> );

...

would need to add the following?

void f(T, optional

<T> ) { BOOST_STATIC_ASSERT(); }

...

void f(optional <T> , T) { BOOST_STATIC_ASSERT(); }

What if there are 3 optional parameters? We can not say to the user

Andrzej Krzemienski wrote that

...

...

they need to program this way.

I do not think it has been addressed.

The problem here (as I can see it) is that you supply an abstract fun(T, optional<T>) with no context whatsoever and then ask -- how it can be addressed -- promote T to optional<T> or poison... or something else?.. Obviously, no matter what the choice is it'll be correct for one set of real functions and wrong for others. So, the answer is "it depends on the context". Granted, it's very tempting to have one absolute truth, one simple answer to all fun(T, optional<T>) under the sun... Say, "shall not kill" sounds like a good rule to live by... unless one is attacked... then "kill in defence" might sound like a reasonable approach... unless one is at war... then "kill plenty" sounds like an expectation... I guess, all I am trying to convey with all that killing and mandarins and oranges is that we need to look at things in context and address those in context so that is, in the end, beneficial to the user. From that perspective (usefulness, user-friendliness, rather than some hypothetical library purity) there cannot possibly be any doubts about sensible/unquestionable implicit promotion of T to optional<T>, about what is more natural, better for the user:

foo->set_time("11:55PM") or foo->set_time(boost::optional<string>("11:55PM"))

As for op<(T, optional<T>), then the library writer'd like to be as helpful as possible and to provide as much functionality as possible. Unfortunately, there is just not enough context to go one way or the other. So, stating that by prohibiting the operator is the safest and most honest solution.

I think at this point I had better pause for some time and rethink, whether it is just that I fail to deliver my point of view correctly, or whether I am just too hang out to my own solution.

I get your arguments. It is just that they do not let me conclude that op<(T, optional<T>) should be banned. Either I am too fixed on my point of view, or there does exist an objective argument that I perceive, but cannot put into words.

In general, my argument is not about being pure, but more about "can the concept of optional<T> be easily explained and taught?". I sense that they are different things, although I admit that when I try to explain it, the explanations look the same in either case.

I will need to take some time and rethink.

Anyone else? Would you be affected if operator<(optional<T>, T) is poisoned? (but operator==(optional<T>, T) remains working)