Date: Tue, 09 Apr 2024 21:12:05 -0700
On Tuesday 9 April 2024 00:05:25 PDT Frederick Virchanza Gotham via Std-
Proposals wrote:
> I'm suggesting two things:
>
> (1) Extend the original std::type_info as much as we can without
> causing an ABI break (i.e. use the common subset of information that
> is already there on Itanium ABI and Microsoft ABI)
> (2) Consider making a new type, std::type_info_extended, and a new
> function, std::get_type_info_extended, with all the extra stuff we
> want
We're still missing the motivation. Why have this information?
It's good to have an exploration of what could be added if we decide we have a
need, but nothing is going to get added *until* there's a need.
Specifically for #2, because it won't apply to polymorphic types already
compiled, you need a very strong motivation to justify having inconsistent
behaviour in real life (not in the standard).
Proposals wrote:
> I'm suggesting two things:
>
> (1) Extend the original std::type_info as much as we can without
> causing an ABI break (i.e. use the common subset of information that
> is already there on Itanium ABI and Microsoft ABI)
> (2) Consider making a new type, std::type_info_extended, and a new
> function, std::get_type_info_extended, with all the extra stuff we
> want
We're still missing the motivation. Why have this information?
It's good to have an exploration of what could be added if we decide we have a
need, but nothing is going to get added *until* there's a need.
Specifically for #2, because it won't apply to polymorphic types already
compiled, you need a very strong motivation to justify having inconsistent
behaviour in real life (not in the standard).
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel DCAI Cloud Engineering
Received on 2024-04-10 04:12:23