Boost logo

Boost :

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.
> .com/robertramey/safe_numerics/master/doc/html/checked_result.html
> and here is a link to the code
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at