Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-02-06 09:19:16
>> It is overwhelming to the uninitiated
>> though, so I can see how it might appear to be complex.
> Surely that is a sign of complexity. That doesn't mean it is unnecessary complexity, however.
Not at all.
Floating point numbers are simple right? But they wouldn't be to someone
who has never seen one before. They'd be overwhelming initially until
you wrapped your head around them and stopped asking, "why can't this
just be fixed point integer arithmetic?"
>> I would argue
>> that being overwhelmed with the possibilities would be a
>> characteristic of any vocabulary library.
> The same cannot be said for shared_ptr, though it probably could be said of chrono.
I remember enormous confusion back in the day about shared_ptr vs
unique_ptr and what was wrong with auto_ptr anyway? I remember Dave
losing his temper with the argument "nothing is wrong with auto_ptr,
don't see any need for any of this totally unnecessary additional
Yet all that is gone now. One day it'll be the same with
Outcome/Expected. It'll just be there, and widely understood. People
will use it appropriately without even thinking about it.
> Perhaps the solution is basic_result and basic_outcome, with result and outcome as special, simplifying cases. That way, most can use the normal, simpler templates, but those needing all of the knobs and levers for a custom use case can use the basic_* types.
Already agreed to this during the review. Tracked by
-- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk