[cxx-abi-dev] manglings for exception specifications in function types

[Richard Smith]

On 2 November 2016 at 11:13, Jason Merrill <jason at redhat.com> wrote:

> On Sun, Oct 23, 2016 at 1:10 AM, Richard Smith <richardsmith at google.com>
> wrote:
> > On 11 October 2016 at 14:11, Richard Smith <richardsmith at google.com>
> wrote:
> >>
> >> Under
> >>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html
> >>
> >> the noexceptness of a function type is now part of the type. As a
> result,
> >> we need manglings for exception-specifications on function
> pointer/reference
> >> types:
> >>
> >> void f(void()) {}
> >> void f(void() noexcept) {} // ok, overload not redefinition
> >>
> >> (It's not clear to me whether or not this was also necessary prior to
> >> C++17 to handle dependent exception specifications that appear lexically
> >> within the parameter list of a function template, and actual
> implementation
> >> practice varies as to whether such exception specifications are
> SFINAEable.)
> >>
> >> In order to handle overloading/SFINAE on exception specifications in
> >> dependent cases, we need to be able to mangle not only "noexcept", but
> also
> >> "noexcept(expression)" and "throw(<types>)". Suggestion for manglings:
> >>
> >> <exception-spec> ::=
> >>   nx  -- non-throwing exception specification
> >>   nX <expression> E  -- computed (value-dependent) noexcept
> >
> > Minor correction: this should be mangled if instantiation-dependent, not
> > only if value-dependent. It appears that SFINAE can happen here.
> >
> >>   tw <type>* E  -- throw (types)
> >> <function-type> ::= [<CV-qualifiers>] [<exception-spec>] [Dx] F [Y]
> >> <bare-function-type> [<ref-qualifier>] E
> >>
> >> In the case of throw(a, b, c), we could omit types that are neither
> >> instantiation-dependent nor pack expansions (if that omits all types,
> we can
> >> use the 'nx' mangling instead), since C++17 says you can't overload on
> the
> >> actual types in the dynamic exception specification, and we otherwise
> only
> >> need them to be present if they might result in a substitution failure.
> >>
> >> Thoughts?
>
> I'm uncomfortable with adding new mangling for the intersection of a
> new C++17 feature and a deprecated feature that just barely missed
> being removed from C++17 (though we'll see what happens next week),
> especially since you can't overload on it,


Why not? [temp.over.link]/4 doesn't have any special case for exception
specifications, so as far as I can see, this is valid:

// If T has a nested type 'exception', the function might throw it.
template<typename T> void f(void p() throw(typename T::exception)) { try {
p(); } catch (...) { /*...*/ } }
// Otherwise we can assume it doesn't throw anything.
template<typename T> void f(void p() noexcept) { p(); }

... and will do SFINAE on the existence of a nested type 'exception' within
T.


> and before C++17 putting an
> exception specification on a nested function type was ill-formed; we
> can just restore that prohibition for dynamic exception specs if they
> stay in the language.
>
> Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20161102/0b92d9a2/attachment.html>