Re: [boost] [outcome] Whether to default EC = error_code for result?

Subject: Re: [boost] [outcome] Whether to default EC = error_code for result?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2018-01-23 10:34:26

2018-01-23 10:48 GMT+01:00 Niall Douglas via Boost <boost_at_[hidden]>:

> Just wondering what the reviewers' opinion is on the choice by Outcome
> to default `result<T, EC = std::error_code>`?
>
> 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
> <system_error> which drags in <string> and imposing compile time costs
> on those who don't use <system_error>. 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 <system_error2> without the problems with <system_error> (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 <status_code> -- 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 `<system_error>`, 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 `<system_error>` 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<T, EC>` 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<T, std::error_code>;
```
Similarly to what you do for `unchecked` and `checked`.

Regards,
&rzej;