I have been playing with these recently. The reason why you get the inefficiency is because the invocable can change the type, so the methods have to return by value.
It gets even more complicated with std::expected, where the unhappy path needs to potentially pass through the and_then that can change both the result and error types.
It's an interesting API choice, it does lean very heavily on the compiler to optimize.
that's an excellent point! There's never "right" or "wrong" choice, which is why it's important to understand the particular context and gradient for optimizations. What fun would be engineering without trade-offs after all? :)
I have been playing with these recently. The reason why you get the inefficiency is because the invocable can change the type, so the methods have to return by value.
It gets even more complicated with std::expected, where the unhappy path needs to potentially pass through the and_then that can change both the result and error types.
It's an interesting API choice, it does lean very heavily on the compiler to optimize.
that's an excellent point! There's never "right" or "wrong" choice, which is why it's important to understand the particular context and gradient for optimizations. What fun would be engineering without trade-offs after all? :)