Subject: Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
From: Peter Dimov (lists_at_[hidden])
Date: 2017-05-15 11:14:58
Andrzej Krzemienski wrote:
> Currently, if you are using library L, the `error_code` describes
> "disappointments" typical to L's business domain. And an empty `outcome`
> represents problems related to incorrectly using the Outcome library.
Exactly. Returning an uninitialized outcome<> to the caller is incorrect use
of library Outcome. Not supposed to happen in your example.
> Also, to construct some object, it takes time. error_code is just two
> words, but why waste time on setting them if you will be overriding them
> in the course of the function call.
Overly focusing on outcome<>'s runtime performance is odd given that it's
usually returned by functions that take millions of cycles to do their job.
But either way, it's possible to optimize the default construction to still
set a bit and only create the error_code on demand when it's retrieved.
> And, in the current state you can perform a loss-less conversion (or
> "upgrade") form `option<T>` to `outcome<T>`.
option<T> is only present because of the empty state; no empty state, no
option<T>. Duplicating opional<T> is questionable, upconverting it to
outcome<T> is, too. If you call a function that optionally gives you an
object T, and you have to return outcome<T>, you need to provide a reason
for the missing T, and the silent upconversion allows you to punt. Error
context is lost because only you know why your implementation detail failed
to provide the T you asked of it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk