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

Subject: Re: [boost] [outcome] Ternary logic -- need an example
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-24 15:37:49

Le 24/05/2017 à 17:03, Andrzej Krzemienski via Boost a écrit :
> 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.
+1
>
> 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.
If customizing is simple, it should be simple to explain it on an 
Advanced Extension section.
If it is complex, maybe we don't want it.
> 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.
This mean that base_outcome is not part of the interface and only when 
the customization is public we can look at it.

BR,
Vicente