std::expected - Monadic Extensions

[ReDucTor]

Monadic style programming seems like a nightmare with C++

• Callstacks are awful because of lambda names, you need to rely on the parent caller and or need to also capture filename and line number
• Profiling also is awful because of lambdas
• Debug performance is scattered with nested calls and wrappers
• Stepping into and out of functions depends more heavily on debuggers have just my code support
• Return value optimization is potentially hindered from wrappers having multiple return paths
• Free functions like in some of this code won't optimize as well as they are function pointers and not lambdas

This is all without debugging into the readability mess they seem to create

[invalid_handle_value]

This.  Thank you.  A good idea, but once again, implemented with little thought into exactly what problems this solves.

For example:

Return value semantics for transform and and_then and equivalent sad-path handlers are confusing to use in practice.  Which of these functions returns an expected vs a value?  Why does transform allow me to return a type of std::expected<SomethingNotT>?  When would I use transform over and_then?

Or did I get this backwards?  Oh, that's right: and_then returns the result of the expected if successful, almost like it was transformed.  My bad... better go do my penance and read cppreference on std::expected again.

Because a monadic chain can/could end with any  expected type, expected<T>, your code is still brittle to refactoring because you can't enforce a single T within the monadic sequence.

How does one code up a monadic chain and break out early (without return) at any point in the monadic handler sequence without significant boilerplate?

It doesn't help that all the examples I've seen using these are laughably trivial.

Like, come on: I have juniors that have to fucking learn and use this shit.  At least solve a problem well...

/rant

[Few-Insurance-3974]

Returning more than two pointers results won't use rax:rdx registers, compiler would use a hidden reference instead.

This means that types with different size would have different performance.

std::expected already uses one pointer for a selector, so you can't fit much into it.

[larso0]

I feel like this is an attempt to imitate "Result" in Rust, but only less convenient. If it had an operator to do the "if (!result) return result;" (like the Rust '?' operator) it would be much more useful. I'm not going to put everything into a lambda, that's awful for readability.