Boost logo

Boost :

Subject: Re: [boost] [outcome] Requesting pre-review of Boost.Outcome tutorial
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-11 15:23:54


Am 11.11.2016 um 20:27 schrieb Niall Douglas:
> Dear Boost,
>
> I am hoping to bring Boost.Outcome, a C++ 14 library providing a
> factory and family of policy driven lightweight monadic
> value-or-error transports, into the Boost peer review queue by March
> 2017 followed shortly thereafter by an ACCU talk in April if my talk
> proposal passes their programme committee. To that end, I've written
> an explanation and a sort of tutorial explaining the history and
> purpose of Outcome at https://ned14.github.io/boost.outcome/ and I'd
> greatly appreciate if people could tell me:
>
> 1. Does it make sense?
Yes, it does. Especially for embedded development, this seems very useful.
> 2. Do you think you could use Outcome in your own code after reading
> it?
I'd think so.
> 3. Do you think you would want to use Outcome in your own code after
> reading it?
Yes.
> 4. Are there any missing parts which are showstoppers?
I'm not entirely sure, I'd have to use it.

Is there a way to switch the behaviour depending on whether exceptions
are available? I.e. throw if they are, elsewise use the result? Or would
you consider this a horrible Idea?
The reason for me would be, that I could write a library which's user
could use it both ways, depending on what he has available. I think if I
wanted to provide a way to have a function-call using an exception or an
error_code, I'd go with the C++11 way, i.e. distinguish this in the
signature. So for me the main use-case would be, that exceptions might
not be available.

> My thanks in advance. Be aware the install stuff described at the
> start doesn't work yet. The reference documentation is also quite
> patchy thanks to doxygen not understanding CRTP. All that stuff and a
> fair bit more remains to fix before it's ready to enter the Boost
> peer review queue.
>
> Niall
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk