Boost logo

Boost :

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
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

Boost list run by bdawes at, gregod at, cpdaniel at, john at