Re: [boost] [outcome] To variant, or not to variant?

Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-06-01 07:22:38

2017-05-31 18:09 GMT+02:00 Robert Ramey via Boost <boost_at_[hidden]>:

> On 5/31/17 1:26 AM, Gavin Lambert via Boost wrote:
>
> well since people are chiming in with their own ideas I might has well
> demonstate mine.
>
> The save numerics library (which I'm still working on trying to make all
> the required changes), includes a type called checked_result.  It turns out
> that I needed this so I just made it.  I was familar with expected<T, E>
> and of course variant, but I didn't find a "finished" implementation of
> expected - boost didn't have one, and variant, ... I just didn't think of
> deriving from it - which would be my usual inclination.  Basically I
> thought my needs were just simple to need to use a library or more general
> facility.  After all, I'm a C++ programmer and to a man with a hammer in
> his hand, the whole world looks like a nail (not Naill).  So I just wrote a
> simple class which I called "checked_result".  It's part of the safe
> numerics library implementation so I didn't feel required to document it,
> but I did anyway because I thought it would useful to do so, I have a
> simple easy to use documentation system, and it's helpful for me to do this
> to clarify my own thinking.  Here a link to the documenation for
> checked_result.
>
> https://htmlpreview.github.io/?https://raw.githubusercontent
> .com/robertramey/safe_numerics/master/doc/html/checked_result.html
>
> and here is a link to the code
>
> https://github.com/robertramey/safe_numerics/blob/master/
> include/checked_result.hpp
>
> which comes to about 230 lines (way more than I thought it would).  The
> template includes a parameter for the value type but doesn't include one
> for the error/exception type - because I didn't need it.  I might "improve"
> this in the future by making the error/exception type another template
> parameter.
>
> Readers of this humble missive are free to make of this what they desire.
>
> When the review of outcome was announced, I had the expectation that the
> proposal would be for something of like this of similar scale, simplicity,
> and functionality - but done more formally and carefully. So I'm sort of
> blown away at how this thing has grown.  I've already posted my review, so
> I'm not going to try to compare these things, I'm just thinking that when
> something seems to grow way, way out of proportion to what one original
> expectation, perhaps it's time to step back and re-consider.  Maybe the
> idea of "outcome" is too ambitious, or maybe we're trying to solve too many
> problems at once, or maybe we're trying to reconcile fundamentally
> irreconcilable view points.
>

A valid observation. In a way `expected` and `outcome` (both from
Boost.Outcome) have different goals in mind. `expected` might in fact cover
your case. They could be two libraries. The reason they come together is
that they share 95% of the same implementation. They differ only by
interfaces. Two interfaces for two different problems.

Regards,
&rzej;