Re: [boost] Outcome v2 is feature complete

2017-07-11 16:09 GMT+02:00 Niall Douglas via Boost :

...

...

Github: https://github.com/ned14/outcome

Docs (highly incomplete): https://ned14.github.io/outcome/

This is a welcome development, if still a bit too-policy-heavy for my taste.

The policy is there purely to say what to do when you call .value() on a non-valued result/outcome. Compelling use cases could be:

- Delay constructing metadata to accompany any exception throws. - Use .error() as a key to look up an associative map. - Invoke Emil's Noexcept instead :)

One could have used ADL customisation points instead, but those tend to surprise end users, so I felt the policy approach was better and leave the ADL points for advanced users.

...

Regarding construction, I have the following suggestion.

Instead of reusing in_place_type, use the following tag types:

struct in_place_value_t { constexpr in_place_value_t() noexcept {} };

constexpr in_place_value_t in_place_value;

struct in_place_error_t { constexpr in_place_error_t() noexcept {} };

constexpr in_place_error_t in_place_error;

This is isomorphic but superior to using in_place_index<0> and in_place_index<1>, which were my initial choice. Now the ambiguity when T == EC is resolved and

template result( in_place_value_t, A&&... a );

always initializes the value and does not need to be disabled when T == EC.

You've struck on a very interesting design point indeed, and one which caused me a few restless nights.

My initial approach was to do exactly what you just described, after all it's how v1 implemented its tagged emplacing constructors, and v1 had a host of make_(valued|errored|excepted)_*() functions too. v1's API was all about construction of specific, named state.

But upon further reflection - and I want to emphasise that I think the jury is still out on this decision, and I may revert during the next few months - I decided that std::variant<> by-type emplacement was superior, so I went with that instead.

The reason why is subtle. These types, result & outcome, are not in the same use space as Expected where expected is perfectly reasonable due to its use case as a monad. result & outcome are specifically intended to be used for one thing and one thing only: returning value *or* error from functions.

And for that one use case, result makes no sense. Actually, it's stronger than that: result must **NOT** make sense. Everything about the API and contract must loudly proclaim that "ambiguous success and failure types are discouraged" because the type system should be set up to reflect the non-ambiguity of success vs failure.

maybe result indeed looks suspicious, but using result might come as quite natural: auto select_first_error(vector v) -> result { if (!v.empty()) return result{in_place_index<0>, v[0]}; else return result{in_place_index<1>, MyErrc::NoFirstElement}; } Regards, &rzej;