Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

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.