Re: [boost] [outcome] How to drop the formal empty state

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-26 16:16:50

On 26/05/2017 15:23, Peter Dimov via Boost wrote:
> Niall Douglas wrote:
> 
>> But after I built up some experience, now I tend to write this instead:
>>
>> result<Foo> something()
>> {
>>   result<Foo> ret(Foo());
>>   Foo &foo = ret.value();
>>   ... build foo ...
>>   return ret;
>> }
> 
> This takes us back to "what if due to a logic error the code that should
> build `foo` doesn't?"
> 
> And since you've constructed `ret` to non-empty, the point of empty is,
> again, lost.

But if I am writing my implementation that way, it is because there is
no purpose here to my function returning empty. Else I would implement
it differently.

I appreciate that the above is me speaking vaguely from experience and
without concrete evidence. But I think most programmers, once they are
using these objects for a while, will start to naturally write code
which never *could* return an empty object if returning an empty object
makes no sense for that function. Equally, if some function could return
an empty object, the programmer will structure their code appropriately.

To be honest, writing code using these objects becomes so second nature
after a while you stop thinking about why you write the code you do. You
just do it and certainly with code written using Outcome, most of the
time the code works first time, including error handling, which is
unusual. My port of AFIO v2 to POSIX was particularly weird - I wrote
hundreds of lines of new code. Damn thing passed all the unit tests
written for Windows very first time. I actually had to step through with
the debugger to prove it to myself, I didn't believe the result.

Niall

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