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

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-24 20:31:04

2017-05-24 22:04 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> > 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.
>

Ok.

>
> 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.
>

I agree with this assumption. But if this is the case, I think you should
not expose in the reference section of the documentation that outcome<> has
a base class. As per your explanation, it is just an implementation detail.
I am referring to this page:
https://ned14.github.io/boost.outcome/classboost_1_1outcome_1_1v1__xxx_1_1outcome.html

>
> 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.
>

Yes, you did suggest ti use expected instead. Then you also wrote:

>    - as_error() // for wide contract
> >    - error() // for narrow contract
>
> It would fit much better with the design of Outcome if these were new
> typedefs of basic_monad.
>
> How about these for the narrow contract editions of outcome<T>,
> result<T> and option<T>:
>
> - outcome_u<T>
> - result_u<T>
> - option_u<T>
>

But I mistakenly took it as saying "do it yourself". You were proposing
more of precooked "transports". Sorry.

Regarding your suggestion to use `expected<>`, I could use `expected<T,
error_code_extended>` and this would get me close to `result<T>`, but I get
no counterpart for `outcome<T>`. Or are you really proposing to add
`outcome_u<T>` to collection?

> 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/
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>