when move operations are specified with conditional noexcept this rule triggers. Since such conditions often are quite complex traits with nested noexcept operations the checker looks ugly
if a conditional noexcept is encountered that is not noexcept(false) the checker should be silenceable by configuration, so still blame when there is no noexcept after a move operation, but not blaming in cases above without adding an attribute (which does not change code correctly at the moment anyway).
Needs to be discussed, may be an attribute is what we want here.
Expected Behavior
when move operations are specified with conditional noexcept this rule triggers. Since such conditions often are quite complex traits with nested noexcept operations the checker looks ugly
e.g:
Actual Behavior
if a conditional noexcept is encountered that is not noexcept(false) the checker should be silenceable by configuration, so still blame when there is no noexcept after a move operation, but not blaming in cases above without adding an attribute (which does not change code correctly at the moment anyway).
Needs to be discussed, may be an attribute is what we want here.
Cevelop Version, Operating System and Compiler
current