Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-06-03 06:17:04

Le 02/06/2017 à 16:57, Peter Dimov via Boost a écrit :
> Niall Douglas wrote:
>> 3. User wants to write functional programming logic using the basic 
>> vocabulary of Maybe, Either and i/o monads and basic operators of 
>> bind, fmap, do etc and probably some subset or refinement of Hana for 
>> the collections monads, though my GSoC student may be making the 
>> Ranges TS a choice here as well later this summer.
>>
>> All-narrow observers make sense for this use case as the monadic 
>> operators ensure your function will never be called with the wrong 
>> state.
>
> There's no need for narrow (value) observers when using the monadic 
> interface; it's all wide and since you get the value directly, you 
> don't need to observe it.
>
>
>
You are right Peter. You can just provide the Functor, Applicative, 
Monad operations directly.
You can as well provide the SumType interface (to be defined) but that 
will have at least the visit function.

My idea is to see any TypeConstructible PossiblyValued as a Functor, an 
Applicative and a Monad.
expected<_,E>/optional<_>/unique_ptr<_,D>/shared_ptr<_> are all 
PossiblyValued.
A PossiblyValued is the sum/variant of a type T and something else.

A TypeConstructible type is one that has a factory that makes the type 
from its underlying type.

I know that see unique_ptr<_,D>/shared_ptr<_> as PossiblyValued types 
can be surprising, but any NullablePointer either has a pointee (pointer 
not null) or not (pointer null). So we can see it as the sum of T and 
nullptr_t.

We don't need this and we can have direct mappings for all these 
concrete types. Nevertheless, if a type has already access to its 
possibly value types, why not have also a narrow contract.

The question is do we want optional/expected to provide only a monadic 
interface. Do we want it to provide the visit function as well? Why not 
provide a direct access?
I know (thanks to Niall) variant has a wide narrow access. We have lost 
the train for std::variant.

If we had to define a monadic interface for std::variant<T, 
unexpected<E>>, I'm sure that the std::variant implementer would have a 
hidden narrow access to its elements and will not use neither get_if nor 
visit. Well, this is what I will do to avoid to have to ensure/check 
that there is no cost while using get_if/visit. The problem is that a 
user of variant can not change variant or see hidden functions. Maybe 
I'm wrong and I'm doing premature micro optimizations. While I think 
compilers could optimize a lot of things, I believe that a developer 
should try to define the minimal interface that helps the compiler to 
generate the best code.

A narrow contract (like the one of optional, smart pointers) is like 
accessing the alternative directly and this is could be considered bad. 
The point is that it allows to build the high abstraction efficiently.

Again, we don't need a narrow contract access, but then we need all the 
high level abstractions that we can built on to of it. I'm a fan of safe 
interface, but also the ones that are efficient enough.

Vicente

P.S. Sorry if I have repeated myself more than once.

P.S. You can take a look at the current state of my work concerning this 
a more at

https://github.com/viboes/std-make/tree/master/include/experimental/fundamental/v3

https://github.com/viboes/std-make/tree/master/doc/proposal