Re: [boost] [outcome] Second high level summary of review feedback accepted so far

Subject: Re: [boost] [outcome] Second high level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-31 12:16:50

On 30/05/2017 22:38, Andrzej Krzemienski via Boost wrote:
> 2017-05-30 16:58 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:
>> With regard to the previous high level summary at
>> http://boost.2283326.n4.nabble.com/outcome-High-level-
>> summary-of-review-feedback-accepted-so-far-tp4694767.html,
>> I have made only these changes to the changes in that summary:
> 
> Thanks Niall, for the summary. But now, after these changes, the review I
> am still writing is useless, as it applies to a different library. Maybe we
> should schedule another review?

As I have said in a number of posts previously, I haven't been convinced
to change much yet apart from drop some member functions for the
runtime-checked empty-capable editions which are the ones presented for
review. The behaviours of those are still being actively discussed e.g.
should exception() synthesize an exception_ptr from an errored state?

And even in the added varieties, it's not like I am writing any new
source code. The statically checked varieties just leave out the runtime
checks, otherwise they're literally identical consisting of identical
implementation. The non-empty varieties just leave out the empty state.
It's the same library as presented.

>> 1. I have been persuaded to use longer more appropriate naming for
>> result<T> and outcome<T>, so now the typedefed varieties with implicit
>> conversions to their empty-capable form indicated by "=>" are:
>>
>> - static_checked_outcome<T> => static_checked_optional_outcome<T>
>>   static_checked_result<T>  => static_checked_optional_result<T>
>>
> 
> No, no. I strongly suggest to provide only one outcome, with empty state if
> needed, and both narrow and wide contracts. We have learned to live with
> such types in C++, even if they are far from perfect.

I am absolutely sold on the empty-capable vs non-empty-capable being
represented in the type system. Makes a big difference to public API
contracts.

I may choose to drop the typedef for the statically checked varieties,
but the underlying non-public template is capable of all.

I'll see what Charley's report recommends before deciding.

>> 3. Under the assumption that error_code_extended's use of a static
>> global ring buffer would be controversial in this review, I hacked a
>> quick and dirty solution expecting to have to remove it. Now we know
>> that few disapprove, a more serious implementation will be needed.
>> https://github.com/ned14/boost.outcome/issues/52
> 
> 
> I am not sure of that. It was my impression that many potential reviewers
> were put off by documentation and legal/structural issues, and stopped with
> their review at that point. Once you have move thes obstacles out of the
> way, you will likely draw more reviewers, and who knows what they have to
> say about the ring buffer.

Dunno, I got quite a few detailed questions on it, and people seemed
pleased with the design rationale once they'd thought about it.

Anyway, I intend to do something better than the current hack. Certainly
with more storage, anyway.

Niall

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