Andrzej Krzemienski wrote
... 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 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. -- View this message in context: http://boost.2283326.n4.nabble.com/optional-operator-optional-T-T-is-it-wron... Sent from the Boost - Dev mailing list archive at Nabble.com.