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

Subject: Re: [boost] [outcome] High level summary of review feedback accepted so far
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-30 11:58:30

On 30/05/2017 00:25, Vicente J. Botet Escriba wrote:
> Le 29/05/2017 à 17:05, Niall Douglas via Boost a écrit :
>>> I can not ignore this Outcome review, but I have not see too much people
>>> saying that the semantic you have done to this functions is the good
>>> one.
>> Strange. I've been surprised at how little criticism there has been of
>> my design choices. Silence can be interpreted both ways I guess.
>
> he he, you find that your library has not been criticized?

People started off with a lot of problems with my design choices for
Outcomes. But as discussion proceeded and people thought through the
balance of factors, approximately half ended up deciding that my
original design was well balanced, including the formal empty state.

Of the remaining other half, many wanted narrow observers with
__builtin_unreachable() being used to enforce static correctness
checking at compile time. I can see value to that, so I'll be adding
varieties implementing those with implicit conversion on demand to the
runtime checked varieties.

The only other design criticism I've noticed is that APIs returning
Outcomes are not indicating via the type returned whether the empty
state is a valid return or not. I think that important, so I will
provide varieties to represent that situation too.

The common underlying storage has not been criticised apart from by
yourself Vicente, nor the design of "API personalities" sitting on top
of the common storage (again, apart from yourself). People aren't happy
with the profusion of varieties thinking that a single object design
should rule them all as is the Boost way, but I haven't got the sense
it's a showstopper for a future acceptance.

My argument that it's the same object, just wearing a different face
depending on what variety the programmer has selected, appears to have
been accepted as viable, if non-ideal in each individual's opinion.

>> I do agree with this philosophy, but if you're going to go narrow, you
>> need to go narrow on everything including .value(). You need to
>> consistently choose one or the other. No middle ground.
>
> value() id wide operator*() is narrow.

Why? Just because optional made that mistake?

If narrow is good, make the entire thing consistently narrow. I have no
objection to all member functions all being narrow. The programmer,
knowing that it is a narrow-only type, can not accidentally write the
wrong thing. It helps code auditing to be consistent and simple.

If you want to mix narrow and wide observers into the same object, I
cannot abide by making less programmer typing choose the narrow UB
observers. It is bad design, and I think it will cause programmers to
inadvertently write UB code out of laziness.

Niall

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