On Thu, Sep 13, 2018 at 11:52 AM Emil Dotchevski
On Thu, Sep 13, 2018 at 12:22 AM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
czw., 13 wrz 2018 o 01:26 Emil Dotchevski via Boost < boost@lists.boost.org> napisał(a):
On Wed, Sep 12, 2018 at 3:25 PM Andrzej Krzemienski via Boost < boost@lists.boost.org> wrote:
It appears that this functionality is now deeply burried in policies and other complexity (assuming it still exists, which is still unclear to me).
I would not agree with this characterization. It is assumed that the most natural choice for `EC` would be `error_code`. The type the user would use is `result<T>` (second and third parameter defaulted), and the `fun().value()` idiom that you described works out of the box.
If the user wants her custom `EC` (other than an enum plugged into error_code framework)
I don't understand why are we talking about error codes in this context. The use case I'm talking about does not use error codes, its only way to report an error is to throw an exception, it's just that the throw is postponed until value() is called.
I mispoke, please disregard the above.