Subject: Re: [boost] [outcome] To variant, or not to variant?
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-05-31 16:09:38
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
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.
and here is a link to the code
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk