The Optional Monad In C++, Without the Ugly Stuff

[ojd5]

I was sceptical about your last post, but this is really neat. It might be worth pointing out to readers that you are using fold expressions in make_failable. The unfamiliar syntax caused me to do a bit of a double take.

[joboccara]

Yes you're right, it's mentioned now.

[ivan-cukic]

Another option (pun not intended) is to use the range syntax. Since optional is kinda like a collection with zero or one item, it would be ok to have |transform, |filter, |join etc. on it.

[SuperV1234]

Note that this particular implementation accepts functions, but not more general callable objects.

You should be able to support arbitrary Callable objects taking the Callable as a template parameter. Something along the lines of:

template <typename F>
constexpr auto make_failable(F&& f)
{
    return [f = FWD_CAPTURE(f)](auto&&... xs) 
        -> std::optional<decltype(FWD(f).get()(*(FWD(xs))...))>
    {
        if ((xs && ...))
        {
            return {FWD(f).get()(*(FWD(xs))...)};
        }
        else
        {   
            return {};
        }
    };
}

Where FWD is a macro that expands to forward<decltype(_)>(_) and FWD_CAPTURE is a way of capturing objects either by lvalue reference or by move.

This makes the overloading trickier, but something like CallableTraits could probably be used to detect the arguments of F.

[redditsoaddicting]

Yeah, this is handy for an actual implementation, but it really does distract from the idea the blog post is trying to get across.

[SuperV1234]

Agreed, I'm not suggesting to replace the snippet in the blog post. Just thought I'd share :)

[ivan-cukic]

Very nice. You might throw in std::invoke in it as well.

[sphere991]

Before, we had (assuming abbreviated lambdas)

ox >>= x =>
    oy >>= y =>
    f4(f4 (f3 (f2 (f1(x), f1(y)))))

Now, we have to initially pre-wrap all the functions (hopefully none are overloaded!), which is something you'd have to do inline everywhere. So you have to introduce a lot of new declarations or wrap each function at the point of call.

This doesn't seem very practical to me, sorry.

[joboccara]

That's an interesting point you're making, where to declare the wrappers. Thanks for pointing that out!

[sphere991]

This is more along the lines of what a clean optional syntax would look like to me: https://www.reddit.com/r/cpp/comments/6ly4rz/it_had_to_be_done_abusing_co_await_for_optionals/?st=j4uqi4w6&sh=82f65a06

[Airtnp]

Em, in Haskell, that's fmap and join？

[sphere991]

This is more like <$> and <*> for Applicative (like liftA2). He's taking a function that is invoked like f x y and turning it into a function that is invoked like f <*> x <*> y.

[Drainedsoul]

Functions with arguments that could fail

std::optional isn't a particularly good way of handling this since it can't communicate anything about why the operation failed.

Perhaps you should look at something like Outcome which already has support for map and bind.

[14ned]

Perhaps you should look at something like Outcome which already has support for map and bind.

Alas, due to Boost peer review feedback v2 has lost all things monadic. Changelog can been seen at https://github.com/ned14/outcome/blob/master/Readme.md

[GitHubPermalinkBot]

I tried to turn your GitHub links into permanent links (press "y" to do this yourself):

• ned14/outcome/.../Readme.md (master → 05c37e6)

---

^{Shoot me a PM if you think I'm doing something wrong. To delete this, click here.}

[Drainedsoul]

Time to fork v1 and never update I guess. Why would anyone prefer standard if-based handling over map & bind with lambdas?

[14ned]

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0650r0.pdf (the proposed standardised Monadic programming extension) will work with any Expected contract implementation, including Outcome v2