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

[David Vandevoorde]

> On Oct 12, 2016, at 4:51 PM, John McCall <rjmccall at apple.com> wrote:
[…]
> I'll admit that I don't attend committee meetings, but I thought that implementation experience was expected *prior* to standardization, not something that gets done months after voting the thing in concurrently with the committee finalizing the language in a draft for next year's release.

That’s cute ;-)

> 
>>> You will note that I have omitted the necessary specializations for "transaction_safe", as well as the incredibly common extension of specialized calling conventions.
>>> 
>>> This also breaks source compatibility for template matching, and basically every function template in the standard library is going to change manglings (and become *much* larger) due to noexcept expressions now being mangled.
>>> 
>>> It's a problem, but I don't think it's as bad as you claim. The mangling of a function still wouldn't include its exception specification; this would only affect mangling in cases where a parameter or return type or template argument involves a function type with an exception-specification -- a lot less common than every function template in the standard library, but this still does change manglings for existing code.
>> 
>> Okay, so it only triggers SFINAE failures in nested function types, and you can't overload templates by it?  I agree that that helps a lot.
>>> And the entire proposal seems to have forgotten about reference-to-function types.
>>> 
>>> The change to [dcl.init.ref]p4 allows a reference to non-noexcept function to bind to a noexcept function, and this indirectly allows the same during overload resolution, casts, and so on. What additional considerations were missed?
>> 
>> I hadn't realized that the expression logic was so consistent about defining e.g. the behavior of the conditional operator on l-values in terms of reference binding.  I apologize.
>> 
>> ...I see that this adds a new special case to exception handling.
>> 
>> Yes; I'd forgotten to mention this side of the ABI change.
>> 
>> We'll also need a new flag on type_info objects to model this. In line with the transaction_safe changes that Jason proposed, I suggest adding a __noexcept_mask = 0x40 to __pbase_type_info, and representing a pointer to noexcept function as a pointer with __noexcept_mask bit set to the corresponding *non-noexcept* function pointer type.
> 
> I strongly disagree; we should take this opportunity to revisit that decision.  The floodgates are open, and this set of function type attributes is clearly going to grow over time.  (It's actually transaction_safe that really drives this point home; noexcept is at least a longstanding part of the core language in various forms.)  We also have a lot of vendor-specific function type attributes that are part of the type but just aren't standardized and can't be represented in type_info.  I don't think it makes sense to indefinitely keep hacking these things into the pointer type flags; we should just bite the bullet and create a new function_type_info subclass.

I agree with you (John).

(That said, I’ll keep resisting adding standard bifurcations to function types. “contracts” and one alternative for coroutines are currently trying to add to that list.)

	Daveed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20161012/ddfef818/attachment-0001.html>