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

2017-05-31 18:09 GMT+02:00 Robert Ramey via Boost :

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