Re: [boost] [optional] Safe optional

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

Le 17/11/14 18:14, Joaquin M Lopez Munoz a écrit :
> Andrzej Krzemienski <akrzemi1 <at> gmail.com> writes:
>
>> No, no exceptions.
>> The solution is based on the observation that there is a limited number of
>> things you can do with optional<T>
>>
>> optional<int> oi = ...;
>>
>> 1:
>> if (oi) doSomething(*oi);
>> else doSomethingElse(); // or nothing
>>
>> 2:
>> if (oi) doSomething(*oi);
>> else doSomething(-1); // use default value
>>
>> 3:
>> if (!oi) oi = (int)getIntByOtherMeans();
>> doSomething(*oi); // now it is safe
> Just to throw some idea in, there's an altenative based on the following
> approach: let's assume we have a function f such as
>
>    f(T1,...,T2)->ret
>
> and we have arg1,...argn where the type of argi optional<T1>.
> To call f we'd have to do something like
>
>    auto ret=
>      arg1&&arg2&&...&&argn?
>      f(arg1.get(),...,argn.get()):
>      none;
>
> In fact, we could *lift* f so that we write this instead:
>
>    auto ret=lift<f>(arg1,...,argn);
>
> with the same semantics. This is a case of *monadic lifting* as
> explained (and implemented) at
>
>    http://bannalia.blogspot.com/2014/03/monadic-lifting-in-c.html
Hi Joaquin, I missed your post.

I like this, of course :)

If I understood your blog, this should be something like

     auto ret = lift<optional, f>(a1, ..., an);

Or could the optional template be deduced?

The first variant

     auto ret = lift<optional, f>(a1, ..., an);

doesn't scales to expected<T,E>. Instead of a template <class> 
parameter, lift should take a type constructor, In Boost.Expected we 
would do this as

     auto ret = lift<expected<_holder, error_code>, f>(a1, ..., an);

where _holder is a holder type that makes expected<_holder, error_code> 
to behave as a type constructor.

>
> Lifting can be applied to regular functions as well as operator
> such as the arithmetic ones (relational operators don't follow the
> asme behavior). For the same price, lift<f> can accept any
> combination of optional and non-optional args. Not sure this is
> a case of interface augmentation that we want to apply to
> boost::optional, but I felt like mentioning it at least.
>
>
This lift operation is a good thing when you have a function. The 
problem is that people don't have always a function to call, they have 
just code to execute. The closer we have are lambdas

     auto res = fmap(o1, ..., on , [](a1, ..., an) {
         // the code
     });

Thanks for raising this alternative.
Vicente