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