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

Subject: [boost] [outcome] Whether to default EC = error_code for result?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-23 09:48:51

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).

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.

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?

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/