Boost logo

Boost :

Subject: Re: [boost] [Boost-users] [afio] Formal review of Boost.AFIO
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-08-24 12:43:23

On 24 Aug 2015 at 19:21, Peter Dimov wrote:

> I have to say that I find this choice of naming baffling. Why would you name
> a concrete type 'monad'? Makes no sense to me.

That was discussed on this very list in great depth and length. The
choice of monad<T> was made to ensure people looked up the
documentation for what it meant instead of making any assumptions. I
think that aim worked out beautifully.

> Would not something like afio::result been better? In this way this is
> clearly a part of AFIO and no separate review would be necessary.

In Monad in addition to a monad<T> there is a result<T> and an
option<T> in increasing order of lightweightness. They all specialise

> If one insists on calling a type boost::monad, this is a serious claim over
> quite a territory and I agree with Andrey that this calls for a review of
> Boost.Monad.

It's coming in 2016. I am rewriting the AFIO engine first using Monad
throughout, as that will debug Monad and put production ready finish
on Monad. Then I'll have to write tutorials and docs and explain my
design choices as I'm sure few will agree with them.

For reference, it's boost::monad::monad<T>, not boost::monad<T>. And
Monad specifically disclaims trying to be a full fat Haskell type
monad in C++, it is a lightweight C++-centric monad with almost zero
overhead. In my own code to date I have been finding it *amazingly*
useful, my productivity has jumped and my debugging and unit test
writing time cut significantly. I genuinely suspect I will never
write C++ code without using Monad or something very similar ever


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at