Re: Supporting C++17

[Jonathan Wakely <gtkmm kayari org>]

On 4 April 2017 at 23:28, Chris Vine <chris cvine freeserve co uk> wrote:
> On Tue, 4 Apr 2017 23:09:33 +0100
> Jonathan Wakely <gtkmm kayari org> wrote:
> > On 4 April 2017 at 22:56, Chris Vine wrote:
> > > I would check that.  It didn't affect ABI in C++11/14, but I am not
> > > so sure about C++17.  According to
> > > http://en.cppreference.com/w/cpp/language/noexcept_spec,
> > > in C++17 "The noexcept-specification is a part of the function type
> > > and may appear as part of any function declarator."  If it is part
> > > of the type then it might feature in name mangling, so this is
> > > worth checking with the compiler writers.
> >
> > In C++17 the exception spec is part of the type, so noexcept(true)
> > functions are mangled differently from functions that are
> > noexcept(false).
>
> As I said in my follow-up email, on reflection I agree with you about
> noexcept(false).
>
> But if this is correct about noexcept(true), and I am now beginning to
> doubt myself on this, then it seems a recipe for broken libraries.  It
> makes any code with a noexcept(true) function specification which has
> been compiled with the -std=c++14 option ABI incompatible with the same
> code compiled with the -std=c++17 option.

Not any code, only code that depends on the type of function pointers
in mangled names. The mangled names of the functions themselves don't
change, only names that depend on them.

Using https://godbolt.org/g/akduU4 again, foo anr bar do not change
their mangled names. But f2, which depends on decltype(&bar), does
change.

However, it's uncommon to actually use decltype(&bar) like that in a
function signature. Far more common would be something like:

using func_type = void(*)();
void f2(func_type);

And this wouldn't change, because func_type doesn't include the
exception specification (because it wasn't allowed to in C++14).

There's an implicit conversion from R(*)(Args...) noexcept to
R(*)(Args...) so calling f2(&bar) would still work whether it's
declared to take void(*)() or void(*)()noexcept.

Some code may well be affected, and we don't know exactly how much,
but it's not as catastrophic as you suggest. It's a good reason not to
require C++17 for glibmm yet though :-)



> What benefit accrues from making the noexcept specification part of
> the type which is worth all that ABI breakage?

See my previous email.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html
also gives some (terse) rationale.