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

2017-05-24 22:04 GMT+02:00 Niall Douglas via Boost :

...

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

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