Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-18 23:04:26

>> Once you've been using these things in your own code for a bit, for
>> especially low level systems libraries you'd never willingly go back.
>> The difference is very similar (to me at least) to that feeling you have
>> when you must go back to writing C++ 98 without Boost after you've been
>> using C++ 14 for a quite a while.
> 
> I trust your judgement on this. I just wish short examples in the docs
> could convince me about that.

I did have some examples culled from real world usage in an earlier
edition of the tutorial. People found them too hard to grok. They wanted
toy, unrealistic examples instead, which is what you have now.

>> All that said, 60-70% of C++ would see no benefit to using Outcome nor
>> Expected. Such code is always better off using only C++ exceptions.
>>
> 
> That leaves 30-40%, which is a huge market share.

If you follow the C++ Reddit on the topic of Either and Maybe monads, in
the very long threads of bikeshedding you'll find one fairly widely held
opinion that choosing something like Outcome is effectively the same as
a library implementation of pre-table EH whereby a fixed overhead is
added to all code execution in exchange for various benefits such as
very fast handling of failure. Some would also argue that by forcing the
programmer to manually write out the logic for handling failure at the
point of failure, it improves auditing and maintenance of failure
handling. This sort of C++ code, mostly low level systems programming,
benefits from using something like Outcome.

However a majority of C++ very rarely needs to handle more than one form
of failure in any given local use context. For this sort of C++,
exceptions prevent cluttering the code with failure handling, and remove
that fixed overhead from execution. They're a better choice, a better fit.

There are secondary arguments about cost of debugging and bringing code
to production quality, but those are hard to prove. Obviously the games
and finance industries take a pretty consistent and strong opinion there
i.e. globally disable all C++ exceptions, but other users very
interested in low latency do make use of C++ exceptions, so if you have
talented programmers anything is possible, even easy. I suspect that in
games and finance that assuming top notch programmers everywhere in a
large org is unwise, so better avoid ruinous surprise by someone messing
with code they don't understand.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/