I think it would be helpful to update the design consideration section of your paper, or perhaps add a design alternatives section, that details some of the alternate design options and provides the rationale for your preferred solution.

On Wednesday, March 6, 2024, Tom Honermann wrote:

On 3/6/24 3:07 AM, Frederick Virchanza Gotham wrote:

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).

I don't agree with you here however it would be a small compromise to make, if more people would prefer 'current_exception_typeid'. I'm not gonna get caught up on what English words we use -- so long as we can use the feature.

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 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).

Yeah I think it might be an idea to add a few non-static non-virtual methods to 'exception_ptr', such as to get the 'type_info', or to get a pointer to the bytes of the exception object.

For the time being though, I want to keep this proposal very simple. It won't be the end of the world if we end up with a little redundancy in C++29 whereby we have a choice of using either 'std::typeid_except' or 'std::exception_ptr::type'.

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.

I want to be comprehensive here and cover all bases. The last thing I want is to receive an email in 2031 from some guy writing a compiler for an Arduino microcontroller asking me why I didn't push harder for the parameterless version. But even today in 2024, we have scenarios where 'current_exception()' returns a nullptr even though there is 'type_info' available. If a person is logging every exception that is thrown, i.e. logging the 'type_info' and also possibly the 'what()' of what was thrown, then maybe they also want to log forced unwinds too, and to have something descriptive like "abi::__forced_unwind" instead of just 'typeid(void)'.

I think we really should have a parameterless version of the function. Personally I would give both functions the same name, but if others want to give them different names then I'm easy.