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/