Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Rob Stewart (rstewart_at_[hidden])
Date: 2018-02-08 10:01:09
On February 6, 2018 4:19:16 AM EST, Niall Douglas via Boost <boost_at_[hidden]> wrote:
> >> 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
> 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?"
You're saying Outcome isn't complex, it's just overwhelming at first, which is rather a contradiction.
Floating point types are quite simple on the surface. Using them properly is not always so easy. Indeed, they can be misused rather easily, which is similar to my concern with not actually forcing inspection of the Outcome types.
> >> 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.
Please don't ignore my statements that the complexity may well be necessary.
> 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.
That may well be, but don't ignore Charley's point about std::error_code in recent discussions. Correct usage is not always as obvious as early proponents of something suppose.
-- Rob (Sent from my portable computation device.)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk