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 03:34:28

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.