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.
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk