Boost logo

Boost :

Subject: Re: [boost] [optional] Safe optional
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-11-19 15:46:30

On 11/19/2014 05:58 PM, Vicente J. Botet Escriba wrote:
> Le 19/11/14 01:55, Vladimir Batov a écrit :
>> On 11/19/2014 10:52 AM, Vicente J. Botet Escriba wrote:
>>> Le 18/11/14 22:35, Vladimir Batov a écrit :
>>> ...
>>>> 2. I find it troubling that you keep bringing "remove implicit
>>>> conversion from T " up. That indicates that the property is close
>>>> to the top of your "grievances" list. On my side, I find that
>>>> implicit conversion essential for sane interactions of users with
>>>> "optional". Back a while, when we were discussing "optional" (was
>>>> it ISO forum?), I remember Fernando Cacciola expressing the same
>>>> opinion (and as strongly). I'd greatly appreciate if you could
>>>> please provide practical usage/deployment examples where implicit
>>>> conversion from T causes a problem.
>>> It is about the pre-conditions. Before doing a conversion you need
>>> to ensure that there is a value. This give an if-the-else style that
>>> doesn't scale when you have several optionals in the game.
>> Hmm, aren't we talking about different conversions? I was referring
>> to "T to optional<T>". I have the feeling that you are referring to
>> "optional<T> to T". I've never been advocating the implicit latter.
> You are right. I was referring to optional<T> to T conversions. The T
> to optional<T> conversion suffer from overload resolution ambiguity.
> void f(int);
> void f(optional<int>);
> f(1); // ambiguous.

As Andrey already pointed out (while I was asleep :-) it is not ambiguous.

> but this is a different problem.

Andrey, I and GCC insist that there is not problem here. :-)

> Removing the conversion will make the following code correct
> f(1);
> f(make_optional(1));

Again, (1) the code is already correct as-is. (2) asking the library
user to call "f(make_optional(1))" where he conceptually deals with
"ints" is cruel and wrong. The user needs to to program and deal with
his domains concepts ('int' in this particular case) not optional<int>.
Logically, from the user perspectives, the no-int condition is not part
of the range. It's special case. Technically, for implementation
purposes, however, it is. That's where "optional" steps in and bridges
the gap between logical/human view and implementation. Contorting the
human view to cater for implementation has always been wrong.

> I really think that these make_ factories make the code much more
> readable.
> let see how optional, any, expected default conversion work
> void f(int);
> void f(optional<int>);
> void f(expected<int>);
> void f(any);

My current focus is "optional" and on that level "void f(int)" conveys
what it does.

> ...
> For those that have not yet see the Seasoning talk from Seam Parent I
> suggest you take a look at the no-raw-loops part The other are also
> interesting, of course, but this part is really related to what we are
> discussing.
> I agree with you that in general people don't even know all the std
> algorithms are there (and that they can create their own).

I've been in s/w longer that I can remember and to be honest those
std::for_each and the ilk do not grow on me... unless they provide
*real* functionality (like sorting, etc.)... and I honestly tried to
love them... The reason is simple -- readability. I jump back to the old
code and immediately see/understand what it does. Lambdas *might*
address that... Can't judge... C++0x compilers throughout.

Boost list run by bdawes at, gregod at, cpdaniel at, john at