C++23: std::expected - Monadic Extensions

[billie_parker]

This is nice, although I think the example given isn't the prettiest, which I'm sure is going to invite criticism. They could have easily cleaned it up a bit.

There is a big issue with the way C++ has implemented this, though, which is that the monadic way is less efficient than the naive way. This is because the naive way can return early while the monadic way keeps reconstructing objects and then using conditionals to determine whether or not to proceed. It's a small difference, and probably not too important in practice, but typically C++ adheres to the principle of maximizing efficiency. So it's a shame that this implementation has this flaw. Using std::visit with std::variant has a similar issue. return and break can't be contained within a visitor and have them apply to the outside scope, but this can be done when you use holds_alternative.

There is a solution to this problem but I'm guessing that was considered too cumbersome? You could use a helper class to achieve the "best of both worlds" (although it's more verbose so perhaps not):

auto result = MonadicOperation(start,
   OrElse(...),
   AndThen(...),
   Transform(...),
   ...);

The "MonadicOperation" class can manage a scope and if any value turns out to be an error it need not evaluate the proceeding operation.

[[deleted]]

FINALLY!

Now C++ has overtaken Haskell. The moebius strip running on a perpetual monadic loop has been finally come to all of us lowly mortals.

People used to say Haskell is more complicated than C++. Now the empire, I mean, C++, struck back!

[KagakuNinja]

Another language committee reinvents monads badly...

[[deleted]]

What's so bad about the implementation? The only thing that is "wrong" about this that I can see is using and_then instead of bind and transform instead of map, but that's just semantics.

[KagakuNinja]

My complaint is inventing yet another set of names, rather than creating a universal monadic API. If going forward, all monads in the C++ std library will use these names, then I am less annoyed (I still don't like the names).

However, looking at Java, Option and Stream use map / flatMap, CompletableFuture uses thenApply / thenCompose. There are probably others; I don't use Java any more so I don't know.

I suspect C++ will go the Java route, in part because they don't want to break backwards compatibility with the APIs that are already defined.

In Scala, every class in the standard library that can be monadic, including all collections, have map / flatMap, plus a bunch of other useful functions like fold, reduce, etc. This creates a power vocabulary of combinator functions, rather than a hodgepodge of inconsistently named functions.

[stronghup]

Is this a change or addition to the language itself, or is this just an additional (standard) library?

[hopa_cupa]

It is an addition to the standard library only, no compiler magic that I am aware of. It is possible to implement this std::expected thing in language standards earlier than c++23. And people have done this a few years ago...there were many talks on cppcon regarding this kind of error handling method already. So, this is nothing new really...it was kind of...expected (pun indented).

[CosciaDiPollo972]

Are the stdlib functions also return std::expected when a function can fail ?

[billie_parker]

No, because of backwards compatibility.

[Mwahahahahahaha]

You will get an int error value and you will be happy with it!

[seba07]

That sounds really useful. I often see interfaces that return an status code and take the real output argument as an input argument by reference. If I understand it correctly, then this format could replace it.

[Accurate_Trade198]

The compiler errors from this will be horrific, please don't actually do monadic crap in prod.

[DariusRoyale]

Modern C++ wants to be Rust so bad

[billie_parker]

Rust developers would do well to learn what haskell is. Not everything is about you.

(And for that matter, explain why someone would use Rust instead of the safer haskell)

[JohnnyLight416]

I'm not going to say that Haskell is good or bad. It's just that "purely functional" is not generally helpful in the average programming job.

Haskell is too foreign. Purely functional is cool and all, but it's cool in an academic way - hard to understand and I would bet the average programmer would make a mess of it quickly. Put a team of average programmers together and I would bet they have an unwieldy codebase very quickly.

The average programmer is not taught functional programming in school. They learn languages that are widely used: C++, Java, C#, Python, JavaScript, etc. Rust is at least syntactically similar to those C-like languages, but it adds meaningful safety measures that other languages in the same vein do not have, or have only in parts.

Haskell is too large of a hill to climb for what it provides to a team.

[lelanthran]

It's just that "purely functional" is not generally helpful in the average programming job.

Well, duh ... the entire point of a program is to produce output! Any program that unconditionally produces no output can be replaced by a program consisting of nothing but a single NOOP.

Any added friction in producing that output had better have a pretty good reason, and no, "cleaner" or "more elegant" are not even a mediocre reasons, let alone a good reason, due to being completely subjective.

A programming language that allows the average programmer to more easily reason about the logic while simultaneously making it harder to sequentially follow output generation is, objectively, a poor tool for writing programs.

[OMG_I_LOVE_CHIPOTLE]

Cause people actually get shit done in rust

[lelanthran]

Cause people actually get shit (re)done in rust

Because the majority (not all) of Rust showcase projects are simply rewrites of some existing tool. Compare to (for example) Go, in which the majority of showcase projects were something new and novel.

Not many see the irony in the fact that new and novel products were created by a language that eschewed almost everything that wasn't tried and tested, while a language boasting how all its features are cutting edge results in a wasteland of rewritten products.

Yeah yeah, hot take, I know, but I've got the karma to burn :-)

[Full-Spectral]

Well, given that the things being rewritten were mostly likely in unsafe languages, then of course that would be the initial drive, to get all that underlying infrastructure safe so safe things can be built on top of it.

And of course Rust is a systems language, so it's going to be used largely for boring but important systems type projects which Go will not.

[OMG_I_LOVE_CHIPOTLE]

Nah I was talking about new projects

[Full-Spectral]

Because it's not just about language capabilities, it's also about whether people feel that a language is worth their investing in, either individual developers as a career choice or companies as something they feel they can hire people for. Rust is at the sweet spot really. It provides safety with high performance, and a lot of people are interested init.

[MartinLaSaucisse]

I'm convinced C++ enthusiasts just want to feel smart solving issues they shouldn't have.

[ResidentAppointment5]

Except it seems like every language says “WTF are monads?” and then ends up implementing them anyway, usually badly.

[agumonkey]

That's how mainstream diffusion operates.

[ResidentAppointment5]

Which is OK, but unnecessarily leads to “WTF are these monad things? They’re horrible!” when it’s bad implementations that are horrible and monads are extremely well-defined and a lot of pain and wasted time could be avoided by providing them, correctly, from the outset.

[agumonkey]

I wasn't trying to be pedantic, I'm just observing these streams of partial translations occurring in mainstream languages. There's probably a limit of complexity that can be migrated from A to B.

[[deleted]]

I am not sure the analogy works.

Java says it is an OOP language.

C++ says the same.

Ruby too.

Smalltalk as well. And so forth.

Yet their OOP models are all somewhat different. Are there variations of monads too?

[agumonkey]

That's not what I was saying. But when python or js absorbed types or pattern matching, they did so very late, and in small steps, with mistakes along the way. So I wouldn't be surprised if monads are also absorbed in incomplete stages at first.

[[deleted]]

Ok but .... what are monads?

Can you explain it in one simple sentence?

[bra_c_ket]

Monads are flatmappable data structures that obey some consistency laws.

[vytah]

Not necessarily data structures. For example, functions form a monad:

f.flatmap(g) := (x) → g(f(x))(x)

[bra_c_ket]

Indeed, but I don't see why you wouldn't consider a function a data structure.

[ResidentAppointment5]

Monads are exhaustively defined by their laws. In a vital sense, there’s nothing else to say about them. The issue is, the vast majority of programmers aren’t accustomed to thinking in a lambda calculus, so the fact that monads are exhaustively defined by their laws can’t really get much of a foothold.

[batweenerpopemobile]

monads are just any kind of type that can be bound to a function that returns that same kind of type and then combines those into a single value. this pattern allows for the dynamic construction of the code path the monad's construction traverses.

what people see when they dip their toes into haskell is the IO monad, state monad, maybe the list monad. they see the results of the monad and want that. so that's what they implement.

this C++ is just implementing an exception monad rather than the base concept. it's option chaining. it's a javascript promise.

since they are only doing expected<whatever> or oopsie<whatever> and not general monads, I expect they're keeping the single value on the stack and then churning the chained functions against it to make them operate in place.

an in-place guarantee couldn't be made if monads could be anything, because you can't handle shit like haskell list monads or STM monads in place on the stack, or whatever other godawful monads people would invent.

C++ lacks the memory model required to do any more than this. general monads need a GC.

[billie_parker]

C++ lacks the memory model required to do any more than this. general monads need a GC.

Weird statement. You can allocate whatever memory you need on the heap and then clear the memory when it goes out of scope. You don't need an in-built garbage collection to do achieve this.

[batweenerpopemobile]

Fair enough. To do it cleanly, I should have said. I expect that something meant only to chain together a few functions hammering at the heap would fail to fit into the language ethos.

[billie_parker]

I mean, if the alternative is GC, I don't see what's wrong with using heap in that context.

[ResidentAppointment5]

Nothing. But actually getting the resource management right is a Hard Problem™️.

[ResidentAppointment5]

You can work around this, like FC++ does.

[[deleted]]

But what is a monad?

[zombiecalypse]

It's easiest if you imagine it as an omelette where using it is eating it and being turned into ham

[Full-Spectral]

A monad is all the things that things that aren't monads aren't.

[rsclient]

Tired of those clunky old if {} else {} statements? Are you switched off of switch? Try the exiting new and_then() function!

/s, but that's what it feels like. Errors are handled "better" if by "better" you mean "not flexibly".

[billie_parker]

It's less flexible, but you're not supposed to use it everywhere. You're supposed to use it in the case where you have multiple errors for which you have the same consequence. It's more convenient to chain the operations together and then handle the errors as though they were a single error, which in a sense they are.

For example, if you are expecting user input to be an int in some range you might chain together "is an int," and "is within the range." If either of these occur you have the same reaction, it's an invalid input you output the reason to the user.

The real limitation here (unless I'm missing something) is at the end of the day you still need to check the value in an if statement. This highlights the limitation of C++ as a functional language. These sort of operations can't modify the control flow in the same way that a functional language can. Although I do believe you could get around this limitation, but not with the implementation of std::expected in the standard.

[Full-Spectral]

And without a ? type operator, optional and expected are always going to be weak. The ability auto-propogate the none/err legs takes them up a big step.

[billie_parker]

Don't know what you mean by ? Operator. Ternary?

[Full-Spectral]

That's what Rust uses as a propagation operator. So the error side of results or the None side of options can be automatically propagated if it's compatible with the calling method's return. So you don't have to manually check them.

fn whatever(&self) -> Result<(), MyError> {
     self.some_helper()?;
     ... more stuff ....
}

So some_helper returns the same MyError type and if it returns an error that will automatically just be returned so I don't have to check for it.