Review in LEWG will address all of these options.

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.

Tom.

On 3/6/24 1:18 PM, Frederick Virchanza Gotham via Std-Proposals wrote:
>
> 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 <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).
>
>
>
> 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.
>