There are intrinsic costs for each change of the standard. Another possible feature is delayed or skipped for each included one.   The compilers have to compile dependent on the standard version set on command line.   Lots of C++ users have to read and learn the changed features and look through their code and test for breakages.   Some library developers have to work around differences between versions of the standard.   No real (non-lectoral) change is simply pasting two snippets. That and the discussion here actually is the least of the effort.   The reasons you give show that that change probably has a lower bar for the motivation than lots of other proposals, nevertheless it should have one.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 09.01.2023 23:43 Betreff:Re: [std-proposals] RTTI in current_exception An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Mon, Jan 9, 2023 at 4:39 PM Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote: > > A good proposal needs to start with motivation. The conversation we're having right now takes more time and effort than copy-pasting the following paragraph into Section 17.9.6 of C++26: [ - - START COPY-PASTE - - ] std::type_info const &current_exception_typeid(void) noexcept; Returns: A reference to a 'type_info' object that refers to the currently handled exception (14.4), or simply 'typeid(void)' (7.6.1.7) if no exception is being handled. The return values of two successive calls to 'current_exception_typeid' refer to the same 'type_info' object. [ - - END COPY-PASTE - - ] Furthermore, compiler vendors haven't got much work to do. The GNU guys can copy-paste the following snippet into their text file named 'exception':    inline type_info const &current_exception_typeid(void) noexcept    {        type_info const *const p = abi::__cxa_current_exception_type();        if ( p ) return *p;        return typeid(void);    } And here it is for Microsoft:  inline type_info const &current_exception_typeid(void) noexcept  {        _ThrowInfo const *const p1 = static_cast<_ThrowInfo const*>(             static_cast<void const*>(             ExceptionPointers->ExceptionRecord->ExceptionInformation[2u]));        if ( nullptr == p1 ) return typeid(void);        type_info const *const p2 =                p1->pCatchableTypeArray->arrayOfCatchableTypes[0u];        if ( nullptr == p2 ) return typeid(void);        return *p2; } One does not need to be greatly motivated if one does not need to expend much effort. I mean the above 40 lines are everything everyone needs. > something that the current language cannot do, as well as explain why > it is important to be able to do that thing. Either C++26 should deprecate the throwing of objects not derived from 'std::exception', or it should provide a means of getting the RTTI inside 'catch(...)'. One or the other. It doesn't make sense to do neither. > Your proposal does not. It says what you can't do, but it never says > why doing that would be useful. It merely assumes that everyone agrees > that we ought to be able to do that. I think community consensus is enough given how easy it is to copy-paste the aforementioned paragraph into section 17.9.6 of the Standard. If it meant rewriting entire pages of the Standard and getting compiler vendors to spend four months implementing a new feature, then yeah fair enough I'd say that mere group consensus isn't enough. But for this particular feature, I think it's enough for us to be thinking "We ought to have this". > Is this for printing out some debugging information? Are you going to > start comparing it to other `type_info`s and doing a bunch of casting > to figure out what it could be (which would be exceedingly pointless)? > What is the point of getting this information if there's nothing you > can really do about it? Personally I never throw anything that doesn't inherit from std::exception, so this isn't really for me. But I have to interact with shared libraries provided by other people though, and that's why I want the Committee to choose one of the following for C++26: Choice 1: Deprecate the throwing of non-std::exception's. Choice 2: Provide RTTI inside catch(...) And yeah I'd probably print debugging information if an unhandled exception propagated all the way up to a 'catch(...)' body inside 'main', or perhaps send some error info out over a HTTP socket I have going. > As for your suggestion that we shouldn't be able to throw anything > that isn't derived from `std::exception`, again I ask: why? What would > that do which you can't do otherwise? The only functionality of > `std::exception` is that it carries a message via a `char const*`. But > even that could just be an empty string, so you are guaranteed > precisely *nothing*. std::exception has a virtual destructor, which means that it's a polymorphic type, which means that when you apply 'typeid' to it, you don't get the type_info for std::exception but rather you get the type_info for what was thrown -- which is *exactly* what I'm looking for. -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals