2018-01-23 10:48 GMT+01:00 Niall Douglas via Boost :

Just wondering what the reviewers' opinion is on the choice by Outcome to default `result`?

That made sense back when Boost.System's error_code aliased `std::error_code` when being compiled under C++ 11 or better (i.e. always in the case of Outcome). But now that Boost.System's error code looks to be becoming a superset of `std::error_code`, I am now wondering whether to no longer default it at all to anything.

Arguments in favour of this:

1. Expected no longer defaults E to anything, thus avoiding including which drags in <string> and imposing compile time costs on those who don't use . I did some more benchmarking, on a recent GCC on a 4Ghz CPU it's about 0.6 secs per compiland being added on Linux, and more like a second on Windows with MSVC.

2. As is pretty clear from the tutorial, we expect all non-trivial uses of Outcome to typedef `result` into the local namespace anyway. So defaulting `EC` only really benefits trivial use cases.

3. I think it now inevitable I need to go implement a much lighter weight without the problems with (e.g. header only use problems, heavy includes, underspecified semantics, hardcoded use of `int`, memory allocation and so on). I'll send it to SG14 for them to get it into the standard if they like it (they will, it'll tick all their boxes, WG21 may be more challenging).

Maybe, as others observed, you should call it -- those codes are not necessarily errors.

Arguments against this:

1. Use of `std::error_code` ought to be encouraged rather than UDTs such that Outcome using code is not anti-social to other code. Defaulting the type sends a clear message on this.

2. Removing the defaulted `EC` on `result` is asymmetrical to defaulting `EC` and `EP` on `outcome`. I personally don't mind it, different typical use cases means different defaults, but others may find the asymmetry upsetting.

So, are you saying you want `EC` with no default in `result` and `EC` to default to `std::error_code` in `outcome`?

3. The relevant policies need to include ``, otherwise they don't compile. So the include of `result.hpp` would need to be split into a `result.hpp` and a `error_code_support.hpp` with the latter containing the `` stuff.

Thoughts?

If what you are saying is true, that all non-trivial usage will be to compose one's own type, then you could provide `basic_result` to be used for building custom types: no defaults. Next, in another header you could provide an alias: ``` template <typename T> using result = basic_result; ``` Similarly to what you do for `unchecked` and `checked`. Regards, &rzej;