This simple C++ example generates a warning with gcc 7.1.1: template<class Func> void call (Func f) { f (); } void func () noexcept { } int main () { call (func); return 0; } $ g++ -std=c++11 -Wall -c test.cc test.cc:2:6: warning: mangled name for ‘void call(Func) [with Func = void (*)() noexcept]’ will change in C++17 because the exception specification is part of a function type [-Wnoexcept-type] void call (Func f) ^~~~ IMHO this warning is a false positive. The mangled name of call() doesn't matter because it is a template function which is called from the same compilation unit in which it is defined, and it will almost certainly be inlined. Please consider refining the triggers for -Wnoexcept-type so that it does not produce a warning in a case like this one. gcc-multilib 7.1.1-3 (Arch Linux) $ gcc --version gcc (GCC) 7.1.1 20170528
Consider: template<class Func> int call (Func f) { static int counter; f (); return ++counter; } void func () noexcept { } Now if call(func) is evaluated in two different translation units, one using C++14 and one using C++17, you get two different counters. The fact it's a function template doesn't mean there's no consequence of the change, and whether it's inlined is irrelevant. Maybe if the function is known to be pure and is there's no explicitly instantiation declaration or definition the warning would be redundant.
(In reply to Jonathan Wakely from comment #1) > template<class Func> > int call (Func f) > { > static int counter; > f (); > return ++counter; > } Yes, this is a different example in which the warning does matter. > Maybe if the function is known to be pure and is there's no explicitly > instantiation declaration or definition the warning would be redundant. Something along those lines, yes. As I said, I'm only asking that the warning be refined so it produces less false positives. Or could you consider not including this warning in -Wall? I want to use -Wall to display only warnings that (1) likely indicate buggy code and (2) can be silenced by fixing the code. The code in my example is quite correct and there is no obvious way to "fix" it except to avoid using major features of the C++ language.
Question: what am I supposed to do about this warning? Using John's example as-is... what does John do to "satisfy" the warning? I just ran into this writing a test suite for a library when I added gcc7 compiling in c++14 mode and I'm not sure that there's anything for me to do besides -Wno-noexcept-type (https://stackoverflow.com/q/46798456/2069064)