Date: Fri, 1 Mar 2024 13:50:41 +0100
I generally support the idea, but the specifics need to be discussed
more. Implementation experience is missing from this proposal
entirely, and that's a very important section to have in any C++
proposal.
It's also unclear why you would return "typeid(void)" when given a
null pointer as an input. Shouldn't that throw an exception or be
undefined behavior?
Furthermore, wouldn't it make more sense to specify exception_ptr in
more detail? Perhaps we could get away with specifying it as a class
type that has a "type_info()" member function. That seems more
reasonable than a separate free function, if this mechanic is 100%
tied to exception_ptr anyway.
Personally, I dislike the name "typeid_except". It's not obvious what
it does and you use it so rarely that abbreviating the name is
pointless. Perhaps "exception_typeid()" would be better.
more. Implementation experience is missing from this proposal
entirely, and that's a very important section to have in any C++
proposal.
It's also unclear why you would return "typeid(void)" when given a
null pointer as an input. Shouldn't that throw an exception or be
undefined behavior?
Furthermore, wouldn't it make more sense to specify exception_ptr in
more detail? Perhaps we could get away with specifying it as a class
type that has a "type_info()" member function. That seems more
reasonable than a separate free function, if this mechanic is 100%
tied to exception_ptr anyway.
Personally, I dislike the name "typeid_except". It's not obvious what
it does and you use it so rarely that abbreviating the name is
pointless. Perhaps "exception_typeid()" would be better.
Received on 2024-03-01 12:50:54