Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2018-02-01 06:30:05

On 1/02/2018 19:09, Emil Dotchevski wrote:
>> The factory method technique also allows somewhat restoring a stronger
>> invariant -- only the constructor and destructor need to cope with empty or
>> otherwise uninitialised instances; other methods can be reasonably assured
>> that no such instances escaped the factory method.
> 
> This is true only if you use exceptions to report errors from the factory.
> Otherwise it is most definitely NOT reasonable for member functions to
> assume that the object has been initialized, because nothing guarantees
> that an error reported by the factory wasn't ignored.

The factory itself provides that guarantee.  One such pseudo-code 
implementation might be:

   static std::unique_ptr<A> A::create(args...) noexcept
   {
       // the constructor is itself noexcept and cannot fail
       std::unique_ptr<A> a(new (std::nothrow) A(arg1));
       if (!a)
           return nullptr;

       if (!a->private_init_stuff(arg2, arg3, ...))
           return nullptr;

       return a;
   }

This can't return *why* it failed to create an A, but it cannot return 
an invalid A, assuming that private_init_stuff always returns false if 
it failed to satisfactorily init the object.

Thus any public members of A (and basically anything other than the 
constructor, destructor and what is directly called from here or there) 
can always assume it has a fully valid instance, whatever that means.

If you don't like the heap usage, the same concept applies if it returns 
an optional instead of a pointer (assuming it has a no-fail move).

With Boost.Outcome, it can be implemented exactly as above (including 
not letting an invalid instance escape), but *also* indicate a failure 
reason to the caller, through a simple change to the return type.

Are exceptions cleaner and shorter?  Of course.  But this still works, 
and some people will prefer it due to perceived latency issues with 
exceptions, or just personal issues with exceptions in general, or with 
"hidden code paths" expressly due to the code being shorter.  (Whether 
those issues are real or not, I cannot say.)