On Saturday, 23 September 2023 16:22:59 PDT Jason McKesson via Std-Proposals
wrote:
> `typeinfo`s are only generated if you statically do something that
> *requires* such a type to exist. Like calling `typeid` on it, or maybe
> using `dynamic_cast`. If your program never uses `typeid` on those
> types, then `typeinfo` objects won't exist for them.

That's true, but not a complete information.

The vast majority of typeinfo in C++ OOP codebases are generated because of
polymorphic classes, because the vtable has a pointer to the typeinfo. You can
suppress that with -fno-rtti with GCC & Clang, but disabling RTTI is quite
rare, much rarer than disabling exceptions.

> But the compiler does not, and *cannot*, know what exception types get
> bubbled through a particular function. Therefore, in order for your
> feature suggestion to work, it would have to use every single type.

Obviously that's impossible.

Frederick is suggesting that it suffices to have all the types that are known to
the compiler up until this point, because if the type hadn't been known, the
developer couldn't have meant to catch them. I submit that this is a dangerous
assumption, just in itself. It can also make itself known by having the
#include hierarchy change and certain types disappear from visibility after an
upgrade to some dependency, causing code that did catch a certain exception to
stop catching it.

I also submit you *must* know what types you're meant to catch, as a matter of
design of exception-using code. If you don't know what your called function
may throw, you've done something wrong. If you don't know what your function
may throw, you've designed a bad API.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DCAI Cloud Engineering