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

On 26 May 2015 at 11:40, Giovanni Piero Deretta wrote:

...

For me my main purpose is making AFIO allocate four malloc/frees per op instead of eight. I also make heavy use of make_ready_future(), and by definition that is now optimally fast.

The ready future path is taken unconditionally or with a condition often known at compile time? If yes that seems strange to me and would love to see an example. If no then you are probably optimising for the wrong case.

If an op is scheduled with a precondition which has already completed, a make_ready_future is scheduled to be executed on function exit that makes the outcome the same as if the precondition were continued. That happens a good chunk of the time.

...

Also, as I mentioned, the lion's share of the future implementation is actually reusable as a monadic transport. That's currently a monad base class in my code, but I am asking for bike shedding here on what to name a user facing specialisation.

I think you are selling your code wrongly. What you have is a potentially zero overhead expected-like result wrapper; this is something people would want. What you are advertising is a zero overhead future in the uninteresting case and people can't see the point of it.

TBH I don't really care about what other people *think* they want. Most of the time what people think they want before they *need* it is misplaced. I've seen that already in some of the comments here, people are bikeshedding what they think a future/expected/monad ought to be without actually needing a better future/expected/monad for their specific problem use case. I *do* have a pressing use case, and better futures makes my immediate pressing use case go away. I've been working on the correct redesign since October 2014, so none of these design decisions were taken without very ample reflection. I also waited to attend Thomas Heller's C++ Now presentation on his replacement futures before starting my own. I think my solution to my problems solves all the major problems ASIO has with futures too, as my problems are those also of ASIO. That could eventually help bridge the travesty the Networking TS is currently being degraded into :( That may mean this design could be useful in Boost.Thread too, and therefore eventual standardisation as part of repairing the Networking TS for the next standard release after they no doubt cock up the first attempt. We'll see.

The fact that your future is internally implemented using your result wrapper is nice but not critical.

It *is* critical if you want a future to efficiently convert into a result, and vice versa.

Also why does the future inherit from the result object? I would expect it to contain something like variant.

It won't inherit from result, but from the same base class (currently "monad"). No variants at all in this design (too expensive).

...

...

I believe that trying to design a future that can fulfill everybody's requirements is a lost cause. The c++ way is to define concepts and algorithms that work on concepts. The types we want to generalize are std::future, expected, possibly optional and all the other futures that have been cropping up in the meantime. The algorithms are of course those required for composition: then, when_all, when_any plus probably get and wait.

I think it might not be a lost cause in a world with concepts and especially modules. Until then it's going to be unacceptably slow.

I'm not following. How do concepts and modules allows to have a catch all future?

If we had C++ Modules and Concepts now, my guess would be that Expected would be enormously faster to build. Of course, we'd simply push out the complexity still further until even Modules wasn't enough. GCC will be in the way of ubiquitous Modules though :(

If you need this week just use boost.thread future and get afio reviewed with that. Have the magic future as an optional unstable preview only interface.

AFIO already uses either boost::future or std::future. Has done since v0.1. Indeed Vicente patched extra APIs into boost::future for me to improve performance :) But the community here said they wanted a "final" API before review, so I'll deliver exactly that. These futures will be custom subclassed by AFIO into a special afio::future, and that makes a ton of API cruft dealing with the limitations of std::future go away.

Boost reviews usually focus on interfaces more than implementation. As long as the reviewers believe that your interface can be implemented efficiently you'll be fine.

In fact having yet another non interoperable future in afio might be a negative point during review.

After afio is accepted, you can lobby to get boost.thread future do what you want, or better add generalised future composition to boost.

c.f. earlier discussion here asking for community preferences. tl;dr; the community prefers a "final" API to review. They shall get it. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/