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

Reply via email to