Re: [boost] [optional] Safe optional

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.