On Sun, Oct 23, 2016 at 1:10 AM, Richard Smith <[email protected]> wrote: > On 11 October 2016 at 14:11, Richard Smith <[email protected]> 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, 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 _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
