Subject: Re: [boost] [next gen future-promise] What to call the monadic return type?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-25 10:51:17
On 25 May 2015 at 8:27, Rob Stewart wrote:
> > In case you might want to know why a monadic return transport might
> > be so useful as to be a whole new design idiom for C++ 11, try
> > reading
> > https://svn.boost.org/trac/boost/wiki/BestPracticeHandbook#a8.DESIGN:Stronglyconsiderusingconstexprsemanticwrappertransporttypestoreturnstatesfromfunctions.
> Make the examples in that correct WRT shared_ptr. As written, the
> shared_ptrs will delete file handles rather than close them.
I would imagine destroying an open file handle would close it.
Anyway, that really isn't important to the code examples given the
topic, it was never mentioned what a handle_type is, I had an
afio::async_io_handle in mind but it doesn't matter.
> > However, future<T> doesn't seem named very "monadic", so I am
> > inclined to turn future<T> into a subclass of a type better named.
> > Options are:
> > * result<T>
> > * maybe<T>
> > Or anything else you guys can think of? future<T> is then a very
> > simple subclass of the monadic implementation type, and is simply
> > some type sugar for promise<T> to use to construct a future<T>.
> 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
Expected is a great library. Lovely piece of work. However, it is
also enormous. For a simple monadic return transport with traditional
unexpected type exception_ptr, it is enormously overkill. It does
category theory, huge quantities of constexpr machinery, and a fair
chunk of what a variant implementation would need. This is why it is
so slow on compile times.
When we were using expected, 98% of the time we didn't need any of
that. We just wanted a simple Either-Or object which imposed optimal
compile and runtime overhead. We just wanted to return some expected
type T, or some error, and the monadic operations to work as
described without any extra fluff like comparison operations,
hashing, container semantics, automatic conversion, variant semantics
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.
> Put another way, I'd rather one type be smart enough to handle common
> use cases with aplomb than to have many specialized types. I realize
> that doesn't solve your immediate need, but you have your own namespace
> so you can just create your own "expected" type until the other is
> improved. Then, if improvement isn't possible, you can explore another
> name for your expected type.
Mine isn't an expected implementation. It doesn't even do optional
semantics, or even value semantics. It simply provides the simple
future API on a fixed variant wrapper type - three quarters of a
std::future - nothing more.
If you have ever done a lot of make_ready_future() in your code as a
quick and dirty Maybe implementation (I know I have), this use is
exactly what I am trying to formalise into an enormously more
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk