=== on 22 Jun 2016, 08:23:53 Ann Campbell wrote:
FYI [~alban.auzeill], we're not citing the Core Guidelines (yet) in the See sections because we're not sure how stable the naming/numbering will be.

=== on 6 Nov 2018, 19:44:21 Ann Campbell wrote:
\[~loic.joly] this is confusing:


____
This rule raises an issue when a destructor is not specified to be noexcept. Note that most of the time, nothing needs to be written in the source code, because destructors are, by default, noexcept if their data members allow it.
____


It raises a rule when ``++noexcept++`` isn't used, but you don't need to use ``++noexcept++`` because that's the default...?

=== on 7 Nov 2018, 08:55:00 Loïc Joly wrote:
\[~ann.campbell.2]

There is a distinction between being noexcept (a property of a function) and using the ``++noexcept++`` keyword to coerce the noexcept status. Here, the destructor needs to be noexcept, we don't directly care about the keyword (this is a change in behaviour from the previous implementation).


By default a destructor is noexcept. There are two ways for it not to be noexcept:

* It is decorated with the ``++noexcept++`` keyword followed by something that evaluates to false
* Some data member/base class prevent it from being noexcept (which means there is a violation of this rule on another class)

Maybe remving the word "specified" in the quoted sentence would make it clearer?


You may also see the full decision graph in CPP-2026

=== on 7 Nov 2018, 20:25:42 Ann Campbell wrote:
\[~loic.joly] I think I've just realized that a couple cases aren't covered in the "raises an issue" clause. 


I counter-propose:

____
This rule raises an issue when 

* a destructor's default ``++noexcept++`` behavior is overridden
* a destructor throws an exception
* a destructor allows an exception to be thrown from one of its calls
____

Because once you introduce an explicit  "raises an issue" clause, you need to cover all the cases.

=== on 8 Nov 2018, 09:24:24 Loïc Joly wrote:
\[~ann.campbell.2] Only the first bullet of your list is (partially) covered. So I prefer to keep "when a destructor is not ``++noexcept++``".

It would be nice to detect that a destructor throws (directly or indirectly) an exception, but :

* This would be very hard to do correctly, and we are not doing it in this case
* This belongs, I believe, to a more generic, yet to be written, rule: ``++noexcept++`` functions should not throw. 


=== on 8 Nov 2018, 17:48:45 Loïc Joly wrote:
\[~ann.campbell.2] I applied the change we talked about. Can you please review?

=== on 8 Nov 2018, 19:33:31 Ann Campbell wrote:
\[~loic.joly] I've edited the first bullet in the 'raises issues' clause. Please double-check me. Assuming it's okay, this is good to go!

