Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)

Subject: Re: [boost] Monad (was: Re: [Boost-users] [afio] Formal review of Boost.AFIO)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-27 22:38:42

On 27 Aug 2015 at 5:05, Glen Fernandes wrote:

> Niall Douglas wrote:
> > The idea is that no one ever need implement the Concurrency TS 
> > themselves ever again. Just pick up a copy of Boost.Monad/Outcome. 
> > Write your policy class for your custom variant. Profit. 
> 
> Is anyone besides Boost or standard library vendors actually interested in
> doing this? Standard library implementors are not going to take a dependency
> on a Boost library.
> 
> For example: Are there many (or any) Filesystem TS implementations that
> people care about outside of standard library implementations and Boost? 
> 
> I just can't imagine someone, say, proposing Boost.Path that provides a 
> boost::basic_path that can be used to implement
> std::experimental::filesystem::path and expecting anyone to care about it.
> Anyone implementing the TS will just implement
> std::experimental::filesystem::path themselves and not take a dependency on
> boost::basic_path to do it.
> 
> What makes your basic_future so different to the hypothetical basic_path?

A basic_path is probably not going to attract much need for 
customisation without losing interoperability with other basic_path 
customisations.

basic_future lets you implement any custom future type of your 
heart's desire without losing wait composure with other custom 
basic_futures.

Also people do have a real need for custom futures. A big bone Chris 
picks with the Concurrency model in the Concurrency TS is its 
reliance on futures which he views (rightly) as being too chunky for 
low latency socket i/o. My lightweight futures don't address all of 
Chris' concerns, but they are a whole ton load better for low latency 
work than standard futures.

If someone wanted even lower latency than my default implementation 
and wanted to give up standards conformance, they certainly can do 
that. My default implementation has to match the TS, and there is a 
definite overhead to that.

I also suspect they'll be a real boon for C++ 1z coroutines given how 
that is designed, but testing that is many months away yet. If they 
are a real boon, I don't doubt Gor will be very interested.

Finally, you may not be aware that my lightweight futures are 
dependent on a system future implementation. They do not replace 
system nor Boost futures, they act as a layer implemented on top 
dropping down onto the system futures when unavoidable.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/