On 3/6/24 3:07 AM, Frederick Virchanza Gotham via Std-Proposals wrote:
> On Fri, Mar 1, 2024 at 12:18 PM Frederick Virchanza Gotham wrote:
>> We should have access to the 'type_info' of any object that is thrown,
>> even if it is caught inside a 'catch(...)' block.
>
> I've made a few cosmetic changes to the paper and I think it's ready
> now, see here:
>
> http://www.virjacode.com/papers/typeid_except.htm
>
> I've also attached it to this email.
>
> In 48 hours' time, I will email the paper to the vice-chair Nevin
> Liber to obtain a document number.
>
> So lastly, can I get suggestions from people on what this new function
> should be called? Presently it's called 'typeid_except', and I called
> it this because I wanted it to resemble the 'typeid' operator. I was
> reluctant to have 'exception' in the name as I don't want any
> confusion about whether it has anything to do with the class named
> "std::exception". A few other possible names:
>
> typeidex
> typeid_ex
> typeid_exception
> typeid_of_exception
> typeid_from_exception
> exception_typeid
> exception_typeinfo
> get_typeinfo_of_exception
> get_typeinfo_from_exception

For the form that returns a std::type_info reference for the currently
handled exception, I prefer current_exception_typeid() for consistency
with current_exception() and the typeid operator (assuming this form is
needed at all).

For the form that returns a std::type_info reference from a
std::exception_ptr /E/, I prefer the addition of a type_info() member
function to enable /E/.type_info() assuming that this is implementable
on all platforms without an ABI break ([propagation]p6
<http://eel.is/c++draft/propagation#6> contains a note that states "An
implementation can use a reference-counted smart pointer as
exception_ptr" which suggests to me that a generic smart pointer can be
used subject to the implicit conversion limitations). If that isn't an
option for some implementations, then I prefer get_exception_type_info()
for consistency with rethrow_exception().

If the latter form is provided, then I don't see a need for the former
form. I don't see compelling motivation to be able to query the type in
the forced unwinding scenario in which current_exception() returns a
null std::exception_ptr.

Tom.