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/fundamen... https://github.com/viboes/std-make/tree/master/doc/proposal