------=_Part_24287_127828840.1525724258513
Content-Type: multipart/alternative;
 boundary="----=_Part_24288_2018881137.1525724258514"

------=_Part_24288_2018881137.1525724258514
Content-Type: text/plain; charset="UTF-8"

A nearly unique property of the C++ language are the destructors.

Handling failures is hard, but when executing a destructor it is twice as
hard since we should not fail.
How are we supposed to handle a failure when we might already failed at
something?

Another thing that I like a lot are the exception guarantees of the
standard library.
(No-throw guarantee, Strong exception safety, Basic exception safety and No
exception safety)

Implementing a strong exception-safe routine (or even no-throw) is (almost)
easy if we have some `noexcept` functions at disposal.

The underlying problem is assuring that all functions (event those called
implicitly) are `noexcept` all the time.

If one of the called function changes, it might break silently our code.

Suppose that we have something like

````
void foo(const G& g) noexcept{
    bar(g);
    g.baz();
}
`````

and we want to be sure that it will remain `noexcept` (`bar`, `baz`, and
`G`could change in the future)

We need to write something like

````
void foo(const G& g) noexcept(strong){// compiles only if all called
operations are noexcept(true)
    static_assert(std::is_nothrow_copy_constructible<G>::value, "ERROR");
// Because bar might not take a const reference but a copy(!)
    static_assert(noexcept(bar(), "ERROR");;
    bar(g);
    static_assert(noexcept(std::declval<G>().baz(), "ERROR");
    g.baz();
}
````

Which is barely readable, and error prone, since it easy to forget to
`static_assert` some operation. (implicit conversion, copy constructors
when calling other functions, ... I did not find a
`std::is_nothrow_destructible` in case `bar` make a copy...)


I would like to propose a syntax like:

````
void foo(const G& g) noexcept(strong){ // compiles only if and only if all
called operations are noexcept(true), it should also take copy elision into
account in case `foo` returns something
    bar(g);
    g.baz();
}
````

and of course `noexcept(strong)` should imply `noexcept(true)` (`strong` is
just a placeholder, it could be another keyword/identifier, an enum value,
....)



Since destructors should not throw, I see more and more people writing code
like this (just to be on he safe side)

````
~myclass(){
    try{
        foo();
    }catch(...){}
}
````

which clutters the code, since this code does not tell me if foo can really
fail (and in most cases, `foo` did only free memory, or call other
functions that did not throw).

It would be much better to be able to write

````
~myclass() noexcept(strong){
    foo();
}
````

And be sure that it will not throw, and that there are no errors to ignore.

I hope that something like `noexcept(strong)` could help to avoid those
constructs, and making writing exception-safe code easier.
It seems to me like a great addition to the language, similar to
const-correctness.


Since it would not be possible to implement it as a library change, I
wanted to gather some ideas, get some feedback, before even trying to write
a paper.


Are there any obvious downsides/issues that I missed?
Was something similar already proposed in the past and maybe rejected?



Thank you in advance for your feedback

Federico

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/00a080eb-03df-4922-b6c8-c80c069d454d%40isocpp.org.

------=_Part_24288_2018881137.1525724258514
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A nearly unique property of the C++ language are the destr=
uctors.<br><br>Handling failures is hard, but when executing a destructor i=
t is twice as hard since we should not fail.<br>How are we supposed to hand=
le a failure when we might already failed at something?<br><br>Another thin=
g that I like a lot are the exception guarantees of the standard library.<b=
r>(No-throw guarantee, Strong exception safety, Basic exception safety and =
No exception safety)<br><br>Implementing a strong exception-safe routine (o=
r even no-throw) is (almost) easy if we have some `noexcept` functions at d=
isposal.<br><br>The underlying problem is assuring that all functions (even=
t those called implicitly) are `noexcept` all the time.<br><br>If one of th=
e called function changes, it might break silently our code.<br><br>Suppose=
 that we have something like<br><br>````<br>void foo(const G&amp; g) noexce=
pt{<br>=C2=A0 =C2=A0 bar(g);<br>=C2=A0 =C2=A0 g.baz();<br>}<br>`````<br><br=
>and we want to be sure that it will remain `noexcept` (`bar`, `baz`, and `=
G`could change in the future)<br><br>We need to write something like<br><br=
>````<br>void foo(const G&amp; g) noexcept(strong){// compiles only if all =
called operations are noexcept(true)<br>=C2=A0=C2=A0=C2=A0 static_assert(st=
d::is_nothrow_copy_constructible&lt;G&gt;::value, &quot;ERROR&quot;); // Be=
cause bar might not take a const reference but a copy(!)<br>=C2=A0=C2=A0=C2=
=A0 static_assert(noexcept(bar(), &quot;ERROR&quot;);;<br>=C2=A0=C2=A0=C2=
=A0 bar(g);<br>=C2=A0=C2=A0=C2=A0 static_assert(noexcept(std::declval&lt;G&=
gt;().baz(), &quot;ERROR&quot;);<br>=C2=A0=C2=A0=C2=A0 g.baz();<br>}<br>```=
`<br><br>Which is barely readable, and error prone, since it easy to forget=
 to `static_assert` some operation. (implicit conversion, copy constructors=
 when calling other functions, ... I did not find a `std::is_nothrow_destru=
ctible` in case `bar` make a copy...)<br><br><br>I would like to propose a =
syntax like:<br><br>````<br>void foo(const G&amp; g) noexcept(strong){ // c=
ompiles only if and only if all called operations are noexcept(true), it sh=
ould also take copy elision into account in case `foo` returns something<br=
>=C2=A0=C2=A0=C2=A0 bar(g);<br>=C2=A0=C2=A0=C2=A0 g.baz();<br>}<br>````<br>=
<br>and of course `noexcept(strong)` should imply `noexcept(true)` (`strong=
` is just a placeholder, it could be another keyword/identifier, an enum va=
lue, ...)<br><br><br><br>Since destructors should not throw, I see more and=
 more people writing code like this (just to be on he safe side)<br><br>```=
`<br>~myclass(){<br>=C2=A0=C2=A0=C2=A0 try{<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=
=A0=C2=A0 foo();<br>=C2=A0=C2=A0=C2=A0 }catch(...){}<br>}<br>````<br><br>wh=
ich clutters the code, since this code does not tell me if foo can really f=
ail (and in most cases, `foo` did only free memory, or call other functions=
 that did not throw).<br><br>It would be much better to be able to write<br=
><br>````<br>~myclass() noexcept(strong){<br>=C2=A0=C2=A0=C2=A0 foo();<br>}=
<br>````<br><br>And be sure that it will not throw, and that there are no e=
rrors to ignore.<br><br>I hope that something like `noexcept(strong)` could=
 help to avoid those constructs, and making writing exception-safe code eas=
ier.<br>It seems to me like a great addition to the language, similar to co=
nst-correctness.<br><br><br>Since it would not be possible to implement it =
as a library change, I wanted to gather some ideas, get some feedback, befo=
re even trying to write a paper.<br><br><br>Are there any obvious downsides=
/issues that I missed?<br>Was something similar already proposed in the pas=
t and maybe rejected?<br><br><br><br>Thank you in advance for your feedback=
<br><br>Federico</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/00a080eb-03df-4922-b6c8-c80c069d454d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00a080eb-03df-4922-b6c8-c80c069d454d=
%40isocpp.org</a>.<br />

------=_Part_24288_2018881137.1525724258514--

------=_Part_24287_127828840.1525724258513--

.

------=_Part_6512_1207693315.1525980355440
Content-Type: multipart/alternative;
 boundary="----=_Part_6513_1217802886.1525980355440"

------=_Part_6513_1217802886.1525980355440
Content-Type: text/plain; charset="UTF-8"

I've played a little more with the idea of `noexcept`-correctness, so here
my thoughts.

Suppose that we have following line function:


----
// header file foo.hpp
void foo(const G& g) noexcept;

// source file foo.cpp
void foo(const G& g) noexcept {
    bar(g);
    g.baz();
}
----

I've marked `foo` as `noexcept`, because when I wrote it, `bar` and `baz`
where `noexcept` too, and `bar` took `g` as constant reference.

When code changes happen, some functions that could not fail before, now
can.
Failing, in this context, does not mean that we get in a non-recoverable
state, but simply that we need to handle it.

In it's current form our whole programs could suffer for our `noexcept`
specification, because of a possibly non-critical and recoverable error.

My hope is to provide to the developer a better tool, to detect at compile
time such problems.

If we wrote

----
// header file foo.hpp
void foo(const G& g) noexcept;

// source file foo.cpp
void foo(const G& g) noexcept(strong) {
    bar(g);
    g.baz();
}
----

and the copy-construtor of `g` could throw, or `bar` or `baz` or any other
hidden function call, then the program would be ill-formed, and the
compiler needs to diagnostic an error.

What are the advantages?
Introducing those kind of bugs wouldn't happen silently anymore.

f the code does not compile, we know that we need to inspect the `foo`
function, because we probably cannot guarantee anymore if `foo` is
`noexcept`.
Maybe it is not unreasonable to make a `bar() noexcept` function that
mimics `bar noexcept(false)`. Maybe we do not need all the work done by
`bar noexcept (false)`.

What if the function is not marked as `noexcept`, but it never throws an
exception?
We have a few options:

    - Change the function signature and add the `noexcept` specifier,
similar to what we would to with `const`;
    - Mark our function as `noexcept` or `noexcept(true)`, and not
`noexcept(strong)`, and acknowledge with a comment why we are marking it as
such (maybe the error will never happen at run time, but we can't prove it
at compile time);
    - If it makes sense, we could split `foo` in order to use
`noexcept(strong)` on a subset of operations.


Notice that similar to parameter names or the `const` specifier, when
passing parameters by value, the `noexcept(strong)` specifier should be an
implementation detail.

To the caller it makes no difference if the function is `noexcept` or
`noexcept(strong)`.
In both cases the function is not going to throw an exception.

The important difference is for the implementer of the function.


This also means (I've done some digging into the standard) that:
The paragraph "5.3.7 noexcept operator" can remain unchanged, the
`noexcept` operator still evaluates to `bool`.

The paragraph "15.4 Exception specifications" states that `noexcept` takes
something that is convertible to `bool`.
Therefore `strong` should be convertible to `true`.
And this part

"An implementation shall not reject an expression merely because when
executed it throws or might throw
an exception that the containing function does not allow"

is the core part I would like to update with `noexcept(strong)`.
Maybe something like

"An implementation shall not reject an expression merely because when
executed it throws or might throw
an exception that the containing function does not allow, unless it is
marked as noexcept(strong)"

could suffice.
An maybe extend the examples to something like:

----
extern void f() throw(X, Y);
void g() throw(X) {
    f();                    // OK
}

extern void f() throw(X, Y);
void g() noexcept {
    f();                    // OK
}

extern void f() throw(X, Y);
void g() noexcept(strong) {
    f();                    // ill-formed
}
----

Now, after digging into he standard and thinking about possible use-cases,
I finally saw the biggest issue with such a proposal: generic code and
therefore function templates.

Let us consider the `std::transform` algorithm.
It is not marked as `noexcept`, because in many cases, it will not be.
It depends on it's input parameters, consider

----
foo() noexcept(strong) {
    int arr[] = {1,2,3,4,5};
    std::transform(begin(arr), end(arr), begin(arr), [](int
i)noexcept{return i+1;});
}
----

I would like this program to compile. `begin` and `end` are already
`noexcept`, and I've marked the lambda as such.
I would expect that on all implementation, this algorithm will not allocate
memory or do other operations that might cause an exception. It might make
sense to expect it to be conditionally `noexcept`.


Of course something like

----
foo() noexcept(strong) {
    int arr[] = {1,2,3,4,5};
    for(auto a& : arr){
        a++;
    }
}
----

would compile just fine, but it would be a huge step back for reusability.
I think it should be possible to write `std::transform` in a way to be
conditionally `noexcept`, just like `std::pair`.
If possible, such an implementation would have similar problems to those
that `noexcept(strong)` would like to solve.
It would be nice having something like `noexcept(auto)`, like proposed in
n4773 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4473), but
as far as I know no one is working on it.
I also saw that Stroustrup (www.stroustrup.com/N3202-noexcept.pdf) wrote
something about `noexcept`-deduction.

Unfortunately, I could not find any recent papers or proposals.
I think that `noexcept`-correctness and `noexcept`-deduction in templates
are two important topics in order to write robust code.
It would ease a lot writing exception-safe code, which is a tremendously
important property.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90a50cd6-7ad4-4444-89f4-51f75822e358%40isocpp.org.

------=_Part_6513_1217802886.1525980355440
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ve played a little more with the idea of `noexcept`-=
correctness, so here my thoughts.<br><br>Suppose that we have following lin=
e function:<br><br><br>----<br>// header file foo.hpp<br>void foo(const G&a=
mp; g) noexcept;<br><br>// source file foo.cpp<br>void foo(const G&amp; g) =
noexcept {<br>=C2=A0=C2=A0=C2=A0 bar(g);<br>=C2=A0=C2=A0=C2=A0 g.baz();<br>=
}<br>----<br><br>I&#39;ve marked `foo` as `noexcept`, because when I wrote =
it, `bar` and `baz` where `noexcept` too, and `bar` took `g` as constant re=
ference.<br><br>When code changes happen, some functions that could not fai=
l before, now can.<br>Failing, in this context, does not mean that we get i=
n a non-recoverable state, but simply that we need to handle it.<br><br>In =
it&#39;s current form our whole programs could suffer for our `noexcept` sp=
ecification, because of a possibly non-critical and recoverable error.<br><=
br>My hope is to provide to the developer a better tool, to detect at compi=
le time such problems.<br><br>If we wrote<br><br>----<br>// header file foo=
..hpp<br>void foo(const G&amp; g) noexcept;<br><br>// source file foo.cpp<br=
>void foo(const G&amp; g) noexcept(strong) {<br>=C2=A0=C2=A0=C2=A0 bar(g);<=
br>=C2=A0=C2=A0=C2=A0 g.baz();<br>}<br>----<br><br>and the copy-construtor =
of `g` could throw, or `bar` or `baz` or any other hidden function call, th=
en the program would be ill-formed, and the compiler needs to diagnostic an=
 error.<br><br>What are the advantages?<br>Introducing those kind of bugs w=
ouldn&#39;t happen silently anymore.<br><br>f the code does not compile, we=
 know that we need to inspect the `foo` function, because we probably canno=
t guarantee anymore if `foo` is `noexcept`.<br>Maybe it is not unreasonable=
 to make a `bar() noexcept` function that mimics `bar noexcept(false)`. May=
be we do not need all the work done by `bar noexcept (false)`.<br><br>What =
if the function is not marked as `noexcept`, but it never throws an excepti=
on?<br>We have a few options:<br><br>=C2=A0=C2=A0=C2=A0 - Change the functi=
on signature and add the `noexcept` specifier, similar to what we would to =
with `const`;<br>=C2=A0=C2=A0=C2=A0 - Mark our function as `noexcept` or `n=
oexcept(true)`, and not `noexcept(strong)`, and acknowledge with a comment =
why we are marking it as such (maybe the error will never happen at run tim=
e, but we can&#39;t prove it at compile time);<br>=C2=A0=C2=A0=C2=A0 - If i=
t makes sense, we could split `foo` in order to use `noexcept(strong)` on a=
 subset of operations.<br><br><br>Notice that similar to parameter names or=
 the `const` specifier, when passing parameters by value, the `noexcept(str=
ong)` specifier should be an implementation detail.<br><br>To the caller it=
 makes no difference if the function is `noexcept` or `noexcept(strong)`.<b=
r>In both cases the function is not going to throw an exception.<br><br>The=
 important difference is for the implementer of the function.<br><br><br>Th=
is also means (I&#39;ve done some digging into the standard) that:<br>The p=
aragraph &quot;5.3.7 noexcept operator&quot; can remain unchanged, the `noe=
xcept` operator still evaluates to `bool`.<br><br>The paragraph &quot;15.4 =
Exception specifications&quot; states that `noexcept` takes something that =
is convertible to `bool`.<br>Therefore `strong` should be convertible to `t=
rue`.<br>And this part<br><br>&quot;An implementation shall not reject an e=
xpression merely because when executed it throws or might throw<br>an excep=
tion that the containing function does not allow&quot;<br><br>is the core p=
art I would like to update with `noexcept(strong)`.<br>Maybe something like=
<br><br>&quot;An implementation shall not reject an expression merely becau=
se when executed it throws or might throw<br>an exception that the containi=
ng function does not allow, unless it is marked as noexcept(strong)&quot;<b=
r><br>could suffice.<br>An maybe extend the examples to something like:<br>=
<br>----<br>extern void f() throw(X, Y);<br>void g() throw(X) {<br>=C2=A0=
=C2=A0=C2=A0 f();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // OK<br>}<br><br=
>extern void f() throw(X, Y);<br>void g() noexcept {<br>=C2=A0=C2=A0=C2=A0 =
f();=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // OK<br>}<br><br>extern void=
 f() throw(X, Y);<br>void g() noexcept(strong) {<br>=C2=A0=C2=A0=C2=A0 f();=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ill-formed<br>}<br>----<br><br>N=
ow, after digging into he standard and thinking about possible use-cases, I=
 finally saw the biggest issue with such a proposal: generic code and there=
fore function templates.<br><br>Let us consider the `std::transform` algori=
thm.<br>It is not marked as `noexcept`, because in many cases, it will not =
be.<br>It depends on it&#39;s input parameters, consider<br><br>----<br>foo=
() noexcept(strong) {<br>=C2=A0=C2=A0=C2=A0 int arr[] =3D {1,2,3,4,5};<br>=
=C2=A0=C2=A0=C2=A0 std::transform(begin(arr), end(arr), begin(arr), [](int =
i)noexcept{return i+1;});<br>}<br>----<br><br>I would like this program to =
compile. `begin` and `end` are already `noexcept`, and I&#39;ve marked the =
lambda as such.<br>I would expect that on all implementation, this algorith=
m will not allocate memory or do other operations that might cause an excep=
tion. It might make sense to expect it to be conditionally `noexcept`.<br><=
br><br>Of course something like<br><br>----<br>foo() noexcept(strong) {<br>=
=C2=A0=C2=A0=C2=A0 int arr[] =3D {1,2,3,4,5};<br>=C2=A0=C2=A0=C2=A0 for(aut=
o a&amp; : arr){<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 a++;<br>=C2=A0=C2=
=A0=C2=A0 }<br>}<br>----<br><br>would compile just fine, but it would be a =
huge step back for reusability.<br>I think it should be possible to write `=
std::transform` in a way to be conditionally `noexcept`, just like `std::pa=
ir`.<br>If possible, such an implementation would have similar problems to =
those that `noexcept(strong)` would like to solve.<br>It would be nice havi=
ng something like `noexcept(auto)`, like proposed in n4773 (http://www.open=
-std.org/jtc1/sc22/wg21/docs/papers/2015/n4473), but as far as I know no on=
e is working on it.<br>I also saw that Stroustrup (www.stroustrup.com/N3202=
-noexcept.pdf) wrote something about `noexcept`-deduction.<br><br>Unfortuna=
tely, I could not find any recent papers or proposals.<br>I think that `noe=
xcept`-correctness and `noexcept`-deduction in templates are two important =
topics in order to write robust code.<br>It would ease a lot writing except=
ion-safe code, which is a tremendously important property.<br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90a50cd6-7ad4-4444-89f4-51f75822e358%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90a50cd6-7ad4-4444-89f4-51f75822e358=
%40isocpp.org</a>.<br />

------=_Part_6513_1217802886.1525980355440--

------=_Part_6512_1207693315.1525980355440--

.

------=_Part_11488_331268904.1526064080141
Content-Type: multipart/alternative;
 boundary="----=_Part_11489_2022248986.1526064080142"

------=_Part_11489_2022248986.1526064080142
Content-Type: text/plain; charset="UTF-8"

The basic problem I have with this is that it requires that everybody play
on the same team. Either everyone examines every function for `noexcept`,
or what you're doing doesn't work very well.

Right now, `noexcept` matters primarily for indicating a *local* construct
of your program. A move constructor is `noexcept` because it doesn't do
anything that might throw exceptions. If it happens to call some subsidiary
functions to copy pointers or whatever, those functions don't need to be
explicitly marked `noexcept`.

You put exception specifications on things where you have some reasonable
expectation that someone is going to, at compile-time, do something
different based on that. That's not everywhere; it's not a part of most
functions.

You're trying to promote a world where every function needs to consider
whether it ought to be `noexcept`. And that's just not a reasonable world.
Especially if whether you're `noexcept` or not is conditioned based on the
exception specification of user-provided code.

Is `std::sort` `noexcept`? Well, that would depend on whether the
comparison function is `noexcept`. Do we really want every kind of
algorithm to have to write some complex exception specification?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/35f89aa3-02e6-4306-a120-18cd3ebc5ddf%40isocpp.org.

------=_Part_11489_2022248986.1526064080142
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">The basic problem I have with this is that it requires tha=
t everybody play on the same team. Either everyone examines every function =
for `noexcept`, or what you&#39;re doing doesn&#39;t work very well.<br><br=
>Right now, `noexcept` matters primarily for indicating a <i>local</i> cons=
truct of your program. A move constructor is `noexcept` because it doesn&#3=
9;t do anything that might throw exceptions. If it happens to call some sub=
sidiary functions to copy pointers or whatever, those functions don&#39;t n=
eed to be explicitly marked `noexcept`.<br><br>You put exception specificat=
ions on things where you have some reasonable expectation that someone is g=
oing to, at compile-time, do something different based on that. That&#39;s =
not everywhere; it&#39;s not a part of most functions.<br><br>You&#39;re tr=
ying to promote a world where every function needs to consider whether it o=
ught to be `noexcept`. And that&#39;s just not a reasonable world. Especial=
ly if whether you&#39;re `noexcept` or not is conditioned based on the exce=
ption specification of user-provided code.<br><br>Is `std::sort` `noexcept`=
? Well, that would depend on whether the comparison function is `noexcept`.=
 Do we really want every kind of algorithm to have to write some complex ex=
ception specification?<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/35f89aa3-02e6-4306-a120-18cd3ebc5ddf%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/35f89aa3-02e6-4306-a120-18cd3ebc5ddf=
%40isocpp.org</a>.<br />

------=_Part_11489_2022248986.1526064080142--

------=_Part_11488_331268904.1526064080141--

.

------=_Part_12028_1344690904.1526072849245
Content-Type: multipart/alternative;
 boundary="----=_Part_12029_307778784.1526072849246"

------=_Part_12029_307778784.1526072849246
Content-Type: text/plain; charset="UTF-8"

Hi Nicol, thank you for your time and feedback

On Friday, May 11, 2018 at 8:41:20 PM UTC+2, Nicol Bolas wrote:
>
> The basic problem I have with this is that it requires that everybody play
> on the same team. Either everyone examines every function for `noexcept`,
> or what you're doing doesn't work very well.
>

Yes, this is true.
But look at pair, optional, tuple, variant, array...
They are all conditionally `noexcept`.
So we already have the situation that for some constructs we need to pay
attention if our code is (conditionally) `noexcept`.
And the compiler won't tell us if we did something wrong!

With `constexpr` and `const` it's different, since calling a non-constexpr
function at compile time yields an error, and mutating a const variable is
a compile error too.
You could argue with `constexpr` the same way about `noexcept` (or
`const`). We all need to play on the same team.
And look at <algorithm>. For c++20 different algorithms like find
(https://en.cppreference.com/w/cpp/algorithm/find) are marked as constexpr.



> Right now, `noexcept` matters primarily for indicating a *local*
> construct of your program. A move constructor is `noexcept` because it
> doesn't do anything that might throw exceptions. If it happens to call some
> subsidiary functions to copy pointers or whatever, those functions don't
> need to be explicitly marked `noexcept`.
>

No, those function called in a move constructor do not need to be marked as
such, but it would be great if they were, just to avoid hidden bugs. And
remember that noexcept is already part of the function signature(!).

And like you said, it is a local construct.
Why should the whole program suffer a non-recoverable error that could get
detected at compile time, if locally we mess something up?
It's not like corrupting memory, which invalidates the state of the
program. (Notice: I'm not saying that terminating when throwing inside
noexcept is bad!)


> You put exception specifications on things where you have some reasonable
> expectation that someone is going to, at compile-time, do something
> different based on that. That's not everywhere; it's not a part of most
> functions.
>

Yes, and that's why I believe the problem you are describing are not so
dramatic.
Most function will continue to be `noexcept(false)` as they are today, and
as most functions are not constexpr.
For some functions, `noexcept` is really relevant, like destructor, moving
operations and so on.
And those functions, normally, do not call a lot of code.
So we do not need to revisit immediately our code-basis and apply
`noexcept` to every function that does not throw by accident. We do not
need it.
Highly generic and reusable functions (like algorithms, pair, tuple, ...),
would greatly benefit from something like `noexcept(auto)`, since by they
nature they have a greater probability to get called in a context where
being `noexcept` is relevant.


> You're trying to promote a world where every function needs to consider
> whether it ought to be `noexcept`. And that's just not a reasonable world.
> Especially if whether you're `noexcept` or not is conditioned based on the
> exception specification of user-provided code.
>

We already live in a world where we need to think if a function might throw
or not, and at least for three reasons:
 - write exception-safe code
 - consider execution paths/code flows when reading the program
 - documentation (we do not always have the source code available, so we
need to document if functions are going to throw something, like all
function of std are already documented)
I'm proposing to let the compiler use that information.
I'm also not proposing to deprecate `noexcept(true)` in favor of
`noexcept(strong)`.
So we can still use `noexcept(false)` functions whenever we want.

Is `std::sort` `noexcept`? Well, that would depend on whether the
> comparison function is `noexcept`. Do we really want every kind of
> algorithm to have to write some complex exception specification?
>

It also depends on the iterators, move constructor, if the comparison
functions takes by copy or reference, if there are hidden conversions...
and maybe something else that I've forgot.
That's why it is important to let the compiler check if everything is
`noexcept` or not (like described in n4773), if we need a `noexcept` or
conditionally `noexcept` function.

I believe, it would make little sense to standardize something like
`noexcept(strong)` without something like `noexcept(auto)`, because the two
specification serve different purposes, but they would work together very
well.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d0400a21-7fbe-4fec-9b40-74fc80e170d6%40isocpp.org.

------=_Part_12029_307778784.1526072849246
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Nicol, thank you for your time and feedback<br><br>On F=
riday, May 11, 2018 at 8:41:20 PM UTC+2, Nicol Bolas wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr">The basic problem I have with=
 this is that it requires that everybody play on the same team. Either ever=
yone examines every function for `noexcept`, or what you&#39;re doing doesn=
&#39;t work very well.<br></div></blockquote><div><br>Yes, this is true.<br=
>But look at pair, optional, tuple, variant, array...<br>They are all condi=
tionally `noexcept`.<br>So we already have the situation that for some cons=
tructs we need to pay attention if our code is (conditionally) `noexcept`.<=
br>And the compiler won&#39;t tell us if we did something wrong!<br><br>Wit=
h `constexpr` and `const` it&#39;s different, since calling a non-constexpr=
 function at compile time yields an error, and mutating a const variable is=
 a compile error too.<br>You could argue with `constexpr` the same way abou=
t `noexcept` (or `const`). We all need to play on the same team.<br>And loo=
k at &lt;algorithm&gt;. For c++20 different algorithms like find (https://e=
n.cppreference.com/w/cpp/algorithm/find) are marked as constexpr.<br><br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">R=
ight now, `noexcept` matters primarily for indicating a <i>local</i> constr=
uct of your program. A move constructor is `noexcept` because it doesn&#39;=
t do anything that might throw exceptions. If it happens to call some subsi=
diary functions to copy pointers or whatever, those functions don&#39;t nee=
d to be explicitly marked `noexcept`.<br></div></blockquote><div><br>No, th=
ose function called in a move constructor do not need to be marked as such,=
 but it would be great if they were, just to avoid hidden bugs. And remembe=
r that noexcept is already part of the function signature(!).<br><br>And li=
ke you said, it is a local construct.<br>Why should the whole program suffe=
r a non-recoverable error that could get detected at compile time, if local=
ly we mess something up?<br>It&#39;s not like corrupting memory, which inva=
lidates the state of the program. (Notice: I&#39;m not saying that terminat=
ing when throwing inside noexcept is bad!)<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">You put exception specificatio=
ns on things where you have some reasonable expectation that someone is goi=
ng to, at compile-time, do something different based on that. That&#39;s no=
t everywhere; it&#39;s not a part of most functions.<br></div></blockquote>=
<div><br>Yes, and that&#39;s why I believe the problem you are describing a=
re not so dramatic.<br>Most function will continue to be `noexcept(false)` =
as they are today, and as most functions are not constexpr.<br>For some fun=
ctions, `noexcept` is really relevant, like destructor, moving operations a=
nd so on.<br>And those functions, normally, do not call a lot of code.<br>S=
o we do not need to revisit immediately our code-basis and apply `noexcept`=
 to every function that does not throw by accident. We do not need it.<br>H=
ighly generic and reusable functions (like algorithms, pair, tuple, ...), w=
ould greatly benefit from something like `noexcept(auto)`, since by they na=
ture they have a greater probability to get called in a context where being=
 `noexcept` is relevant.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div dir=3D"ltr">You&#39;re trying to promote a world where every=
 function needs to consider whether it ought to be `noexcept`. And that&#39=
;s just not a reasonable world. Especially if whether you&#39;re `noexcept`=
 or not is conditioned based on the exception specification of user-provide=
d code.<br></div></blockquote><div><br>We already live in a world where we =
need to think if a function might throw or not, and at least for three reas=
ons:<br>=C2=A0- write exception-safe code<br>=C2=A0- consider execution pat=
hs/code flows when reading the program<br>=C2=A0- documentation (we do not =
always have the source code available, so we need to document if functions =
are going to throw something, like all function of std are already document=
ed)<br>I&#39;m proposing to let the compiler use that information.<br>I&#39=
;m also not proposing to deprecate `noexcept(true)` in favor of `noexcept(s=
trong)`.<br>So we can still use `noexcept(false)` functions whenever we wan=
t. <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">Is `std::sort` `noexcept`? Well, that would depend on whether the compa=
rison function is `noexcept`. Do we really want every kind of algorithm to =
have to write some complex exception specification?<br></div></blockquote><=
div><br>It also depends on the iterators, move constructor, if the comparis=
on functions takes by copy or reference, if there are hidden conversions...=
 and maybe something else that I&#39;ve forgot.<br>That&#39;s why it is imp=
ortant to let the compiler check if everything is `noexcept` or not (like d=
escribed in n4773), if we need a `noexcept` or conditionally `noexcept` fun=
ction.<br><br>I believe, it would make little sense to standardize somethin=
g like `noexcept(strong)` without something like `noexcept(auto)`, because =
the two specification serve different purposes, but they would work togethe=
r very well.<br></div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d0400a21-7fbe-4fec-9b40-74fc80e170d6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0400a21-7fbe-4fec-9b40-74fc80e170d6=
%40isocpp.org</a>.<br />

------=_Part_12029_307778784.1526072849246--

------=_Part_12028_1344690904.1526072849245--

.

------=_Part_12441_464423062.1526082271103
Content-Type: multipart/alternative;
 boundary="----=_Part_12442_550995618.1526082271103"

------=_Part_12442_550995618.1526082271103
Content-Type: text/plain; charset="UTF-8"

On Friday, May 11, 2018 at 5:07:29 PM UTC-4, federico...@gmail.com wrote:
>
> I believe, it would make little sense to standardize something like
> `noexcept(strong)` without something like `noexcept(auto)`, because the two
> specification serve different purposes, but they would work together very
> well.
>

That's effectively agreeing with me that `noexcept(strong)` will result in
more people writing `noexcept` specifications where they would not
otherwise need to.

`noexcept` isn't *supposed* to be like `constexpr`. `constexpr` cannot call
non-`constexpr` functions because only `constexpr` functions can execute at
compile-time (in theory). The C++ constant expression model simply doesn't
allow for anything else.

`noexcept` is not meant to work that way. A `noexcept` function calling a
non-`noexcept` function is perfectly valid code. This is precisely *why* we
don't need `noexcept(auto)`: because if I need to call `std::copy`, and I
know that all of the operations it will use don't throw (for the provided
types), I don't need `std::copy` to tell me it doesn't throw.

The lack of a `noexcept` specification does not mean "throws exceptions",
and we should not assume that it does.

`noexcept(strong)` divides C++ functions into two groups: those that have
noexcept specifications and those that don't. That's why you need
`noexcept(auto)`; so that users can more easily sort themselves into a
group.

The last thing the C++ language needs is to divide functions into yet
another grouping.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c61c55dd-d4e9-4db1-b527-0918e0b734dd%40isocpp.org.

------=_Part_12442_550995618.1526082271103
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 11, 2018 at 5:07:29 PM UTC-4, federico...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>I believe,=
 it would make little sense to standardize something like `noexcept(strong)=
` without something like `noexcept(auto)`, because the two specification se=
rve different purposes, but they would work together very well.<br></div></=
blockquote><div><br>That&#39;s effectively agreeing with me that `noexcept(=
strong)` will result in more people writing `noexcept` specifications where=
 they would not otherwise need to.<br><br>`noexcept` isn&#39;t <i>supposed<=
/i> to be like `constexpr`. `constexpr` cannot call non-`constexpr` functio=
ns because only `constexpr` functions can execute at compile-time (in theor=
y). The C++ constant expression model simply doesn&#39;t allow for anything=
 else.<br><br>`noexcept` is not meant to work that way. A `noexcept` functi=
on calling a non-`noexcept` function is perfectly valid code. This is preci=
sely <i>why</i> we don&#39;t need `noexcept(auto)`: because if I need to ca=
ll `std::copy`, and I know that all of the operations it will use don&#39;t=
 throw (for the provided types), I don&#39;t need `std::copy` to tell me it=
 doesn&#39;t throw.<br><br>The lack of a `noexcept` specification does not =
mean &quot;throws exceptions&quot;, and we should not assume that it does.<=
br><br>`noexcept(strong)` divides C++ functions into two groups: those that=
 have noexcept specifications and those that don&#39;t. That&#39;s why you =
need `noexcept(auto)`; so that users can more easily sort themselves into a=
 group.<br><br>The last thing the C++ language needs is to divide functions=
 into yet another grouping.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c61c55dd-d4e9-4db1-b527-0918e0b734dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c61c55dd-d4e9-4db1-b527-0918e0b734dd=
%40isocpp.org</a>.<br />

------=_Part_12442_550995618.1526082271103--

------=_Part_12441_464423062.1526082271103--

.

------=_Part_12970_480771748.1526082862498
Content-Type: multipart/alternative;
 boundary="----=_Part_12971_1309046307.1526082862498"

------=_Part_12971_1309046307.1526082862498
Content-Type: text/plain; charset="UTF-8"

On Friday, May 11, 2018 at 5:07:29 PM UTC-4, federico...@gmail.com wrote:
>
> On Friday, May 11, 2018 at 8:41:20 PM UTC+2, Nicol Bolas wrote:
>>
>> The basic problem I have with this is that it requires that everybody
>> play on the same team. Either everyone examines every function for
>> `noexcept`, or what you're doing doesn't work very well.
>>
>
> Yes, this is true.
> But look at pair, optional, tuple, variant, array...
> They are all conditionally `noexcept`.
>

Sorry; I missed this point in my previous reply.

Types are not "conditionally `noexcept`". Certain operations of those types
are conditionally `noexcept`.

Those types are wrappers which attempt, where possible, to behave
identically to the wrapped type. That's why the `noexcept` status of some
of their operations are conditional; they're forwarding the `noexcept`
status of the internal type(s).

Such forwarding is necessary only because those operations are ones which
care very much about throwing exceptions: default initialization, copy/move
operations, swapping, etc. There are very specific issues surrounding very
specific operations. The optimizations you can do when you know a copy or
move constructor won't throw are different from if you don't know that.

These issues are why `noexcept` was invented in the first place.

Algorithms, for example, make no effort to forward `noexcept`. Because
they're not expected to do so. Even `std::copy` doesn't forward exception
behavior; external code is not going to optimize based on whether
`std::copy` throws or not.

This is very different from the use you are trying to make of `noexcept`.
You're trying to turn syntax that was intended to solve a special case
problem into something that is intended to solve a very different problem.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cc28edb9-1aa9-46c5-b4a3-c81d5c4b34dd%40isocpp.org.

------=_Part_12971_1309046307.1526082862498
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Friday, May 11, 2018 at 5:07:29 PM UTC-4, federico...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
">On Friday, May 11, 2018 at 8:41:20 PM UTC+2, Nicol Bolas wrote:<blockquot=
e class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">The basic problem I have wit=
h this is that it requires that everybody play on the same team. Either eve=
ryone examines every function for `noexcept`, or what you&#39;re doing does=
n&#39;t work very well.<br></div></blockquote><div><br>Yes, this is true.<b=
r>But look at pair, optional, tuple, variant, array...<br>They are all cond=
itionally `noexcept`.<br></div></div></blockquote><div><br>Sorry; I missed =
this point in my previous reply.<br><br>Types are not &quot;conditionally `=
noexcept`&quot;. Certain operations of those types are conditionally `noexc=
ept`.<br><br>Those types are wrappers which attempt, where possible, to beh=
ave identically to the wrapped type. That&#39;s why the `noexcept` status o=
f some of their operations are conditional; they&#39;re forwarding the `noe=
xcept` status of the internal type(s).<br><br>Such forwarding is necessary =
only because those operations are ones which care very much about throwing =
exceptions: default initialization, copy/move operations, swapping, etc. Th=
ere are very specific issues surrounding very specific operations. The opti=
mizations you can do when you know a copy or move constructor won&#39;t thr=
ow are different from if you don&#39;t know that.<br><br>These issues are w=
hy `noexcept` was invented in the first place.<br><br>Algorithms, for examp=
le, make no effort to forward `noexcept`. Because they&#39;re not expected =
to do so. Even `std::copy` doesn&#39;t forward exception behavior; external=
 code is not going to optimize based on whether `std::copy` throws or not.<=
br><br>This is very different from the use you are trying to make of `noexc=
ept`. You&#39;re trying to turn syntax that was intended to solve a special=
 case problem into something that is intended to solve a very different pro=
blem.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cc28edb9-1aa9-46c5-b4a3-c81d5c4b34dd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc28edb9-1aa9-46c5-b4a3-c81d5c4b34dd=
%40isocpp.org</a>.<br />

------=_Part_12971_1309046307.1526082862498--

------=_Part_12970_480771748.1526082862498--

.

Le 07/05/2018 =C3=A0 22:17, federico.kircheis@gmail.com a =C3=A9crit=C2=A0:
> A nearly unique property of the C++ language are the destructors.
>
> Handling failures is hard, but when executing a destructor it is twice=20
> as hard since we should not fail.
> How are we supposed to handle a failure when we might already failed=20
> at something?
>
> Another thing that I like a lot are the exception guarantees of the=20
> standard library.
> (No-throw guarantee, Strong exception safety, Basic exception safety=20
> and No exception safety)
>
> Implementing a strong exception-safe routine (or even no-throw) is=20
> (almost) easy if we have some `noexcept` functions at disposal.
>
> The underlying problem is assuring that all functions (event those=20
> called implicitly) are `noexcept` all the time.
>
> If one of the called function changes, it might break silently our code.
>
> Suppose that we have something like
>
> ````
> void foo(const G& g) noexcept{
> =C2=A0 =C2=A0 bar(g);
> =C2=A0 =C2=A0 g.baz();
> }
> `````
>
> and we want to be sure that it will remain `noexcept` (`bar`, `baz`,=20
> and `G`could change in the future)
>
> We need to write something like
>
> ````
> void foo(const G& g) noexcept(strong){// compiles only if all called=20
> operations are noexcept(true)
> static_assert(std::is_nothrow_copy_constructible<G>::value, "ERROR");=20
> // Because bar might not take a const reference but a copy(!)
> =C2=A0=C2=A0=C2=A0 static_assert(noexcept(bar(), "ERROR");;
> =C2=A0=C2=A0=C2=A0 bar(g);
> =C2=A0=C2=A0=C2=A0 static_assert(noexcept(std::declval<G>().baz(), "ERROR=
");
> =C2=A0=C2=A0=C2=A0 g.baz();
> }
> ````
>
> Which is barely readable, and error prone, since it easy to forget to=20
> `static_assert` some operation. (implicit conversion, copy=20
> constructors when calling other functions, ... I did not find a=20
> `std::is_nothrow_destructible` in case `bar` make a copy...)
>
>
> I would like to propose a syntax like:
>
> ````
> void foo(const G& g) noexcept(strong){ // compiles only if and only if=20
> all called operations are noexcept(true), it should also take copy=20
> elision into account in case `foo` returns something
> =C2=A0=C2=A0=C2=A0 bar(g);
> =C2=A0=C2=A0=C2=A0 g.baz();
> }
> ````
>
> and of course `noexcept(strong)` should imply `noexcept(true)`=20
> (`strong` is just a placeholder, it could be another=20
> keyword/identifier, an enum value, ...)
>
>
>
> Since destructors should not throw, I see more and more people writing=20
> code like this (just to be on he safe side)
>
> ````
> ~myclass(){
> =C2=A0=C2=A0=C2=A0 try{
> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 foo();
> =C2=A0=C2=A0=C2=A0 }catch(...){}
> }
> ````
>
> which clutters the code, since this code does not tell me if foo can=20
> really fail (and in most cases, `foo` did only free memory, or call=20
> other functions that did not throw).
>
> It would be much better to be able to write
>
> ````
> ~myclass() noexcept(strong){
> =C2=A0=C2=A0=C2=A0 foo();
> }
> ````
>
> And be sure that it will not throw, and that there are no errors to=20
> ignore.
>
> I hope that something like `noexcept(strong)` could help to avoid=20
> those constructs, and making writing exception-safe code easier.
> It seems to me like a great addition to the language, similar to=20
> const-correctness.
>
>
> Since it would not be possible to implement it as a library change, I=20
> wanted to gather some ideas, get some feedback, before even trying to=20
> write a paper.
>
>
> Are there any obvious downsides/issues that I missed?
> Was something similar already proposed in the past and maybe rejected?
>
>
Hi,

I believe the problem is orthogonal whether the function is conditional=20
noexcept is really no except as I would like to the following program to=20
be ill formed as well when g.baz() becomes no noexcept after some changes.


````
void foo(const G& g) noexcept(noexcept(bar(g))) {
 =C2=A0 =C2=A0 bar(g);
 =C2=A0 =C2=A0 g.baz();
}
`````


So maybe we need an additional annotation __STRICT__,

````
void foo(const G& g) __STRICT__ noexcept(noexcept(bar(g))) {
 =C2=A0 =C2=A0 bar(g);
 =C2=A0 =C2=A0 g.baz();
}
`````

or that noexpect accepts an additional label __STRICT__

````
void foo(const G& g) noexcept( __STRICT__, noexcept(bar(g))) {
 =C2=A0 =C2=A0 bar(g);
 =C2=A0 =C2=A0 g.baz();
}
`````


Have you considered the possibility to have an attribute and the=20
possibility that this could be a QOI and that the compiler could warn in=20
those situations?

````
void foo(const G& g) [[strict]] noexcept(noexcept(bar(g))) {
 =C2=A0 =C2=A0 bar(g);
 =C2=A0 =C2=A0 g.baz();
}
`````

This could be useful to experiment with the idea before making code that=20
is valid today ill formed.


Vicente

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7302ce03-3ae9-1721-e524-0bfa5f5084f5%40wanadoo.f=
r.

.

--000000000000e4690c056bfe71d8
Content-Type: text/plain; charset="UTF-8"

On Friday, May 11, 2018, Nicol Bolas <jmckesson@gmail.com> wrote:

> The basic problem I have with this is that it requires that everybody play
> on the same team. Either everyone examines every function for `noexcept`,
> or what you're doing doesn't work very well.
>

What team? Back when Symbian OS was a thing they used scan code for
uncaught exceptions by examining the naming conventions of functions in a
call chain. Clearly not 100% accurate, so if the compiler can point out a
potential exception leak then it should. It would also help catch any
accidental behavioural breaks. The Software Engineering team would
appreciate something like this.

>
>
> Right now, `noexcept` matters primarily for indicating a *local*
> construct of your program. A move constructor is `noexcept` because it
> doesn't do anything that might throw exceptions. If it happens to call some
> subsidiary functions to copy pointers or whatever, those functions don't
> need to be explicitly marked `noexcept`.
>
> You put exception specifications on things where you have some reasonable
> expectation that someone is going to, at compile-time, do something
> different based on that. That's not everywhere; it's not a part of most
> functions.
>
> You're trying to promote a world where every function needs to consider
> whether it ought to be `noexcept`. And that's just not a reasonable world.
> Especially if whether you're `noexcept` or not is conditioned based on the
> exception specification of user-provided code.
>

It's reasonable, and useful, in the Java world. And I'd imagine that it's
required in the embedded/nuclear power plant world too, or maybe it's
easier to reason about a program's behaviour by just turning exceptions off
(Google were right all along)

>
>
> Is `std::sort` `noexcept`? Well, that would depend on whether the
> comparison function is `noexcept`. Do we really want every kind of
> algorithm to have to write some complex exception specification?
>

 Yes, but complex in what way? It's a yes/no answer as to whether a
function throws or not.


> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/35f89aa3-02e6-4306-
> a120-18cd3ebc5ddf%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/35f89aa3-02e6-4306-a120-18cd3ebc5ddf%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAfAVvn-uUzwgnZNpcWTq_Zm--G1G5jS1B_Br%3D-bfE7GQ%40mail.gmail.com.

--000000000000e4690c056bfe71d8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<br><br>On Friday, May 11, 2018, Nicol Bolas &lt;<a href=3D"mailto:jmckesso=
n@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">The basic problem I have with this is that it requi=
res that everybody play on the same team. Either everyone examines every fu=
nction for `noexcept`, or what you&#39;re doing doesn&#39;t work very well.=
</div></blockquote><div><br></div><div>What team? Back when Symbian OS was =
a thing they used scan code for uncaught exceptions by examining the naming=
 conventions of functions in a call chain. Clearly not 100% accurate, so if=
 the compiler can point out a potential exception leak then it should. It w=
ould also help catch any accidental behavioural breaks. The Software Engine=
ering team would appreciate something like this.</div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><br><br>Right now, `noexcept` matters primarily =
for indicating a <i>local</i> construct of your program. A move constructor=
 is `noexcept` because it doesn&#39;t do anything that might throw exceptio=
ns. If it happens to call some subsidiary functions to copy pointers or wha=
tever, those functions don&#39;t need to be explicitly marked `noexcept`.<b=
r><br>You put exception specifications on things where you have some reason=
able expectation that someone is going to, at compile-time, do something di=
fferent based on that. That&#39;s not everywhere; it&#39;s not a part of mo=
st functions.<br><br>You&#39;re trying to promote a world where every funct=
ion needs to consider whether it ought to be `noexcept`. And that&#39;s jus=
t not a reasonable world. Especially if whether you&#39;re `noexcept` or no=
t is conditioned based on the exception specification of user-provided code=
..</div></blockquote><div><br></div><div>It&#39;s reasonable, and useful, in=
 the Java world. And I&#39;d imagine that it&#39;s required in the embedded=
/nuclear power plant world too, or maybe it&#39;s easier to reason about a =
program&#39;s behaviour by just turning exceptions off (Google were right a=
ll along)</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>Is `=
std::sort` `noexcept`? Well, that would depend on whether the comparison fu=
nction is `noexcept`. Do we really want every kind of algorithm to have to =
write some complex exception specification?<br></div></blockquote><div><br>=
</div><div>=C2=A0Yes, but complex in what way? It&#39;s a yes/no answer as =
to whether a function throws or not.</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/35f89aa3-02e6-4306-a120-18cd3ebc5ddf%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/35f8=
9aa3-02e6-4306-<wbr>a120-18cd3ebc5ddf%40isocpp.org</a><wbr>.<br>
</blockquote>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAfAVvn-uUzwgnZNpcWTq_Zm--G1G5j=
S1B_Br%3D-bfE7GQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFQaeCAfAVvn-u=
UzwgnZNpcWTq_Zm--G1G5jS1B_Br%3D-bfE7GQ%40mail.gmail.com</a>.<br />

--000000000000e4690c056bfe71d8--

.

------=_Part_18783_939945041.1526198167734
Content-Type: multipart/alternative;
 boundary="----=_Part_18784_406055227.1526198167735"

------=_Part_18784_406055227.1526198167735
Content-Type: text/plain; charset="UTF-8"

@Vicente
Hi, thank you for your thoughts.

> I believe the problem is orthogonal whether the function is conditional
> noexcept is really no except as I would like to the following program to
> be ill formed as well when g.baz() becomes no noexcept after some changes.
>
> ...
>

Well, if you want to test a single expression, I see no advantages over
something like

````
void foo(const G& g) noexcept(noexcept(bar(g))) {
    bar(g);
    static_assert(noexcept(std::declval<G>().baz(), "ERROR"));
    g.baz();
}
````

In my sample the test is more near to the expression we are actually
testing.
It also means that if in the future we will remove the call to `baz`, it is
easier not to miss the `static_assert` and remove it too.

If we have only some subroutines that are `noexcept`, we can always wrap
the other in another function and mark it `noexcept`, for example:

````
// baz is not marked as noexcept, we cannot change it, but it should never
throw (according to documentation)
void call_not_noexcept_func(const G& g) noexcept { // not noexcept strong(!)
    g.baz();
}

void foo(const G& g) noexcept(strong) { // thanks to call_not_noexcept_func
we can use noexcept(strong) to test at compile time all other expressions
    bar(g);
    static_assert(noexcept(std::declval<G>().baz(), "ERROR");
    call_not_noexcept_func(g);
}
````

And in case of a terminate, we already know that we need to inspect only
`call_not_noexcept_func`, since `foo` is checked at compile time.
We have narrowed the scope where we are not `noexcept`-correct, which is
generally a good thing.

And we do not need to introduce a completely new syntax (`noexcept` taking
multiple parameters).
I do not know if there are other changes we should apply to the standard,
but with my proposal they would not be that big.
Whereas introducing a new syntax will surely require more wording.


> Have you considered the possibility to have an attribute and the
> possibility that this could be a QOI and that the compiler could warn in
> those situations?

Yes, I've considered the possibility and think that it would be suboptimal.
It would be like saying "we do not have const, but we could make an
attribute ..."
I would really like `noexcept`-correctness to be like `const`-correctness.
If `noexcept(strong)` will never be a thing, of course I would try an
attribute, but the other way around:
If the attribute is present, a compiler should not warn if there is a
`throw` statement or `noexcept(false)` function called into a
`noexcept(true)` function.
Because my hope is that in this case

````
void foo(const G& g) noexcept {
    // nested into the function, maybe after some condition
    throw g;
}
````

the compiler will warn us!

> This could be useful to experiment with the idea before making code that
> is valid today ill formed.

Which code would my proposal invalidate?
It is not a breaking change.


@Nicol:
> A `noexcept` function calling a non-`noexcept` function is perfectly
valid code.
I'm not proposing to mark such code as invalid.
But even if it is valid, there are situations where is it questionable.

> and I know that all of the operations it will use don't throw (for the
provided types)
You know the moment you wrote the code that it does not throw (modulo
errors).
But the used class or container could change over time, and now some
operations do throw, but your routine is still marked as noexcept.
Now you have a silent terminate inside a routine that no one noticed.

And testing if a class/routine really does not throw is normally difficult,
look at the standard library.
The primary cause for exceptions are `bad_alloc`.
All other exceptions are because of programming error (like an out of bound
access).
I assume that most programmers, try to write their code in such a way that
those exceptions are never triggered.

So there is this routine which is `noexcept`, and by just reading the code
we might assume that all operations are `noexcept`....
Can we test if our assumptions are true? Can we test it easily?
Because I've noticed that just reading the code is not always sufficient.

Another place where it is important not to fail is when you are already
handling an exception.
Normally you do not want to override by accident the first one or crash
while trying to report important information that would help you to analyze
the error.

And there might be other places too, for example inside a callback function
called by external libraries, since they might be have written in C.
In case of an exception they would leak resources or get in an invalid
state.

> Types are not "conditionally `noexcept`". Certain operations of those
types are conditionally `noexcept`.
Yes, sorry.

> Such forwarding is necessary only because those operations are ones which
care very much about throwing exceptions: default initialization, copy/move
operations, swapping, etc. There are very specific issues surrounding very
specific operations. The optimizations you can do when you know a copy or
move constructor won't throw are different from if you don't know that.

And we do an error while writing those wrapper, the compiler wont complain.

I'm not talking about possible optimizations, I'm talking about
code-correctness.

The constructor of `unique-ptr` for example is `noexcept`.
Not because the underlying type might be `noexcept`, and not because
someone said "just make it noexcept because I like it to behave similar to
a pointer", but because we need that guarantee to write leak-safe code.

Is this code leak-free?

````
T* T = nullptr;
load_memory(&t); // C-function, does not throw (even if not marked with
noexcept), on success T is not null, otherwise null
unique_ptr<T> handle{t};
````

Yes, it is (supposing that `load_memory` does not leak) and the reason is
that the constructor of `unique_ptr` is `noexcept`.

And what about this code this (before C++14, now we should use make_unique)

````
unique_ptr<T> handle{new T{}};
````


If `unique_ptr<T>` would throw, then we would have a leak.

> These issues are why `noexcept` was invented in the first place.

As I just showed you, `noexcept` is also important in other context too,
not only for moving and swapping.

It is used for marking code that will not fail (if certain invariants hold).
For example many container functions like `size()`, `empty()`, `clear()`,
`begin()`, `end()` and others are `noexcept` too.
`std::string` `c_str()`, `data()` and other are `noexcept`.
And we are not constructing, swapping or moving.

> Algorithms, for example, make no effort to forward `noexcept`. Because
they're not expected to do so. Even `std::copy` doesn't forward exception
behavior; external code is not going to optimize based on whether
`std::copy` throws or not.
Would you expect them to be const-correct?
In C there is no such expectation (see `strchr` for example), but in C++ I
would expect every algorithm to be const-correct.
So why no noexcept-correct? Probably because noexcept came much later
compared to const.

And again: its not about optimization, but about correcntess (same reason I
want algorithm to be const-correct, not because the compiler might optimize
something away).

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/99d4b743-2e72-4306-840f-e5d8791e6c7b%40isocpp.org.

------=_Part_18784_406055227.1526198167735
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">@Vicente<br>Hi, thank you for your thoughts.<br><br>&gt; I=
 believe the problem is orthogonal whether the function is conditional<br>&=
gt; noexcept is really no except as I would like to the following program t=
o<br>&gt; be ill formed as well when g.baz() becomes no noexcept after some=
 changes.<br>&gt;<br>&gt; ...<br>&gt;<br><br>Well, if you want to test a si=
ngle expression, I see no advantages over something like<br><br>````<br>voi=
d foo(const G&amp; g) noexcept(noexcept(bar(g))) {<br>=C2=A0=C2=A0=C2=A0 ba=
r(g);<br>=C2=A0=C2=A0=C2=A0 static_assert(noexcept(std::declval&lt;G&gt;().=
baz(), &quot;ERROR&quot;));<br>=C2=A0=C2=A0=C2=A0 g.baz();<br>}<br>````<br>=
<br>In my sample the test is more near to the expression we are actually te=
sting.<br>It also means that if in the future we will remove the call to `b=
az`, it is easier not to miss the `static_assert` and remove it too.<br><br=
>If we have only some subroutines that are `noexcept`, we can always wrap t=
he other in another function and mark it `noexcept`, for example:<br><br>``=
``<br>// baz is not marked as noexcept, we cannot change it, but it should =
never throw (according to documentation)<br>void call_not_noexcept_func(con=
st G&amp; g) noexcept { // not noexcept strong(!)<br>=C2=A0=C2=A0 =C2=A0g.b=
az();<br>}<br><br>void foo(const G&amp; g) noexcept(strong) { // thanks to =
call_not_noexcept_func we can use noexcept(strong) to test at compile time =
all other expressions <br>=C2=A0=C2=A0=C2=A0 bar(g);<br>=C2=A0=C2=A0=C2=A0 =
static_assert(noexcept(std::declval&lt;G&gt;().baz(), &quot;ERROR&quot;);<b=
r>=C2=A0=C2=A0=C2=A0 call_not_noexcept_func(g);<br>}<br>````<br><br>And in =
case of a terminate, we already know that we need to inspect only `call_not=
_noexcept_func`, since `foo` is checked at compile time.<br>We have narrowe=
d the scope where we are not `noexcept`-correct, which is generally a good =
thing.<br><br>And we do not need to introduce a completely new syntax (`noe=
xcept` taking multiple parameters).<br>I do not know if there are other cha=
nges we should apply to the standard, but with my proposal they would not b=
e that big.<br>Whereas introducing a new syntax will surely require more wo=
rding.<br><br><br>&gt; Have you considered the possibility to have an attri=
bute and the<br>&gt; possibility that this could be a QOI and that the comp=
iler could warn in<br>&gt; those situations? <br><br>Yes, I&#39;ve consider=
ed the possibility and think that it would be suboptimal.<br>It would be li=
ke saying &quot;we do not have const, but we could make an attribute ...&qu=
ot;<br>I would really like `noexcept`-correctness to be like `const`-correc=
tness.<br>If `noexcept(strong)` will never be a thing, of course I would tr=
y an attribute, but the other way around: <br>If the attribute is present, =
a compiler should not warn if there is a `throw` statement or `noexcept(fal=
se)` function called into a `noexcept(true)` function. <br>Because my hope =
is that in this case<br><br>````<br>void foo(const G&amp; g) noexcept {<br>=
=C2=A0=C2=A0 =C2=A0// nested into the function, maybe after some condition<=
br>=C2=A0=C2=A0=C2=A0 throw g;<br>}<br>````<br><br>the compiler will warn u=
s!<br><br>&gt; This could be useful to experiment with the idea before maki=
ng code that<br>&gt; is valid today ill formed. <br><br>Which code would my=
 proposal invalidate?<br>It is not a breaking change.<br><br><br>@Nicol:<br=
>&gt; A `noexcept` function calling a non-`noexcept` function is perfectly =
valid code.<br>I&#39;m not proposing to mark such code as invalid.<br>But e=
ven if it is valid, there are situations where is it questionable.<br><br>&=
gt; and I know that all of the operations it will use don&#39;t throw (for =
the provided types)<br>You know the moment you wrote the code that it does =
not throw (modulo errors).<br>But the used class or container could change =
over time, and now some operations do throw, but your routine is still mark=
ed as noexcept.<br>Now you have a silent terminate inside a routine that no=
 one noticed.<br><br>And testing if a class/routine really does not throw i=
s normally difficult, look at the standard library.<br>The primary cause fo=
r exceptions are `bad_alloc`.<br>All other exceptions are because of progra=
mming error (like an out of bound access).<br>I assume that most programmer=
s, try to write their code in such a way that those exceptions are never tr=
iggered.<br><br>So there is this routine which is `noexcept`, and by just r=
eading the code we might assume that all operations are `noexcept`....<br>C=
an we test if our assumptions are true? Can we test it easily?<br>Because I=
&#39;ve noticed that just reading the code is not always sufficient.<br><br=
>Another place where it is important not to fail is when you are already ha=
ndling an exception.<br>Normally you do not want to override by accident th=
e first one or crash while trying to report important information that woul=
d help you to analyze the error.<br><br>And there might be other places too=
, for example inside a callback function called by external libraries, sinc=
e they might be have written in C.<br>In case of an exception they would le=
ak resources or get in an invalid state.<br><br>&gt; Types are not &quot;co=
nditionally `noexcept`&quot;. Certain operations of those types are conditi=
onally `noexcept`.<br>Yes, sorry.<br><br>&gt; Such forwarding is necessary =
only because those operations are ones which care very much about throwing =
exceptions: default initialization, copy/move operations, swapping, etc. Th=
ere are very specific issues surrounding very specific operations. The opti=
mizations you can do when you know a copy or move constructor won&#39;t thr=
ow are different from if you don&#39;t know that.<br><br>And we do an error=
 while writing those wrapper, the compiler wont complain.<br><br>I&#39;m no=
t talking about possible optimizations, I&#39;m talking about code-correctn=
ess.<br><br>The constructor of `unique-ptr` for example is `noexcept`.<br>N=
ot because the underlying type might be `noexcept`, and not because someone=
 said &quot;just make it noexcept because I like it to behave similar to a =
pointer&quot;, but because we need that guarantee to write leak-safe code.<=
br><br>Is this code leak-free?<br><br>````<br>T* T =3D nullptr;<br>load_mem=
ory(&amp;t); // C-function, does not throw (even if not marked with noexcep=
t), on success T is not null, otherwise null<br>unique_ptr&lt;T&gt; handle{=
t};<br>````<br><br>Yes, it is (supposing that `load_memory` does not leak) =
and the reason is that the constructor of `unique_ptr` is `noexcept`.<br><b=
r>And what about this code this (before C++14, now we should use make_uniqu=
e)<br><br>````<br>unique_ptr&lt;T&gt; handle{new T{}};<br>````<br><br><br>I=
f `unique_ptr&lt;T&gt;` would throw, then we would have a leak.<br><br>&gt;=
 These issues are why `noexcept` was invented in the first place.<br><br>As=
 I just showed you, `noexcept` is also important in other context too, not =
only for moving and swapping.<br><br>It is used for marking code that will =
not fail (if certain invariants hold).<br>For example many container functi=
ons like `size()`, `empty()`, `clear()`, `begin()`, `end()` and others are =
`noexcept` too.<br>`std::string` `c_str()`, `data()` and other are `noexcep=
t`.<br>And we are not constructing, swapping or moving.<br><br>&gt; Algorit=
hms, for example, make no effort to forward `noexcept`. Because=20
they&#39;re not expected to do so. Even `std::copy` doesn&#39;t forward=20
exception behavior; external code is not going to optimize based on=20
whether `std::copy` throws or not.<br>Would you expect them to be const-cor=
rect?<br>In C there is no such expectation (see `strchr` for example), but =
in C++ I would expect every algorithm to be const-correct.<br>So why no noe=
xcept-correct? Probably because noexcept came much later compared to const.=
<br><br>And again: its not about optimization, but about correcntess (same =
reason I want algorithm to be const-correct, not because the compiler might=
 optimize something away).<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/99d4b743-2e72-4306-840f-e5d8791e6c7b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/99d4b743-2e72-4306-840f-e5d8791e6c7b=
%40isocpp.org</a>.<br />

------=_Part_18784_406055227.1526198167735--

------=_Part_18783_939945041.1526198167734--

.

------=_Part_21001_59502015.1526218587690
Content-Type: multipart/alternative;
 boundary="----=_Part_21002_28441270.1526218587690"

------=_Part_21002_28441270.1526218587690
Content-Type: text/plain; charset="UTF-8"

On Sunday, May 13, 2018 at 3:56:07 AM UTC-4, federico...@gmail.com wrote:
>
> @Nicol:
>
> Such forwarding is necessary only because those operations are ones which
> care very much about throwing exceptions: default initialization, copy/move
> operations, swapping, etc. There are very specific issues surrounding very
> specific operations. The optimizations you can do when you know a copy or
> move constructor won't throw are different from if you don't know that.
>
> And we do an error while writing those wrapper, the compiler wont complain.
>
> I'm not talking about possible optimizations, I'm talking about
> code-correctness.
>

`noexcept` was not created to promote code-correctness. That's why it's
*not* like `const` or `constexpr`. We don't want it to be used to promote
code correctness, because to do that requires massive proliferation of
`noexcept` in peoples' code.

`throw` specifications were created to promote code-correctness. We ditched
them because they were a terrible idea. We created `noexcept` because it
was important for certain very specific use cases. Let's not turn
`noexcept` into `throw` specifications 2.0.

The constructor of `unique-ptr` for example is `noexcept`.
> Not because the underlying type might be `noexcept`, and not because
> someone said "just make it noexcept because I like it to behave similar to
> a pointer", but because we need that guarantee to write leak-safe code.
>

No, you don't. Your code will be leak-safe because the constructor doesn't
throw, not because it is declared `noexcept`. The latter is simply one
expression of the former; it is not the only one, and it should not be
considered to be the only one.

Basically, I contest your entire premise that any function which is not
declared `noexcept` must be expected to throw. That's simply not how C++
code is written.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caccaf01-b689-4214-8bc6-efe55962daf2%40isocpp.org.

------=_Part_21002_28441270.1526218587690
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sunday, May 13, 2018 at 3:56:07 AM UTC-4, federico...@g=
mail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>@Nicol: <b=
r></div></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">&gt; Such forwarding is necessary only because those operations ar=
e ones which care very much about throwing exceptions: default initializati=
on, copy/move operations, swapping, etc. There are very specific issues sur=
rounding very specific operations. The optimizations you can do when you kn=
ow a copy or move constructor won&#39;t throw are different from if you don=
&#39;t know that.<br><br>And we do an error while writing those wrapper, th=
e compiler wont complain.<br><br>I&#39;m not talking about possible optimiz=
ations, I&#39;m talking about code-correctness.<br></div></blockquote><div>=
<br>`noexcept` was not created to promote code-correctness. That&#39;s why =
it&#39;s <i>not</i> like `const` or `constexpr`. We don&#39;t want it to be=
 used to promote code correctness, because to do that requires massive prol=
iferation of `noexcept` in peoples&#39; code.<br><br>`throw` specifications=
 were created to promote code-correctness. We ditched them because they wer=
e a terrible idea. We created `noexcept` because it was important for certa=
in very specific use cases. Let&#39;s not turn `noexcept` into `throw` spec=
ifications 2.0.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">The constructor of `unique-ptr` for example is `noexcept`.<=
br>Not because the underlying type might be `noexcept`, and not because som=
eone said &quot;just make it noexcept because I like it to behave similar t=
o a pointer&quot;, but because we need that guarantee to write leak-safe co=
de.<br></div></blockquote><div><br>No, you don&#39;t. Your code will be lea=
k-safe because the constructor doesn&#39;t throw, not because it is declare=
d `noexcept`. The latter is simply one expression of the former; it is not =
the only one, and it should not be considered to be the only one.<br><br>Ba=
sically, I contest your entire premise that any function which is not decla=
red `noexcept` must be expected to throw. That&#39;s simply not how C++ cod=
e is written.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/caccaf01-b689-4214-8bc6-efe55962daf2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/caccaf01-b689-4214-8bc6-efe55962daf2=
%40isocpp.org</a>.<br />

------=_Part_21002_28441270.1526218587690--

------=_Part_21001_59502015.1526218587690--

.

--0000000000009dff72056c2fa542
Content-Type: text/plain; charset="UTF-8"

I think a compelling reason for why noexcept functions don't have to be
constructed solely of other noexcept functions (modulo try / catch blocks)
is that a given function might have two contracts - a wide one which may
throw, and a narrow one which definitely won't. If the caller can stay
within the narrow contract, they can get noexcept guarantees, and sometimes
that's only known at runtime.

Noexcept is a *really* strong guarantee.

G

On Sun, May 13, 2018 at 7:36 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Sunday, May 13, 2018 at 3:56:07 AM UTC-4, federico...@gmail.com wrote:
>>
>> @Nicol:
>>
> > Such forwarding is necessary only because those operations are ones
>> which care very much about throwing exceptions: default initialization,
>> copy/move operations, swapping, etc. There are very specific issues
>> surrounding very specific operations. The optimizations you can do when you
>> know a copy or move constructor won't throw are different from if you don't
>> know that.
>>
>> And we do an error while writing those wrapper, the compiler wont
>> complain.
>>
>> I'm not talking about possible optimizations, I'm talking about
>> code-correctness.
>>
>
> `noexcept` was not created to promote code-correctness. That's why it's
> *not* like `const` or `constexpr`. We don't want it to be used to promote
> code correctness, because to do that requires massive proliferation of
> `noexcept` in peoples' code.
>
> `throw` specifications were created to promote code-correctness. We
> ditched them because they were a terrible idea. We created `noexcept`
> because it was important for certain very specific use cases. Let's not
> turn `noexcept` into `throw` specifications 2.0.
>
> The constructor of `unique-ptr` for example is `noexcept`.
>> Not because the underlying type might be `noexcept`, and not because
>> someone said "just make it noexcept because I like it to behave similar to
>> a pointer", but because we need that guarantee to write leak-safe code.
>>
>
> No, you don't. Your code will be leak-safe because the constructor doesn't
> throw, not because it is declared `noexcept`. The latter is simply one
> expression of the former; it is not the only one, and it should not be
> considered to be the only one.
>
> Basically, I contest your entire premise that any function which is not
> declared `noexcept` must be expected to throw. That's simply not how C++
> code is written.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/caccaf01-b689-4214-
> 8bc6-efe55962daf2%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/caccaf01-b689-4214-8bc6-efe55962daf2%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUzuDu-s7b_L8rJetOfxUFpauFmxogmzqFGOhjzXJ64EA%40mail.gmail.com.

--0000000000009dff72056c2fa542
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think a compelling reason for why noexcept functions don=
&#39;t have to be constructed solely of other noexcept functions (modulo tr=
y / catch blocks) is that a given function might have two contracts - a wid=
e one which may throw, and a narrow one which definitely won&#39;t. If the =
caller can stay within the narrow contract, they can get noexcept guarantee=
s, and sometimes that&#39;s only known at runtime.<div><br></div><div>Noexc=
ept is a *really* strong guarantee.</div><div><br></div><div>G</div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Sun, May 13, 20=
18 at 7:36 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesso=
n@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Sunday, May 13, 2018 at=
 3:56:07 AM UTC-4, <a href=3D"mailto:federico...@gmail.com" target=3D"_blan=
k">federico...@gmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div>@Nicol: <br></div></blockquote><span class=3D""><blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr">&gt; Such forwarding is necessary only =
because those operations are ones which care very much about throwing excep=
tions: default initialization, copy/move operations, swapping, etc. There a=
re very specific issues surrounding very specific operations. The optimizat=
ions you can do when you know a copy or move constructor won&#39;t throw ar=
e different from if you don&#39;t know that.<br><br>And we do an error whil=
e writing those wrapper, the compiler wont complain.<br><br>I&#39;m not tal=
king about possible optimizations, I&#39;m talking about code-correctness.<=
br></div></blockquote></span><div><br>`noexcept` was not created to promote=
 code-correctness. That&#39;s why it&#39;s <i>not</i> like `const` or `cons=
texpr`. We don&#39;t want it to be used to promote code correctness, becaus=
e to do that requires massive proliferation of `noexcept` in peoples&#39; c=
ode.<br><br>`throw` specifications were created to promote code-correctness=
.. We ditched them because they were a terrible idea. We created `noexcept` =
because it was important for certain very specific use cases. Let&#39;s not=
 turn `noexcept` into `throw` specifications 2.0.<br><br></div><span class=
=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The construc=
tor of `unique-ptr` for example is `noexcept`.<br>Not because the underlyin=
g type might be `noexcept`, and not because someone said &quot;just make it=
 noexcept because I like it to behave similar to a pointer&quot;, but becau=
se we need that guarantee to write leak-safe code.<br></div></blockquote></=
span><div><br>No, you don&#39;t. Your code will be leak-safe because the co=
nstructor doesn&#39;t throw, not because it is declared `noexcept`. The lat=
ter is simply one expression of the former; it is not the only one, and it =
should not be considered to be the only one.<br><br>Basically, I contest yo=
ur entire premise that any function which is not declared `noexcept` must b=
e expected to throw. That&#39;s simply not how C++ code is written.<br></di=
v></div><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/caccaf01-b689-4214-8bc6-efe55962daf2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/cacc=
af01-b689-4214-<wbr>8bc6-efe55962daf2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUzuDu-s7b_L8rJetOfxUFpauFmxo=
gmzqFGOhjzXJ64EA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAANG%3DkUzuDu-=
s7b_L8rJetOfxUFpauFmxogmzqFGOhjzXJ64EA%40mail.gmail.com</a>.<br />

--0000000000009dff72056c2fa542--

.

------=_Part_6669_703949799.1526586701153
Content-Type: multipart/alternative;
 boundary="----=_Part_6670_1245572199.1526586701153"

------=_Part_6670_1245572199.1526586701153
Content-Type: text/plain; charset="UTF-8"



> The constructor of `unique-ptr` for example is `noexcept`.
>>> Not because the underlying type might be `noexcept`, and not because
>>> someone said "just make it noexcept because I like it to behave similar to
>>> a pointer", but because we need that guarantee to write leak-safe code.
>>>
>>
>> No, you don't. Your code will be leak-safe because the constructor
>> doesn't throw, not because it is declared `noexcept`. The latter is simply
>> one expression of the former; it is not the only one, and it should not be
>> considered to be the only one.
>>
>> Basically, I contest your entire premise that any function which is not
>> declared `noexcept` must be expected to throw. That's simply not how C++
>> code is written.
>>
>
Well, we clearly have completely different views for what noexcept can be
used, and how we use it.
I researched the  topic a little bit, as far as I can see it is recommended
practice to mark functions that we do not ever want to fail with
`noexcept`, and the standard library seems to do so too (see my example
with `unique_ptr`, or all the functions I've listed for containers, but no
only those).

Do you mind to share some resource on the topic, since you claimed that my
premise is wrong (every function not marked as noexcept should be
considered as a function that could throw, with minor exceptions like C
functions, functions marked with throw(), operations on fundamental types
and so on).

And even if "noexcept` was not created to promote code-correctness", it
does not mean that it cannot be used to promote it.
Templates where also not created to do compile-time computations...


I do not see how `noexcept(strong)` (without removing `noexcept(true)`)
would make `noexcept` more similar to `throw()`, since `noexcept` is at
compile time and throw specification where checked at runtime...

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/42ec1d87-b004-42f0-bd29-b6747ffac45f%40isocpp.org.

------=_Part_6670_1245572199.1526586701153
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">The constructor of `unique-ptr` f=
or example is `noexcept`.<br>Not because the underlying type might be `noex=
cept`, and not because someone said &quot;just make it noexcept because I l=
ike it to behave similar to a pointer&quot;, but because we need that guara=
ntee to write leak-safe code.<br></div></blockquote></span><div><br>No, you=
 don&#39;t. Your code will be leak-safe because the constructor doesn&#39;t=
 throw, not because it is declared `noexcept`. The latter is simply one exp=
ression of the former; it is not the only one, and it should not be conside=
red to be the only one.<br><br>Basically, I contest your entire premise tha=
t any function which is not declared `noexcept` must be expected to throw. =
That&#39;s simply not how C++ code is written.<br></div></div><span>

</span></blockquote></div></div></blockquote><div><br>Well, we clearly have=
 completely different views for what noexcept can be used, and how we use i=
t.<br>I researched the=C2=A0 topic a little bit, as far as I can see it is =
recommended practice to mark functions that we do not ever want to fail wit=
h `noexcept`, and the standard library seems to do so too (see my example w=
ith `unique_ptr`, or all the functions I&#39;ve listed for containers, but =
no only those).<br><br>Do you mind to share some resource on the topic, sin=
ce you claimed that my premise is wrong (every function not marked as noexc=
ept should be considered as a function that could throw, with minor excepti=
ons like C functions, functions marked with throw(), operations on fundamen=
tal types and so on).<br><br>And even if &quot;noexcept` was not created to=
 promote code-correctness&quot;, it does not mean that it cannot be used to=
 promote it.<br>Templates where also not created to do compile-time computa=
tions...<br><br><br>I do not see how `noexcept(strong)` (without removing `=
noexcept(true)`) would make `noexcept` more similar to `throw()`, since `no=
except` is at compile time and throw specification where checked at runtime=
....<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/42ec1d87-b004-42f0-bd29-b6747ffac45f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/42ec1d87-b004-42f0-bd29-b6747ffac45f=
%40isocpp.org</a>.<br />

------=_Part_6670_1245572199.1526586701153--

------=_Part_6669_703949799.1526586701153--

.

------=_Part_7669_497303836.1526606592029
Content-Type: multipart/alternative;
 boundary="----=_Part_7670_1822290723.1526606592030"

------=_Part_7670_1822290723.1526606592030
Content-Type: text/plain; charset="UTF-8"

On Thursday, May 17, 2018 at 3:51:41 PM UTC-4, federico...@gmail.com wrote:
>
>
> The constructor of `unique-ptr` for example is `noexcept`.
>>>> Not because the underlying type might be `noexcept`, and not because
>>>> someone said "just make it noexcept because I like it to behave similar to
>>>> a pointer", but because we need that guarantee to write leak-safe code.
>>>>
>>>
>>> No, you don't. Your code will be leak-safe because the constructor
>>> doesn't throw, not because it is declared `noexcept`. The latter is simply
>>> one expression of the former; it is not the only one, and it should not be
>>> considered to be the only one.
>>>
>>> Basically, I contest your entire premise that any function which is not
>>> declared `noexcept` must be expected to throw. That's simply not how C++
>>> code is written.
>>>
>>
> Well, we clearly have completely different views for what noexcept can be
> used, and how we use it.
> I researched the  topic a little bit, as far as I can see it is
> recommended practice to mark functions that we do not ever want to fail
> with `noexcept`, and the standard library seems to do so too (see my
> example with `unique_ptr`, or all the functions I've listed for containers,
> but no only those).
>

Here are a few counter-examples from the standard library:

* The entire random number generation facility. There are a bunch of
blanket statements like, "Except where specified otherwise, no function
described in this section [rand.eng]/[rand. throws an exception." Yet *not
one of those function* is `noexcept`. Nor are the distribution functions
marked `noexcept`, even conditionally.

* The new elementary string conversion functions, `to_chars/from_chars`.
Not only do they not throw, they have their own error mechanism, yet they
lack `noexcept`.

* The entire standard algorithms library. They pass exceptions through
them, but none of them throw anything themselves. Yet they are not
conditionally `noexcept`.

And these are the ones I came up with because those chapters were the
closest ones to where my spec PDF happened to open up.

My views on `noexcept` reflect both the intent of the feature's design and
the reality of its use.

Do you mind to share some resource on the topic, since you claimed that my
> premise is wrong (every function not marked as noexcept should be
> considered as a function that could throw, with minor exceptions like C
> functions, functions marked with throw(), operations on fundamental types
> and so on).
>

Look around. How many C++ libraries do you know of that practice a *strict*
policy of `noexcept` decorations on everything that genuinely doesn't throw
exceptions? Boost? Poco? Qt? You can't even say this about the C++ standard
library.

And even if "noexcept` was not created to promote code-correctness", it
> does not mean that it cannot be used to promote it.
> Templates where also not created to do compile-time computations...
>

Yes, and we're trying our best to *stop doing that*. That's one of the
reasons for `constexpr` stuff; so that we can stop using templates to do
what ought to be done in something that looks like actual C++. It's the
same reason why we want to have static reflection through a `constexpr`
interface rather than a template-based one.

C++ has enough misappropriation of features for unintended purposes; let's
not encourage it.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%40isocpp.org.

------=_Part_7670_1822290723.1526606592030
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, May 17, 2018 at 3:51:41 PM UTC-4, federico...=
@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">The constructor of `unique-ptr` for example is `noe=
xcept`.<br>Not because the underlying type might be `noexcept`, and not bec=
ause someone said &quot;just make it noexcept because I like it to behave s=
imilar to a pointer&quot;, but because we need that guarantee to write leak=
-safe code.<br></div></blockquote></span><div><br>No, you don&#39;t. Your c=
ode will be leak-safe because the constructor doesn&#39;t throw, not becaus=
e it is declared `noexcept`. The latter is simply one expression of the for=
mer; it is not the only one, and it should not be considered to be the only=
 one.<br><br>Basically, I contest your entire premise that any function whi=
ch is not declared `noexcept` must be expected to throw. That&#39;s simply =
not how C++ code is written.<br></div></div><span>

</span></blockquote></div></div></blockquote><div><br>Well, we clearly have=
 completely different views for what noexcept can be used, and how we use i=
t.<br>I researched the=C2=A0 topic a little bit, as far as I can see it is =
recommended practice to mark functions that we do not ever want to fail wit=
h `noexcept`, and the standard library seems to do so too (see my example w=
ith `unique_ptr`, or all the functions I&#39;ve listed for containers, but =
no only those).<br></div></blockquote><div><br></div><div>Here are a few co=
unter-examples from the standard library:</div><div><br></div><div>* The en=
tire random number generation facility. There are a bunch of blanket statem=
ents like, &quot;Except where specified otherwise, no function described in=
 this section [rand.eng]/[rand. throws an exception.&quot; Yet <i>not one o=
f those function</i> is `noexcept`. Nor are the distribution functions mark=
ed `noexcept`, even conditionally.</div><div><br></div><div>* The new eleme=
ntary string conversion functions, `to_chars/from_chars`. Not only do they =
not throw, they have their own error mechanism, yet they lack `noexcept`.<b=
r></div><div><br></div><div>* The entire standard algorithms library. They =
pass exceptions through them, but none of them throw anything themselves. Y=
et they are not conditionally `noexcept`.</div><div><br></div><div>And thes=
e are the ones I came up with because those chapters were the closest ones =
to where my spec PDF happened to open up.</div><div><br></div><div>My views=
 on `noexcept` reflect both the intent of the feature&#39;s design and the =
reality of its use.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div>Do you mind to share some resource on the topic, since y=
ou claimed that my premise is wrong (every function not marked as noexcept =
should be considered as a function that could throw, with minor exceptions =
like C functions, functions marked with throw(), operations on fundamental =
types and so on).<br></div></blockquote><div><br></div><div>Look around. Ho=
w many C++ libraries do you know of that practice a <i>strict</i> policy of=
 `noexcept` decorations on everything that genuinely doesn&#39;t throw exce=
ptions? Boost? Poco? Qt? You can&#39;t even say this about the C++ standard=
 library.</div><br><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>And ev=
en if &quot;noexcept` was not created to promote code-correctness&quot;, it=
 does not mean that it cannot be used to promote it.<br>Templates where als=
o not created to do compile-time computations...<br></div></blockquote><div=
><br></div><div>Yes, and we&#39;re trying our best to <i>stop doing that</i=
>. That&#39;s one of the reasons for `constexpr` stuff; so that we can stop=
 using templates to do what ought to be done in something that looks like a=
ctual C++. It&#39;s the same reason why we want to have static reflection t=
hrough a `constexpr` interface rather than a template-based one.</div><div>=
<br></div><div>C++ has enough misappropriation of features for unintended p=
urposes; let&#39;s not encourage it.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58=
%40isocpp.org</a>.<br />

------=_Part_7670_1822290723.1526606592030--

------=_Part_7669_497303836.1526606592029--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">The main reason for std functions that don't throw, but don't s=
ay noexcept, is that we allow implementations to throw on precondition viol=
ations.</div><div style=3D"width: 100%; font-size: initial; font-family: Ca=
libri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-a=
lign: initial; background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);">Otherwise, most nonthrowing functions would =
be marked noexcept. Or conditionally noexcept. </div><div style=3D"width: 1=
00%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, san=
s-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rg=
b(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: initial;=
 font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, =
73, 125); text-align: initial; background-color: rgb(255, 255, 255);">With =
Contracts, our policies may change. (if contracts were checked outside the =
noexcept...)</div><div style=3D"width: 100%; font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);"><br></div>      =
                                                                           =
                                                    <div style=3D"width: 10=
0%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans=
-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb=
(255, 255, 255);"><br style=3D"display:initial"></div>                     =
                                                                           =
                                                                           =
                        <div style=3D"font-size: initial; font-family: Cali=
bri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-ali=
gn: initial; background-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&=
nbsp;BlackBerry&nbsp;portable&nbsp;Babbage&nbsp;Device</div>               =
                                                                           =
                                                                           =
             <table width=3D"100%" style=3D"background-color:white;border-s=
pacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-size: initial; tex=
t-align: initial; background-color: rgb(255, 255, 255);">                  =
         <div style=3D"border-style: solid none none; border-top-color: rgb=
(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0in; font-family: =
Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b=
>Nicol Bolas</div><div><b>Sent: </b>Thursday, May 17, 2018 9:23 PM</div><di=
v><b>To: </b>ISO C++ Standard - Future Proposals</div><div><b>Reply To: </b=
>std-proposals@isocpp.org</div><div><b>Cc: </b>federico.kircheis@gmail.com<=
/div><div><b>Subject: </b>Re: [std-proposals] noexcept-correctenss</div></d=
iv></td></tr></tbody></table><div style=3D"border-style: solid none none; b=
order-top-color: rgb(186, 188, 209); border-top-width: 1pt; font-size: init=
ial; text-align: initial; background-color: rgb(255, 255, 255);"></div><br>=
<div id=3D"_originalContent" style=3D""><div dir=3D"ltr">On Thursday, May 1=
7, 2018 at 3:51:41 PM UTC-4, federico...@gmail.com wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><br><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><span><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">The constr=
uctor of `unique-ptr` for example is `noexcept`.<br>Not because the underly=
ing type might be `noexcept`, and not because someone said "just make it no=
except because I like it to behave similar to a pointer", but because we ne=
ed that guarantee to write leak-safe code.<br></div></blockquote></span><di=
v><br>No, you don't. Your code will be leak-safe because the constructor do=
esn't throw, not because it is declared `noexcept`. The latter is simply on=
e expression of the former; it is not the only one, and it should not be co=
nsidered to be the only one.<br><br>Basically, I contest your entire premis=
e that any function which is not declared `noexcept` must be expected to th=
row. That's simply not how C++ code is written.<br></div></div><span>

</span></blockquote></div></div></blockquote><div><br>Well, we clearly have=
 completely different views for what noexcept can be used, and how we use i=
t.<br>I researched the&nbsp; topic a little bit, as far as I can see it is =
recommended practice to mark functions that we do not ever want to fail wit=
h `noexcept`, and the standard library seems to do so too (see my example w=
ith `unique_ptr`, or all the functions I've listed for containers, but no o=
nly those).<br></div></blockquote><div><br></div><div>Here are a few counte=
r-examples from the standard library:</div><div><br></div><div>* The entire=
 random number generation facility. There are a bunch of blanket statements=
 like, "Except where specified otherwise, no function described in this sec=
tion [rand.eng]/[rand. throws an exception." Yet <i>not one of those functi=
on</i> is `noexcept`. Nor are the distribution functions marked `noexcept`,=
 even conditionally.</div><div><br></div><div>* The new elementary string c=
onversion functions, `to_chars/from_chars`. Not only do they not throw, the=
y have their own error mechanism, yet they lack `noexcept`.<br></div><div><=
br></div><div>* The entire standard algorithms library. They pass exception=
s through them, but none of them throw anything themselves. Yet they are no=
t conditionally `noexcept`.</div><div><br></div><div>And these are the ones=
 I came up with because those chapters were the closest ones to where my sp=
ec PDF happened to open up.</div><div><br></div><div>My views on `noexcept`=
 reflect both the intent of the feature's design and the reality of its use=
..<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
>Do you mind to share some resource on the topic, since you claimed that my=
 premise is wrong (every function not marked as noexcept should be consider=
ed as a function that could throw, with minor exceptions like C functions, =
functions marked with throw(), operations on fundamental types and so on).<=
br></div></blockquote><div><br></div><div>Look around. How many C++ librari=
es do you know of that practice a <i>strict</i> policy of `noexcept` decora=
tions on everything that genuinely doesn't throw exceptions? Boost? Poco? Q=
t? You can't even say this about the C++ standard library.</div><br><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div>And even if "noexcept` was not c=
reated to promote code-correctness", it does not mean that it cannot be use=
d to promote it.<br>Templates where also not created to do compile-time com=
putations...<br></div></blockquote><div><br></div><div>Yes, and we're tryin=
g our best to <i>stop doing that</i>. That's one of the reasons for `conste=
xpr` stuff; so that we can stop using templates to do what ought to be done=
 in something that looks like actual C++. It's the same reason why we want =
to have static reflection through a `constexpr` interface rather than a tem=
plate-based one.</div><div><br></div><div>C++ has enough misappropriation o=
f features for unintended purposes; let's not encourage it.</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaf=
fa58%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/20180518012917.5054545.37552.52700%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20180518012917.5054545.37552.52700%40gm=
ail.com</a>.<br />

.

------=_Part_8915_159726651.1526621332816
Content-Type: multipart/alternative;
 boundary="----=_Part_8916_380209231.1526621332816"

------=_Part_8916_380209231.1526621332816
Content-Type: text/plain; charset="UTF-8"

On Thursday, May 17, 2018 at 9:29:21 PM UTC-4, Tony V E wrote:
>
> The main reason for std functions that don't throw, but don't say
> noexcept, is that we allow implementations to throw on precondition
> violations.
>
> Otherwise, most nonthrowing functions would be marked noexcept. Or
> conditionally noexcept
>

So what about the ones that have no preconditions to violate? For example,
`uniform_int_distribution::a` and similar functions.

This all seems less like deliberate design and more like nobody spent the
time doing a full `noexcept` pass over the library. Which is exactly my
point: if the standards committee hasn't done that for the feature they
themselves created, why would you expect other C++ libraries to do the
same? And without doing a full `noexcept` pass over a library, you can't
gain much from `noexcept(strong)`.

With Contracts, our policies may change. (if contracts were checked outside
> the noexcept...)
>
>
> Sent from my BlackBerry portable Babbage Device
> *From: *Nicol Bolas
> *Sent: *Thursday, May 17, 2018 9:23 PM
> *To: *ISO C++ Standard - Future Proposals
> *Reply To: *std-pr...@isocpp.org <javascript:>
> *Cc: *federico...@gmail.com <javascript:>
> *Subject: *Re: [std-proposals] noexcept-correctenss
>
> On Thursday, May 17, 2018 at 3:51:41 PM UTC-4, federico...@gmail.com
> wrote:
>>
>>
>> The constructor of `unique-ptr` for example is `noexcept`.
>>>>> Not because the underlying type might be `noexcept`, and not because
>>>>> someone said "just make it noexcept because I like it to behave similar to
>>>>> a pointer", but because we need that guarantee to write leak-safe code.
>>>>>
>>>>
>>>> No, you don't. Your code will be leak-safe because the constructor
>>>> doesn't throw, not because it is declared `noexcept`. The latter is simply
>>>> one expression of the former; it is not the only one, and it should not be
>>>> considered to be the only one.
>>>>
>>>> Basically, I contest your entire premise that any function which is not
>>>> declared `noexcept` must be expected to throw. That's simply not how C++
>>>> code is written.
>>>>
>>>
>> Well, we clearly have completely different views for what noexcept can be
>> used, and how we use it.
>> I researched the  topic a little bit, as far as I can see it is
>> recommended practice to mark functions that we do not ever want to fail
>> with `noexcept`, and the standard library seems to do so too (see my
>> example with `unique_ptr`, or all the functions I've listed for containers,
>> but no only those).
>>
>
> Here are a few counter-examples from the standard library:
>
> * The entire random number generation facility. There are a bunch of
> blanket statements like, "Except where specified otherwise, no function
> described in this section [rand.eng]/[rand. throws an exception." Yet *not
> one of those function* is `noexcept`. Nor are the distribution functions
> marked `noexcept`, even conditionally.
>
> * The new elementary string conversion functions, `to_chars/from_chars`.
> Not only do they not throw, they have their own error mechanism, yet they
> lack `noexcept`.
>
> * The entire standard algorithms library. They pass exceptions through
> them, but none of them throw anything themselves. Yet they are not
> conditionally `noexcept`.
>
> And these are the ones I came up with because those chapters were the
> closest ones to where my spec PDF happened to open up.
>
> My views on `noexcept` reflect both the intent of the feature's design and
> the reality of its use.
>
> Do you mind to share some resource on the topic, since you claimed that my
>> premise is wrong (every function not marked as noexcept should be
>> considered as a function that could throw, with minor exceptions like C
>> functions, functions marked with throw(), operations on fundamental types
>> and so on).
>>
>
> Look around. How many C++ libraries do you know of that practice a
> *strict* policy of `noexcept` decorations on everything that genuinely
> doesn't throw exceptions? Boost? Poco? Qt? You can't even say this about
> the C++ standard library.
>
> And even if "noexcept` was not created to promote code-correctness", it
>> does not mean that it cannot be used to promote it.
>> Templates where also not created to do compile-time computations...
>>
>
> Yes, and we're trying our best to *stop doing that*. That's one of the
> reasons for `constexpr` stuff; so that we can stop using templates to do
> what ought to be done in something that looks like actual C++. It's the
> same reason why we want to have static reflection through a `constexpr`
> interface rather than a template-based one.
>
> C++ has enough misappropriation of features for unintended purposes; let's
> not encourage it.
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposal...@isocpp.org <javascript:>.
> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cb141fd1-d0c4-4ac6-a7a7-fda8e1e4f0c6%40isocpp.org.

------=_Part_8916_380209231.1526621332816
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, May 17, 2018 at 9:29:21 PM UTC-4, Tony V E wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"background-c=
olor:rgb(255,255,255);line-height:initial" lang=3D"en-US">                 =
                                                                     <div s=
tyle=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro&#39=
;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-=
color:rgb(255,255,255)">The main reason for std functions that don&#39;t th=
row, but don&#39;t say noexcept, is that we allow implementations to throw =
on precondition violations.</div><div style=3D"width:100%;font-size:initial=
;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31=
,73,125);text-align:initial;background-color:rgb(255,255,255)"><br></div><d=
iv style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slate Pro=
&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgro=
und-color:rgb(255,255,255)">Otherwise, most nonthrowing functions would be =
marked noexcept. Or conditionally noexcept</div></div></blockquote><div><br=
></div><div>So what about the ones that have no preconditions to violate? F=
or example, `uniform_int_distribution::a` and similar functions.<br></div><=
div><br></div><div>This all seems less like deliberate design and more like=
 nobody spent the time doing a full `noexcept` pass over the library. Which=
 is exactly my point: if the standards committee hasn&#39;t done that for t=
he feature they themselves created, why would you expect other C++ librarie=
s to do the same? And without doing a full `noexcept` pass over a library, =
you can&#39;t gain much from `noexcept(strong)`.<br></div><br><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;"><div style=3D"background-color:rgb(255,255,=
255);line-height:initial" lang=3D"en-US"><div style=3D"width:100%;font-size=
:initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;colo=
r:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"> </d=
iv><div style=3D"width:100%;font-size:initial;font-family:Calibri,&#39;Slat=
e Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;ba=
ckground-color:rgb(255,255,255)"></div><div style=3D"width:100%;font-size:i=
nitial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:=
rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)">With C=
ontracts, our policies may change. (if contracts were checked outside the n=
oexcept...)</div><div style=3D"width:100%;font-size:initial;font-family:Cal=
ibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color:rgb(31,73,125);text-al=
ign:initial;background-color:rgb(255,255,255)"><br></div>                  =
                                                                           =
                                        <div style=3D"width:100%;font-size:=
initial;font-family:Calibri,&#39;Slate Pro&#39;,sans-serif,sans-serif;color=
:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255)"><br s=
tyle=3D"display:initial"></div>                                            =
                                                                           =
                                                                           =
 <div style=3D"font-size:initial;font-family:Calibri,&#39;Slate Pro&#39;,sa=
ns-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-colo=
r:rgb(255,255,255)">Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A0<wbr>portab=
le=C2=A0Babbage=C2=A0Device</div>                                          =
                                                                           =
                                                             <table style=
=3D"background-color:white;border-spacing:0px" width=3D"100%"> <tbody><tr><=
td colspan=3D"2" style=3D"font-size:initial;text-align:initial;background-c=
olor:rgb(255,255,255)">                           <div style=3D"border-styl=
e:solid none none;border-top-color:rgb(181,196,223);border-top-width:1pt;pa=
dding:3pt 0in 0in;font-family:Tahoma,&#39;BB Alpha Sans&#39;,&#39;Slate Pro=
&#39;;font-size:10pt">  <div><b>From: </b>Nicol Bolas</div><div><b>Sent: </=
b>Thursday, May 17, 2018 9:23 PM</div><div><b>To: </b>ISO C++ Standard - Fu=
ture Proposals</div><div><b>Reply To: </b><a href=3D"javascript:" target=3D=
"_blank" gdf-obfuscated-mailto=3D"vFOCPR31AQAJ" rel=3D"nofollow" onmousedow=
n=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=
=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a></div><div><=
b>Cc: </b><a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"vFOCPR31AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">federico...@gmail.com</a></div><div><b>Subject: </b>Re: [std-proposa=
ls] noexcept-correctenss</div></div></td></tr></tbody></table><div style=3D=
"border-style:solid none none;border-top-color:rgb(186,188,209);border-top-=
width:1pt;font-size:initial;text-align:initial;background-color:rgb(255,255=
,255)"></div><br><div><div dir=3D"ltr">On Thursday, May 17, 2018 at 3:51:41=
 PM UTC-4, <a>federico...@gmail.com</a> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"g=
mail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">The constructor of `unique-=
ptr` for example is `noexcept`.<br>Not because the underlying type might be=
 `noexcept`, and not because someone said &quot;just make it noexcept becau=
se I like it to behave similar to a pointer&quot;, but because we need that=
 guarantee to write leak-safe code.<br></div></blockquote></span><div><br>N=
o, you don&#39;t. Your code will be leak-safe because the constructor doesn=
&#39;t throw, not because it is declared `noexcept`. The latter is simply o=
ne expression of the former; it is not the only one, and it should not be c=
onsidered to be the only one.<br><br>Basically, I contest your entire premi=
se that any function which is not declared `noexcept` must be expected to t=
hrow. That&#39;s simply not how C++ code is written.<br></div></div><span>

</span></blockquote></div></div></blockquote><div><br>Well, we clearly have=
 completely different views for what noexcept can be used, and how we use i=
t.<br>I researched the=C2=A0 topic a little bit, as far as I can see it is =
recommended practice to mark functions that we do not ever want to fail wit=
h `noexcept`, and the standard library seems to do so too (see my example w=
ith `unique_ptr`, or all the functions I&#39;ve listed for containers, but =
no only those).<br></div></blockquote><div><br></div><div>Here are a few co=
unter-examples from the standard library:</div><div><br></div><div>* The en=
tire random number generation facility. There are a bunch of blanket statem=
ents like, &quot;Except where specified otherwise, no function described in=
 this section [rand.eng]/[rand. throws an exception.&quot; Yet <i>not one o=
f those function</i> is `noexcept`. Nor are the distribution functions mark=
ed `noexcept`, even conditionally.</div><div><br></div><div>* The new eleme=
ntary string conversion functions, `to_chars/from_chars`. Not only do they =
not throw, they have their own error mechanism, yet they lack `noexcept`.<b=
r></div><div><br></div><div>* The entire standard algorithms library. They =
pass exceptions through them, but none of them throw anything themselves. Y=
et they are not conditionally `noexcept`.</div><div><br></div><div>And thes=
e are the ones I came up with because those chapters were the closest ones =
to where my spec PDF happened to open up.</div><div><br></div><div>My views=
 on `noexcept` reflect both the intent of the feature&#39;s design and the =
reality of its use.<br></div><div><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div>Do you mind to share some resource on the topic, since you cl=
aimed that my premise is wrong (every function not marked as noexcept shoul=
d be considered as a function that could throw, with minor exceptions like =
C functions, functions marked with throw(), operations on fundamental types=
 and so on).<br></div></blockquote><div><br></div><div>Look around. How man=
y C++ libraries do you know of that practice a <i>strict</i> policy of `noe=
xcept` decorations on everything that genuinely doesn&#39;t throw exception=
s? Boost? Poco? Qt? You can&#39;t even say this about the C++ standard libr=
ary.</div><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>And even if &quo=
t;noexcept` was not created to promote code-correctness&quot;, it does not =
mean that it cannot be used to promote it.<br>Templates where also not crea=
ted to do compile-time computations...<br></div></blockquote><div><br></div=
><div>Yes, and we&#39;re trying our best to <i>stop doing that</i>. That&#3=
9;s one of the reasons for `constexpr` stuff; so that we can stop using tem=
plates to do what ought to be done in something that looks like actual C++.=
 It&#39;s the same reason why we want to have static reflection through a `=
constexpr` interface rather than a template-based one.</div><div><br></div>=
<div>C++ has enough misappropriation of features for unintended purposes; l=
et&#39;s not encourage it.</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vFOCPR31AQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"vFOCPR31AQAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/02364803-d36d-41a6-acf6-c72f6eaffa58%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/02364803-d36d-41a6-<wbr>acf6-=
c72f6eaffa58%40isocpp.org</a><wbr>.<br>
<br></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cb141fd1-d0c4-4ac6-a7a7-fda8e1e4f0c6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cb141fd1-d0c4-4ac6-a7a7-fda8e1e4f0c6=
%40isocpp.org</a>.<br />

------=_Part_8916_380209231.1526621332816--

------=_Part_8915_159726651.1526621332816--

.

------=_Part_9297_682859325.1526622550741
Content-Type: multipart/alternative;
 boundary="----=_Part_9298_130219351.1526622550741"

------=_Part_9298_130219351.1526622550741
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

All functions you mentioned (except for the random number generation=20
facility that I do not know well enough), can fail (at least=20
conditionally), and this is the main reason for not marking them as=20
noexcept.

> The main reason for std functions that don't throw, but don't say=20
noexcept, is that we allow implementations to throw on precondition=20
violations.
As Tony said, implementations are allowed to throw on preconditions=20
violations (did not think of it. checked iterators is a good example, AFAIK=
=20
iterators are not marked `noexcept`, but they are not required to throw=20
either).

> Look around. How many C++ libraries do you know of that practice a=20
*strict* policy of `noexcept` decorations on everything that genuinely=20
doesn't throw exceptions?

I guess not many (even if I do not know the internals of most libraries)=20
and in my opinion it's because there are not really many static tools for=
=20
verifying for noexcept-correctness.
From a stability point of view, it's easier to document a function as=20
non-throwing, and if it throws, it is still a recoverable error for the=20
main application, so not a blocking issue.
If it throws and it is marked as `noexcept`, it will terminate, and that's=
=20
not exactly a great feature for a library or a good sign of stability.

But most big libraries I know and have used are also pre c++11 or more=20
c-style... still I would not claim that many tools that came with c++11=20
should be used only in certain contexts because they are not widely used.
Most younger libraries I know, use noexcept and not only for moving, and=20
they use it for guaranteeing that something will not fail, instead of=20
writing a separate documentation.

> With Contracts, our policies may change. (if contracts were checked=20
outside the noexcept...)
I admit that I did not know that contracts could influence `noexcept`, so=
=20
I'll give a look at that proposal too.


Just for the record, here are some references I found when searching on the=
=20
topic:

https://stackoverflow.com/questions/10787766/when-should-i-really-use-noexc=
ept
Recommendations are
1) "[...] use it when it's obvious that the function will never throw."
2) "[...] *semantics first* [...] As a programmer reading code, the=20
presence of noexcept is akin to that of const: it helps me better grok what=
=20
may or may not happen. Therefore, it is worthwhile spending some time=20
thinking about whether or not you know if the function will throw. For=20
reminder, any kind of dynamic memory allocation may throw. [...] now on to=
=20
the possible optimizations. [...]"

The consensus seems to be that if a function cannot and should not fail,=20
then it should be marked as noexcept.


https://akrzemi1.wordpress.com/2014/04/24/noexcept-what-for/
1) Makes the standard example where `noexcept` is used in order to=20
guarantee that `push_back` has a strong exception guarantee (which has=20
nothing to do with optimizations)
2) "This is because the information that noexcept really is intended to=20
convey is that the function *never fails*; not that it never throws! [...]=
=20
This is part of a more general observation, that what we are interested in=
=20
is really failure safety in program components rather than exception safety=
=20
<http://www.boost.org/community/exception_safety.html>. No matter if you=20
use exceptions, error return values, errno or whatever else, the reasoning=
=20
about basic (no leak, invariant preserved), strong (commit or rollback) and=
=20
never-fail guarantee should still hold."

3) The last point, "More eager termiation" is particularly interesting,=20
because with what I'm proposing we would be able to reduce those runtime=20
errors.

4) From a comment (I swear it's not mine) "IMO using noexcept is like using=
=20
const [...] Just like we don=E2=80=99t say we should not use const because=
=20
libraries may =E2=80=98mutable=E2=80=99 themselves out of the const contrac=
t, it does=20
equally not seem like a good idea to promote such a thing for what I would=
=20
like to call noexcept correctness."


The consensus, again, seems to be that if a function cannot and should not=
=20
fail, then it should be marked as noexcept.


https://google.github.io/styleguide/cppguide.html

1) "You may use noexcept when it is useful for performance if it accurately=
=20
reflects the intended semantics of your function, i.e. that if an exception=
=20
is somehow thrown from within the function body then it represents a fatal=
=20
error."

2) "instead of writing a complicated noexcept clause that depends on=20
whether a hash function can throw, for example, simply document that your=
=20
component doesn=E2=80=99t support hash functions throwing and make it=20
unconditionally noexcept."


The guideline puts a lot of focus on performance, and that writing a=20
correct noexcept specifier is hard (`noexcept(auto)` would therefore help),=
=20
and thus use comments (hopefully some `static_assert` too).


https://scottmeyers.blogspot.de/2014/03/declare-functions-noexcept-whenever=
..html
1) Well the title says all...

https://arne-mertz.de/2016/01/modern-c-features-keyword-noexcept/
1) "`noexcept` is worth keeping in mind, since it can help to reason about=
=20
your code"

https://stackoverflow.com/questions/14593333/why-noexcept-is-not-enforced-a=
t-compile-time?rq=3D1
Those are some considerations why `noexcept(true)` should not  verify at=20
compile time that it is calling only `noexcept` code, it is surely worth=20
reading, but also shows that it would be nice having `noexcept(strong)`=20
alongside `noexcept(true)`.

Of course those are only opinions, they can be wrong and whatever.
Just because the majority says a thing it does not mean that it's right.
It seems (at least not only to me) that the primary reason for `noexcept`=
=20
to exist is code correctness (like my example with `unique_ptr` or the=20
example with `std::vector` and `push_back`).
The fact that throwing inside `noexcept` (compared to `throw`) is a call to=
=20
`terminate` without stack unwinding is an optimization opportunity, and it=
=20
would be wrong to dismiss it.
Any of the given points does not still narrow `noexcept` for moving and=20
swapping, on the contrary, it shows that `noecept` has a much bigger=20
audience.

I would love to see some resource why we should not use `noexcept` except=
=20
in move or swap and make no attempt to validate such assumptions at compile=
=20
time.=20
The only reason I could imagine is compile time, but I do not think that=20
this would be an issue.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/976d6dae-3462-4e6d-a74a-8a4d996c4aa5%40isocpp.or=
g.

------=_Part_9298_130219351.1526622550741
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">All functions you mentioned (except for the random number =
generation facility that I do not know well enough), can fail (at least con=
ditionally), and this is the main reason for not marking them as noexcept.<=
br><br>&gt; The main reason for std functions that don&#39;t throw, but don=
&#39;t say=20
noexcept, is that we allow implementations to throw on precondition=20
violations.<br>As Tony said, implementations are allowed to throw on precon=
ditions violations (did not think of it. checked iterators is a good exampl=
e, AFAIK iterators are not marked `noexcept`, but they are not required to =
throw either).<br><br>&gt; Look around. How many C++ libraries do you know =
of that practice a <i>strict</i> policy of `noexcept` decorations on everyt=
hing that genuinely doesn&#39;t throw exceptions?<br><br>I guess not many (=
even if I do not know the internals of most libraries) and in my opinion it=
&#39;s because there are not really many static tools for verifying for noe=
xcept-correctness.<br>From a stability point of view, it&#39;s easier to do=
cument a function as non-throwing, and if it throws, it is still a recovera=
ble error for the main application, so not a blocking issue.<br>If it throw=
s and it is marked as `noexcept`, it will terminate, and that&#39;s not exa=
ctly a great feature for a library or a good sign of stability.<br><br>But =
most big libraries I know and have used are also pre c++11 or more c-style.=
... still I would not claim that many tools that came with c++11 should be u=
sed only in certain contexts because they are not widely used.<br>Most youn=
ger libraries I know, use noexcept and not only for moving, and they use it=
 for guaranteeing that something will not fail, instead of writing a separa=
te documentation.<br><br>&gt; With Contracts, our policies may change. (if =
contracts were checked outside the noexcept...)<br>I admit that I did not k=
now that contracts could influence `noexcept`, so I&#39;ll give a look at t=
hat proposal too.<br><br><br>Just for the record, here are some references =
I found when searching on the topic:<br><br>https://stackoverflow.com/quest=
ions/10787766/when-should-i-really-use-noexcept<br>Recommendations are<br>1=
) &quot;[...] use it when it&#39;s obvious that the function will never thr=
ow.&quot;<br>2) &quot;[...] <strong>semantics first</strong> [...] As a pro=
grammer reading code, the presence of <code>noexcept</code> is akin to that=
 of <code>const</code>:
 it helps me better grok what may or may not happen. Therefore, it is=20
worthwhile spending some time thinking about whether or not you know if=20
the function will throw. For reminder, any kind of dynamic memory=20
allocation may throw. [...] now on to the possible optimizations. [...]&quo=
t;<br><br>The consensus seems to be that if a function cannot and should no=
t fail, then it should be marked as noexcept.<br><p><br></p>https://akrzemi=
1.wordpress.com/2014/04/24/noexcept-what-for/<br>1) Makes the standard exam=
ple where `noexcept` is used in order to guarantee that `push_back` has a s=
trong exception guarantee (which has nothing to do with optimizations)<br>2=
) &quot;This is because the information that <code>noexcept</code> really i=
s intended to convey is that the function <strong>never fails</strong>; not=
 that it never throws! [...] This is part of a more general observation, th=
at what we are=20
interested in is really failure safety in program components rather than
 <a href=3D"http://www.boost.org/community/exception_safety.html">exception=
 safety</a>. No matter if you use exceptions, error return values, <code>er=
rno</code>
 or whatever else, the reasoning about basic (no leak, invariant=20
preserved), strong (commit or rollback) and never-fail guarantee should=20
still hold.&quot;<p>3) The last point, &quot;More eager termiation&quot; is=
 particularly interesting, because with what I&#39;m proposing we would be =
able to reduce those runtime errors.</p><p>4) From a comment (I swear it&#3=
9;s not mine) &quot;IMO using noexcept is like using const [...]  Just like=
 we don=E2=80=99t say we should not use const because libraries may=20
=E2=80=98mutable=E2=80=99 themselves out of the const contract, it does equ=
ally not seem
 like a good idea to promote such a thing for what I would like to call=20
noexcept correctness.&quot;<br></p><p><br></p><p>The consensus, again, seem=
s to be that if a function cannot and should not fail, then it should be ma=
rked as noexcept.</p><p><br></p><p>https://google.github.io/styleguide/cppg=
uide.html</p><p>1) &quot;You may use <code>noexcept</code> when it is usefu=
l for
performance if it accurately reflects the intended semantics
of your function, i.e. that if an exception is somehow thrown
from within the function body then it represents a fatal error.&quot;</p><p=
>2) &quot;instead of writing a complicated <code>noexcept</code> clause
that depends on whether a hash function can throw, for example,
simply document that your component doesn=E2=80=99t support hash
functions throwing and make it unconditionally
<code>noexcept</code>.&quot;</p><p><br></p><p>The guideline puts a lot of f=
ocus on performance, and that writing a correct noexcept specifier is hard =
(`noexcept(auto)` would therefore help), and thus use comments (hopefully s=
ome `static_assert` too).<br></p><p><br></p>https://scottmeyers.blogspot.de=
/2014/03/declare-functions-noexcept-whenever.html<br>1) Well the title says=
 all...<br><br>https://arne-mertz.de/2016/01/modern-c-features-keyword-noex=
cept/<br>1) &quot;`noexcept`=C2=A0is worth keeping in mind, since it can he=
lp=C2=A0to reason about your code&quot;<br><br>https://stackoverflow.com/qu=
estions/14593333/why-noexcept-is-not-enforced-at-compile-time?rq=3D1<br>Tho=
se are some considerations why `noexcept(true)` should not=C2=A0 verify at =
compile time that it is calling only `noexcept` code, it is surely worth re=
ading, but also shows that it would be nice having `noexcept(strong)` along=
side `noexcept(true)`.<br><br>Of course those are only opinions, they can b=
e wrong and whatever.<br>Just because the majority says a thing it does not=
 mean that it&#39;s right.<br>It seems (at least not only to me) that the p=
rimary reason for `noexcept` to exist is code correctness (like my example =
with `unique_ptr` or the example with `std::vector` and `push_back`).<br>Th=
e fact that throwing inside `noexcept` (compared to `throw`) is a call to `=
terminate` without stack unwinding is an optimization opportunity, and it w=
ould be wrong to dismiss it.<br>Any of the given points does not still narr=
ow `noexcept` for moving and swapping, on the contrary, it shows that `noec=
ept` has a much bigger audience.<br><br>I would love to see some resource w=
hy we should not use `noexcept` except in move or swap and make no attempt =
to validate such assumptions at compile time. <br>The only reason I could i=
magine is compile time, but I do not think that this would be an issue.<br>=
</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/976d6dae-3462-4e6d-a74a-8a4d996c4aa5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/976d6dae-3462-4e6d-a74a-8a4d996c4aa5=
%40isocpp.org</a>.<br />

------=_Part_9298_130219351.1526622550741--

------=_Part_9297_682859325.1526622550741--

.