Andrzej Krzemienski wrote:
Currently, if you are using library L, the `error_code` describes "disappointments" typical to L's business domain. And an empty `outcome` represents problems related to incorrectly using the Outcome library.
Exactly. Returning an uninitialized outcome<> to the caller is incorrect use of library Outcome. Not supposed to happen in your example.
Also, to construct some object, it takes time. error_code is just two words, but why waste time on setting them if you will be overriding them in the course of the function call.
Overly focusing on outcome<>'s runtime performance is odd given that it's usually returned by functions that take millions of cycles to do their job. But either way, it's possible to optimize the default construction to still set a bit and only create the error_code on demand when it's retrieved.
And, in the current state you can perform a loss-less conversion (or "upgrade") form `option<T>` to `outcome<T>`.
option<T> is only present because of the empty state; no empty state, no option<T>. Duplicating opional<T> is questionable, upconverting it to outcome<T> is, too. If you call a function that optionally gives you an object T, and you have to return outcome<T>, you need to provide a reason for the missing T, and the silent upconversion allows you to punt. Error context is lost because only you know why your implementation detail failed to provide the T you asked of it.