Hi Janet, > Addressed most of your feedback besides the std::expected thing
Great! > rather wait and see what that ends up being like once in an actual C++ > standard and use before modelling Result to be more like it. Fair enough, though it is not expected that the proposal will change much in the future (I don't remember any issues were raised with std::expected proposal since the Prague meeting, though I might have missed something). > Also, I don't see what advantage a member function template over the > current use of lambdas would offer. Invoking a std::function is as expensive as a virtual member function call (usually implemented either as virtual dispatch-based type erasure or as something similar). If you replace a member function taking std::function<...> with a member function template taking the parameterised type for the function object / invokable, you will avoid wrapping everything into a std::function thus avoiding the performance penalty. Another issue with std::function is that you can not store move-only lambdas inside it (a lambda that captures a unique_ptr for example). std::function (until we get C++23 and std::any_invocable which will further lower the number of use-cases for std::function) should only be used if you are storing a function object / invokable in a class or a class template that can not be parameterised on the function object / invokable type. Now, it is nice to see the signature of the function you need to pass to `then` when calling it, which you lose if you switch from std::function to a generic Fn parameter. But you can (since you're already using C++20) restrict it with the std::invocable concept to avoid this loss of API usage information. Cheers, Ivan -- dr Ivan Čukić i...@cukic.co, https://cukic.co/ gpg key fingerprint: 8FE4 D32F 7061 EA9C 8232 07AE 01C6 CE2B FF04 1C12