It would fit much better with the design of Outcome if these were new typedefs of basic_monad.
How about these for the narrow contract editions of outcome<T>, result<T> and option<T>:
- outcome_u<T> - result_u<T> - option_u<T>
Ok, so are you saying that `basic_monad` (by now probably something like `outcome_base`) is part of this library's public API?
I'm saying that it *might* be, if reviewers think it should be so.
But the documentation leaves me with little information as to how I can use it. Unless I missed it, I recommend that you provide a guide in the docs how one can compose one's own type, and a mention that it would blend nicely with other outcome-like objects, e.g., that BOOST_OUTCOME_TRY will still work for a custom outcome.
I did have documentation on how to do that, but one of the rounds of Reddit review eliminated it because it assumed too much of the average end user. Their argument was that 95% of end users don't want to know that stuff, and keeping such documentation was a major turn off for potential end users. There was also a valid argument by them that if you are in the 5% who do want to know, you'd end up studying the (well commented) source code anyway, and anything in the public docs is likely redundant.
Also, the reference seems to be missing some information. If I go to `basic_monad`: https://ned14.github.io/boost.outcome/classboost_1_1outcome_1_1v1__xxx_1_1ba...
The first thing that interests me: this is a template parametrized by `implementation_policy`. What constraints does a type `implementation_policy` need to satisfy to be a valid policy and meet this library's requirements? For sure, it cannot be just any type, like `int`.
Here is the policy class for expected