Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial

Subject: Re: [boost] [outcome] Requesting second pre-review of Boost.Outcome tutorial
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-01-17 03:23:28

>> Finally back this statement of yours:
>>
>>> I strongly believe that this is the wrong thing to do (or at least
>>> controversial) to annotate a function that can fail-but-not-throw as
>>> noexcept. It is more in the spirit of noexcept intentions to
>>> indicate a no-fail guarantee rather than the no-throw guarantee.
>>
>> On this I think you're just plain wrong. noexcept has a very specific
>> meaning on an API for the *users* of that API: calling this API will not
>> invert control flow. Not EVER. And you can write code calling it
>> assuming that in the strongest sense possible. It does NOT mean that the
>> function cannot fail.
>>
>> The reason why is the heritage from C. Any C function does not throw
>> exceptions, yet they definitely can fail. I would say most C++
>> programmers would agree therefore that marking a function with noexcept
>> means "no exceptions", not "no failures".
>>
>>
>> So, tl;dr and all that, I agree with your opinion if I'm wearing my
>> library developer's hat. I disagree with you if I'm wearing my library
>> user's hat. Hopefully all that above actually made some sense.
>>
> 
> I am confused about the usage of term "inversion of control" in the context
> of throwing exceptions. Maybe I am missing something obvious; but what do
> you mean when you say that "calling noexcept never causes an unexpected
> inversion of control"?

"control flow" not control.

So, for example, if I call a noexcept function, I am *guaranteed* that
the statement after the function call will be executed [1] (or the
program is no longer running). That means I can dispense with using RAII
to trap control flow inversion etc. That means fewer execution paths to
check for validity and to rationalise during maintenance and peer review.

Niall

[1]: Actually there is a subtle trap in noexcept functions which return
types without noexcept move constructors because while the function may
not invert control flow, the _statement_ may invert control flow. And
programmers tend to think in terms of statements, not the branch points
which make up each statement. Again, only if the damn ISO standard
required compilers to refuse to compile functions which could throw
exceptions inside a noexcept execution context ...

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/