[meta] Clarify what happens when `std::meta::members_of` is unable to form a `std::vector`

[eisenwave]

It is plausible that the global namespace is gunked up with several thousand declarations after including various C headers, to a point where std::meta::members_of(^^::) would be unable to form a std::vector that holds the reflections. For example, when targeting a 16-bit architecture, the max_size() of a std::vector may be relatively low, such as ~32K, but the compiler (especially when cross-compiling) could be capable of storing that many declarations internally.

A note may be helpful guidance to implementations in this case. Notably, it would be valid to refuse translation due to implementation limits being exceeded, but it wouldn't be valid to throw std::bad_alloc and let the user handle it.

[frederick-vs-ja]

Notably, it would be valid to refuse translation due to implementation limits being exceeded, but it wouldn't be valid to throw std::bad_alloc and let the user handle it.

Hmm, I guess the current wording suggests that there can only be allocation failure in the overflowing max_size() case. So it seems that only throwing bad_alloc or bad_new_array_length would be allowed, and an LWG issue seems necessary for changing this.

Or alternatively, do we want to constrain translation limits so that such a huge program will be rejected even without using std::meta::members_of?

[eisenwave]

I don't see anything that suggests that an exception would be thrown in this case. I've had a conversation with some people in LWG and they appear convinced that members_of being unable to form a std::vector is an instance of exceeding implementation limits, so it would need to kill translation.

members_of isn't stated to gradually fill a std::vector using push_back or anything like that; it simply conjures it out of thin air. It's not clear how it allocates memory for the std::vector.

[frederick-vs-ja]

Would it be wanted to add some kind of Constant When to all consteval functions returning vector<info>?