Re: [boost] [err] RFC

Subject: Re: [boost] [err] RFC
From: Domagoj Šarić (dsaritz_at_[hidden])
Date: 2015-11-19 11:24:32

On Thu, 19 Nov 2015 05:13:47 +0530, Vicente J. Botet Escriba  
<vicente.botet_at_[hidden]> wrote:
> Your example can be adapted to several variables of type  
> faillible_result<T>
>
> auto a = calcA();
> auto b = calcB();
> auto c = calcC();
>
> if (a.value()) // can throw :(

This example was used in one of the previous discussion on other similar  
proposals I listed in my opening post...It does not apply here as it will  
cause a compiler error...
The only similar 'loop hole' would be if you created a, b and c as above  
but did not touch them and never tested with asserts enabled (as Gavin  
noticed) but, besides being 'obviously wrong', it is also rather  
convoluted...
Finally, as I mentioned earlier, even this case would be deterministically  
caught at compile time if && destructors were added to the language (and I  
see no reason why they shouldn't be).

...which brings us a bit more into 'detail' land :) where I'd like to  
'state' one more, related, thing I miss from the langauge: 'template  
parametrizable' attributes (like noexcept) that would tell the compiler  
for example:
- that after a function is called the object is in a destroyed-like state  
(i.e. the destructor does not need to be called) - the obvious use is to  
prevent useless destructor calls after the object has been moved
- that an object is pod-like/safe to pass in registers even though it has  
a copy constructor
these would greatly help with implementation complexity and codegen  
quality in essentially-wrapper libraries like err or optional...

-- 
"What Huxley teaches is that in the age of advanced technology, spiritual  
devastation is more likely to come from an enemy with a smiling face than  
 from one whose countenance exudes suspicion and hate."
Neil Postman