> On Oct 11, 2016, at 5:11 PM, Richard Smith <[email protected]> wrote:
> 
> Under
>   http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0012r1.html 
> <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
>   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?


That seems reasonable to me.  I don’t think we need to optimize the “throw (a, 
b, c)” case: It’s deprecated anyway, and having all the types makes for nicer 
demangling.

        Daveed


_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev

Reply via email to