Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-11-19 01:58:51

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.

but this is a different problem.

Removing the conversion will make the following code correct

f(1);
f(make_optional(1));

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);

>>>
>>> ...
>>> I have to admit I find it somewhat of a concern hearing from the 
>>> "optional" maintainer and someone leading "optional" for 
>>> standardization that he does not seem to share/agree with the 
>>> current "optional" design to the point where you are keen on forking 
>>> a "seriously incompatible" variant. Going ahead with the latter will 
>>> be a lot of effort implementing, promoting, educating, defending... 
>>> IMO that'll be the effort 1) not necessarily successful; 2) 
>>> fragmenting the user-base; 3) most importantly, it'll be the effort 
>>> taken *away* from the current "optional"... which seems so close 
>>> (hopefully) to standardization. If you have concerns (you would not 
>>> initiate the conversation if you did not), let's discuss them within 
>>> the "optional" boundaries and document/justify the decisions made. 
>>> Do I worry too much?
>>>
>> Things are moving in C++ to the functional paradigm very quick. 
>> People would need to learn,  soon or late,  functional programming 
>> and monads. I'm sorry, they are viral !!!
>
> You may well be right... Still, I would not be that quick and decisive 
> underestimating people's inertia. After all, functional programming 
> languages have been around much longer than C++. I do not see them 
> occupying minds of the programming majority. Even using primitive 
> functional programming in C++ (say, std::for_each instead of ol' and 
> trusty for loop) has not been exactly "viral". :-)
>
I think the main reason has been that people needed to define some 
function object elsewhere. With lambdas, this is no more an issue.
Of course, most of the mainstreams projects are not yet using a 
C++11/c++14 compiler.

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).

Let me recall a devise I have heard a lot recently.

LESS CODE, MORE SOFTWARE

Best,
Vicente

[1] http://channel9.msdn.com/Events/GoingNative/2013/Cpp-Seasoning