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-27 22:46:00

>> I would agree. But well, we were outvoted. And that probably means
>> rejection of this library, as the presented library does not implement
>> what the majority want (yet).
>>
> 
> How do you count the votes? How many votes did you count? What option did I
> vote for?

It's more a case of me judging where majority opinion is at, and
deciding on if I can accommodate that majority opinion at the same time
as preserving what I think are red line issues and design concerns. I
appreciate that this philosophy of giving people what they want instead
of the "correct" single vision is not popular here, but I believe in
market evolution and competitive pressure. So the right design or
designs would win out in time through a process of evolutionary
pressure, and it's my job to select the designs to compete and how they
should interoperate with one another, and then throw it onto the market
to decide what is the best mix.

I personally think I'll have very little use for the narrow contract
varieties, but I've been convinced by the non-empty-capable vs
empty-capable distinction because it means that my public API functions
can specify via the type they return whether an empty return is possible
or not, thus more accurately specifying their public contract. That, and
the fact I can still use a receiving empty-capable variety for detecting
when loops haven't found what they were looking for etc I find very
compelling.

> I indicated my preference towards not having initiali empty state (default
> constructor), on basis that I cannot think of a use case for it. Since you
> are still trying to provide `optional_result`, it means you must see some
> use case for it.

I see a lot of use for it. I also have a lot of code written which makes
great use of that empty state. The fact that the empty state can never
arise on its own and can only result from the programmer introducing it
into a logic chain somewhere I think is something that people either get
and say "that's very useful" or they don't get and say "empty states
need to be removed entirely as an obvious design mistake". I am
battling, sometimes, that people think the empty state has something to
do with variant's valueless_by_exception(), that it arises due to an
exception throw. That isn't the case in Outcome: empty is a truly third
state.

The fact I've chosen that non-empty-capable silently converts to
empty-capable I also think is underappreciated. It enables the best of
both worlds by closely aligning the type used to the exact use case.
Some would say that is a lack of vision and willingness to decide on my
part. I would claim it to have been my original vision for this library
all along.

> Having so many types doesn't look good to me either. I would be more
> comfirtable with result<> having empty state but with additional observers
> with narrow contract.

People are getting hung up on the multitude of types. They're just API
personalities onto an identical implementation. They're just different
ways of speaking to the same variant storage, so basically we are using
the C++ type system like a pair of glasses onto the exact same view,
with well defined rules for changing which glasses you're wearing as
demand presents.

Niall

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