https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124447
--- Comment #11 from Aakash Gupta <uchanahome8 at gmail dot com> --- > Using reflection on anything inside namespace std is supposed to be > unspecified As per https://isocpp.org/files/papers/P2996R13.html#namespace.std-namespace-std: ``` 6a Let F denote a standard library function or function template. Unless F is designated an addressable function, it is unspecified if or how a reflection value designating the associated entity can be formed. [ Note 1: For example, it is possible that std::meta::members_of will not return reflections of standard library functions that an implementation handles through an extra-linguistic mechanism. — end note ] 6b Let C denote a standard library class or class template specialization. It is unspecified if or how a reflection value can be formed to any private member of C, or what the names of such members may be. ``` Assuming `std::int64_t` (or other equivalent structs) falls under 6b, I am not sure if this makes using `^^std::int64_t` unspecified? From the paper itself: https://isocpp.org/files/papers/P2996R13.html#struct-to-struct-of-arrays, this will make using `^^std::array` unspecified behavior. > I don't think we want to change anything in namespace std just because > reflection allows you to observe implementation details. I raised the bug because I am able to use `^^std::string`, but not `^^std::int64_t`, given `std::int..` typedefs are used extensively by C++ users. I feel this case was missed during reflection paper discussions, which seems very low probable to me in first place. > because programs should be relying on ::int64_t being defined any particular > way. Now that I think about it, this is a fair point. > Basically, reflecting things from the standard library is not a good idea. I get why this is not a good idea, as this exposes internal implementation details. It's just bizarre that I am not able to use `^^std::int64_t` for simple use case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124447#c3. Given that https://eel.is/c++draft/expr.reflect#5.1 disallows this, I think the bug can be closed now.
