Re: [boost] [next gen future-promise] What to call the monadic return type?

Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2015-05-26 17:26:33

Le 26/05/15 16:47, Niall Douglas a écrit :
> On 26 May 2015 at 10:02, Lee Clagett wrote:
>
>> But if the major complaint about Expected is the compile-time, what is
>> causing that compile-time, and how will this new type avoid that?
> This monad is ridiculously simple because it's fixed function
> variant, and instantiates exactly two types per instance, and
> currently two free function overloads. No partial specialisations at
> all. There will be R& and void specialisations later, but they are
> all hash lookups, not shortlisting lookups in the compiler.
>
> Expected instantiates dozens of types and functions per instance.
> Lots of partial specialisations too. All of that is very slow and
> involves lots of generating shortlists and iterating them for closest
> overload match. Slow.
>
>
IMO what is important is not is the implementation of Boost.Expected 
slow the compile time considerably (it is just a POC and can be improved 
a lot)  but if the interface fores it. How can it be compared to the 
compile time while using optional?

What I've observed is that making expected a literal type (constexpr 
evrywhere) resulted in compile time much slower.
Now we have C++14, I'm sure there are others that have a better 
implementation.

So the question is, do we have the proposed interface for expected, or 
something else?
Would be the 'to be named type" a literal type?

Vicente