Re: [boost] [outcome] Ternary logic -- need an example

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-24 20:04:58

> I am not entirely satisfied with this reply. I need this documented not
> because I do not know how to do it (well, this also), but because this way
> you commit to supporting this form of customization in subsequent releases.

Ah but I haven't, nor was I intending to.

Earlier rounds of feedback from Reddit convinced me that customising
basic_monad is a very niche enterprise. Very, very few users of Outcome
will want to do that.

Furthermore, a big aim of this review was to find out what other
precooked varieties of basic_monad would be preferable so we can expand
the family of precooked implementations. That would further reduce the
need for anyone to dive into writing policy classes for basic_monad.

> I am also not sure I belong to this 5%. I complained about the wide
> contracts, and your response was I should write my own customization.

That was *not* my response.

My response was to go use expected<T, E> if you want narrow contracts.

Now, the way it looks like consensus opinion is going is that most
reviewers want a really long template with lots of template parameters
twiddling all sorts of knobs like what default construction should do,
wide vs narrow observer functions, empty state to be formal,
nearly-never or never and so on. End users then template alias the
Outcome long template into a local edition configured as they want with
whatever local name they want.

If that's the consensus opinion, that's a fair bit of work to implement
and I'm fairly sure it will affect compile times, but I am open to it.
The single implementation-many personality design I chose is very
amenable to such knobs for twiddling.

Niall

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