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

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-11-24 05:07:19

2014-11-24 9:34 GMT+01:00 Andrzej Krzemienski <akrzemi1_at_[hidden]>:

>
>
> 2014-11-24 7:42 GMT+01:00 Vladimir Batov <vb.mail.247_at_[hidden]>:
>
>> 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.
>>
>
> 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)