Haskell style “Maybe” type & *chaining* in C++11

Question

I repeatedly find myself requiring Haskell style Maybe (especially Maybe chaining) in my project at work. E.g. withdrawal request from customer and we are give

Answer 1

Good start, but I think you're over-engineering in your zeal to make your class foolproof. Personally I'd recommend 'worse is better'. First, let's reuse Boost.Optional:

struct nothing_type {
    template
    operator boost::optional() const
    { return {}; }
};
constexpr nothing_type nothing;

template
boost::optional
just(T&& t)
{
    return std::forward(t);
}

template
auto maybe_do(Option&& option, Functor&& functor)
-> boost::optional<
    decltype( functor(*std::forward(option)) )
>
{
    // Forwarding 
    if(option)
        return functor(*std::forward(option));
    else
        return nothing;
}

Some various explanations on things that aren't really important:

• nothing doesn't have to be an object, it can still be a function (returning nothing_type) like you're doing. That's not important.

• I made sure to preserve the reference semantics of just to match your version. As a bonus though, it can still deal with values. As such, with int i = 0; auto maybe = just(i); then the type of maybe will be boost::optional, whereas with auto maybe = just(42); it is boost::optional.

• the *std::forward(option) can actually simply be *option as Boost.Optional is not move-aware and not many compilers support lvalue/rvalue *this (which would be needed for it to matter). I just like future-proofing perfect-forwarding templates.

• you can still name maybe_do operator| instead. I would however recommend putting it in a namespace and use using ns::operator| (or using namespace ns;) to put it into scope. You can additionally (or instead) add an SFINAE check (or write several overloads) to make sure it only participates in overload resolution at appropriate times. I'm advising this to avoid namespace pollution and annoying errors.

The important stuff:

It may look like maybe_do is severely underpowered compared to your overloads that can deal with member pointers. But I'd recommend keeping it simple and instead putting the burden on client-code to adapt member pointers:

auto maybe = /* fetch an optional from somewhere */
maybe_do(maybe, std::bind(&T::some_member, _1));

Similarly client code can use std::bind to do the poor man's partial evaluation:

maybe_do(maybe, std::bind(some_functor, _1, "foo", _2, bar));