On 2 Nov 2016 12:40 pm, "Jason Merrill" <[email protected]> wrote:
On Wed, Nov 2, 2016 at 2:19 PM, Richard Smith <[email protected]> wrote: > On 2 November 2016 at 11:13, Jason Merrill <[email protected]> wrote: >> >> 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, > > 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. I suppose so, sigh. I notice that with this specification, void f (void (*p)() noexcept) { } would mangle as _Z1fPnxFvvE which currently means f(__int128*, long long, void ()) which is ill-formed, but I'd rather not require the demangler to recognize that. Yeah, that's no good :( Demangler heroics don't even save this; X<void() noexcept> would mangle the same as X<__int128, long long, void()>. Maybe Do, DO and Dw instead? Works for me. Jason
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
