Comments on: Multiple error handling with the optional monad in C++

By: Michael Entin

Michael Entin — Fri, 03 Nov 2017 07:22:00 +0000

I would say the end result is horrible, same nested functions – lacking the benefits of Haskell, where you simply compose functions.

It is pretty trivial to make a better version, where you could simply compose functions without ugly syntax. You just need to use (1) left associative operator (i.e. >> rather than >>=, >>= is left-associative in Haskell but not in C++), (2) use Currying. The end result might look like this (it compiles and works, but probably can be improved):

optional f1(int a);
optional f2(std::pair bc);
optional f3(int d);
optional f4(int e);

// and here is how simple the actual function composition looks like:
auto x = f1(3) >> add_arg(f1(4)) >> f2 >> f3 >> f4;

By: Jonathan Boccara

Jonathan Boccara — Wed, 16 Aug 2017 17:09:00 +0000

In reply to Dmitry Pinaev. In fact I've split in into two steps, I first show the implementation, then the prototype. I made that choice because each of them needs focus to understand, and I put the implementation first because it seems more natural to grasp to me. Anyway, thanks for pointing this out, here is the complete implementation:



template
auto operator>>=(boost::optional const& t, TtoOptionalU f) -> decltype(f(*t))
{
    if (t)
    {
        return f(*t);
    }
    else
    {
        return boost::none;
    }
}

By: Dmitry Pinaev

Dmitry Pinaev — Sat, 12 Aug 2017 22:13:00 +0000

Maybe I should have read this post another two times but… did you intentionally omit the implementation of your operator>>= ?

By: amccartney

amccartney — Sat, 15 Jul 2017 01:23:00 +0000

The >>= is right-to-left associative in C++. That might lead to surprising results when chaining binds together

By: Jeremiah O'Neil

Jeremiah O'Neil — Thu, 13 Jul 2017 16:46:00 +0000

I just learned that short-circuiting and left-to-right evaluation order are guaranteed for non-overloaded && (C++ standard 1.9.18)! So, we can simply write:


if (optional x, y;
    (x = f(3)) && (y = f(4)) && (x = g(*x, *y)) && (x = h(*x)) && (x = h(*x)))
{
   // we can use *x 
} 
else 
{
   // we know that something went wrong 
}

By: Jeremiah O'Neil

Jeremiah O'Neil — Tue, 11 Jul 2017 18:53:00 +0000

Good post! It starts practical and gets interesting. On the practical side of things, I think the naive composition of optionals is just fine when there are only a few errors one may run into; it's not hard to write or read and it's easy to add specific error handling logic or logging to it. Plus, with the new if statement initializers you can write it more concisely and without bleeding any temporary variables:


optional result;

if (auto b = f(3), c = f(4); b && c)
{
    if (auto d = g(*b, *c); d)
    {
        if (auto e = h(*d); e)
        {
            result = h(*e);
               }
    }
}

By: Adi Shavit

Adi Shavit — Tue, 11 Jul 2017 11:50:00 +0000

In the C-like example, another problem, is that you are always calling all the functions even when an error is reported, thus wasting effort or worst, passing garbage to the functions.

[*typo: “wildly” => “widely”]

By: Cristian Pallarés

Cristian Pallarés — Sat, 08 Jul 2017 15:58:00 +0000

In reply to Sarfaraz Nawaz. You are totally right

By: Sarfaraz Nawaz

Sarfaraz Nawaz — Fri, 07 Jul 2017 15:28:00 +0000

In reply to Cristian Pallarés. You dont need the lambdas in the `then()` functions. You can just write: .then(f2).then(f3).then(f4);

By: Cristian Pallarés

Cristian Pallarés — Wed, 05 Jul 2017 14:15:00 +0000

In reply to Jonathan Boccara.

That will require a templated variadic class and a variadic method. Maybe I’ll try to implement it… I don’t have much time these days 🙁