On Wed, Oct 12, 2016 at 4:51 PM, John McCall <rjmcc...@apple.com> wrote: > On Oct 12, 2016, at 11:58 AM, Richard Smith <richardsm...@google.com> wrote: >> 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.
But the various vendor-specific attributes don't create a different type, so they shouldn't be represented in RTTI; this definitely seems true of noreturn. Jason _______________________________________________ cxx-abi-dev mailing list cxx-abi-dev@codesourcery.com http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev