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

2017-05-24 16:38 GMT+02:00 Niall Douglas via Boost :

...

...

...

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

Le 24/05/2017 à 17:03, Andrzej Krzemienski via Boost a écrit : the customization is public we can look at it. BR, Vicente