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: Lee Clagett (forum_at_[hidden])
Date: 2015-05-26 10:02:41

On Mon, May 25, 2015 at 10:51 AM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 25 May 2015 at 8:27, Rob Stewart wrote:
> >
> > The idea has merit, but I have some concerns. The best practice you've
> > linked states that there are problems with Boost.Threads' expected type,
> > but you only mention compile times specifically. I'd like to better
> > understand why expected cannot be improved for your case. That is, can't
> > expected be specialized to be lighter for cases like yours?
>
> I am one of few here who has seen Expected deployed onto a large code
> base. The other guy is Lee, who has even more experience than I do.
> Ours was not a positive experience in a real world large code base
> use scenario.
>

My experience with Expected was positive in that codebase. However, I
really don't care about compile times, and would often switch between
machines after requesting a build (so I rarely knew how long it would
take). I did have a header-heavy portion (using ASIO stackless), and I know
that test file took a noticeable amount of time to compile. I don't know
how much was related to Expected. I recall other files, with less
header-heavy code, being much more reasonable. These files were also under
300 lines each.

The number of macro switches in Expected was the concern for me, which
could be reduced if C++14 only compilers were supported.

Also, in terms of it now being 2015, we know WG21 are working on an
> official variant type - it was the talk of C++ Now. Such a variant is
> an obvious base class for any expected implementation rather than
> reinventing the wheel separately.
>
> Similarly, the future-ishy parts of expected would make more sense to
> come from a base future-ishy type which is then composed with a
> variant type to make an expected type which does all the singing and
> dancing anyone could desire. That means rewriting expected from
> scratch sometime later on.
>

I've read through the remainder of this thread - are you hoping to replace
use-cases of Expected with this new future_result type? So that a codebase
would use this one type for future and immediate related results?
Synchronous functions could be made asynchronous without changing the API,
which is an interesting property.

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?

Lee