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 15:03:59

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

> >> 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>
> >>
> >
> > Ok, so are you saying that `basic_monad` (by now probably something like
> > `outcome_base`) is part of this library's public API?
>
> I'm saying that it *might* be, if reviewers think it should be so.
>
> > But the documentation leaves me with little information as to how I can
> use
> > it. Unless I missed it, I recommend that you provide a guide in the docs
> > how one can compose one's own type, and a mention that it would blend
> > nicely with other outcome-like objects, e.g., that BOOST_OUTCOME_TRY will
> > still work for a custom outcome.
>
> I did have documentation on how to do that, but one of the rounds of
> Reddit review eliminated it because it assumed too much of the average
> end user. Their argument was that 95% of end users don't want to know
> that stuff, and keeping such documentation was a major turn off for
> potential end users.
>
> There was also a valid argument by them that if you are in the 5% who do
> want to know, you'd end up studying the (well commented) source code
> anyway, and anything in the public docs is likely redundant.
>
> > Also, the reference seems to be missing some information. If I go to
> > `basic_monad`:
> > https://ned14.github.io/boost.outcome/classboost_1_1outcome_
> 1_1v1__xxx_1_1basic__monad.html
> >
> > The first thing that interests me: this is a template parametrized by
> > `implementation_policy`. What constraints does a type
> > `implementation_policy` need to satisfy to be a valid policy and meet
> this
> > library's requirements? For sure, it cannot be just any type, like `int`.
>
> Here is the policy class for expected<T, E> personality:
> https://github.com/ned14/boost.outcome/blob/master/
> include/boost/outcome/v1.0/detail/expected_policy.ipp#L407
>
> Would you say it fairly self explanatory for those knowledgeable of CRTP?
>
> The storage policy class can be found at
> https://github.com/ned14/boost.outcome/blob/master/
> include/boost/outcome/v1.0/monad.hpp#L553.
> It essentially wraps a "value_storage" which is the variant storage.
> That is a standalone implementation found at
> https://github.com/ned14/boost.outcome/blob/master/
> include/boost/outcome/v1.0/value_storage.hpp.
>
>
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.
Sure, I can peek into the code, but I do not know if it is something you
intend to keep in the new releases, or if it is just an implementation
detail, or even a bug, which you will "fix" in the next release.

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. I
read this as saying it is relatively easy to customize. But now I am
hearing I need to look into the source files and copy that. But this is
like giving me a number of concrete models of a concept and expecting of me
to synthesize the concept. I cannot do it correctly, because there is a
number of ways to do that. I may arrive at one that happens to work in this
release, but will stop in the next.

On the other hand, I understand your position. First invest in the parts
that bring value to 95% of users, and only then proceed to the remaining
problems.

Regards,
&rzej;