That's surprisingly hard to answer in a meaningful way. I guess the former form you are writing code to generate a Foo, and then wrapping that Foo up into result<Foo> for the purposes of indicating success. The second form you are being more specific, you are not generating a Foo, you are generating a result<Foo>. Somehow the code feels right with the second form. It's somehow more idiomatic.
The problem with this idiom is that you have a reference to something that could become an error :( We are introducing with this idiom a possibly reference leak. But this is C++.
Actually no. We are in fact employing a two stage object construction design pattern. Let me flesh out the example code a bit so it's more realistic: ``` class Foo { A *a {nullptr}; B *b {nullptr}; public: constexpr Foo() noexcept {} // never throws, constexpr ~Foo() { // destructor is capable of destroying partially // constructed instances! delete b; // really if(b) delete b; delete a; // really if(a) delete a; } }; result<Foo> make_Foo() noexcept { // constexpr construct a valid but uninitialised Foo instance result<Foo> ret(Foo()); // get a reference to the Foo instance to be returned Foo &foo = ret.value(); // initialise member variable "a" in Foo foo.a = new(std::nothrow) A(); if(foo.a == nullptr) { return make_errored_result(std::errc::not_enough_memory); } // initialise member variable "b" in Foo foo.b = new(std::nothrow) B(); if(foo.b == nullptr) { // Foo's destructor will be called by result<Foo> being unwound, // thus destroying the A object created earlier return make_errored_result(std::errc::not_enough_memory); } // RVOed on C++ 14 as well as C++ 17 return ret; } ``` Every object in AFIO v2 is constructed like this. A static init function for every class returns a result<TYPE> and is implemented using a two-stage construction design pattern like the above. The constexpr noexcept constructor never initialises anything except trivial types, and once the object has exited the constexpr constructor it is now valid and its destructor will definitely be called. So returning to my previous post to Peter, in the above there is no good reason to ever return an empty result. It would make no sense, so you never write code which could from the beginning. And type Foo knows how to destroy a partially constructed edition of itself, so your init function can bail out with an error at any time and all resources are tidied up. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/