2017-05-30 18:11 GMT+02:00 Peter Dimov via Boost
Niall Douglas wrote:
1. I have been persuaded to use longer more appropriate naming for result<T> and outcome<T>, so now the typedefed varieties with implicit conversions to their empty-capable form indicated by "=>" are:
- static_checked_outcome<T> => static_checked_optional_outcome<T> static_checked_result<T> => static_checked_optional_result<T>
...
- runtime_checked_outcome<T> => runtime_checked_optional_outcome<T> runtime_checked_result<T> => runtime_checked_optional_result<T>
...
Nobody is proposing that end users actually type out the full name each and every time they use them, and the documentation will make that clear.
As I already said, for me this takes away the whole point of the library, which is to provide STANDARD result types which people use in their public APIs.
If everyone is typedefing their own varieties, this doesn't provide a standard infrastructure. Sure, it would be useful for people who control all of their code, but no more than that.
There should be one and only one result<T>, and one and only one outcome<T>, with those names, which the world should use.
I support this. I like the initial choice of this library. What percentage does this make of people wanting one outcome and one result?
Let's first see if people who favor a narrow interface are satisfied with value_if, which for me is a very good compromise. Once you have a raw pointer, things are as narrow as it gets.
I'll respond to this separately. Regards, &rzej;