On Thu, 19 Nov 2015 05:13:47 +0530, Vicente J. Botet Escriba
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