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

[Jason Merrill]

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, 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