Repository navigation
CWG3202 [basic.fundamental] const std::meta::info is not a reflection #924
Description
Section: [basic.fundamental]
Issue description
Consider the following example:
constexpr std::meta::info x{};By definition in [basic.fundamental] p17, a value of type std::meta::info (but not of type const std::meta::info) is a reflection. Since a value of type const std::meta::type is not a reflection, it is unclear how x is meant to represent a null reflection. What is the value of x?
Proposed resolution
Change [basic.fundamental] paragraph 17 as follows:
A value of type
+cv
std::meta::info is called a reflection.
There exists a unique null reflection;
every other reflection is a representation of
- ...
Activity
safocl commentedon Jun 18, 2026
I think that since this exists exclusively at the compilation stage, such a question does not make sense.
and:
safocl commentedon Jun 18, 2026
Many other entries in [basic.fundamental] do not specify cv -- does this mean, in your opinion, that const variants are not declared types and their values, and that they must have some other representation than non-const ?
eisenwave commentedon Jun 18, 2026
We're very careful to include cv in various places in [basic.fundamental] and to include cv-qualified types in certain categories, like including cv-qualified versions of
intin the category of "integral types".Since
const Tis a distinct type fromT, some care must be put into making the wording work, and we simply got it wrong forstd::meta::infoin this place.safocl commentedon Jun 18, 2026
That is, you are now assuming that the formulation allows for the absence of guaranteed equality in values for const and non-const std::meta::info objects?
In this case, wouldn't it be necessary to additionally supplement the provision [expr.eq#6] with the appropriate amendments?
safocl commentedon Jun 18, 2026
Wouldn't it be better then to introduce a general rule for fundamental types, that all provisions also imply cv-qualified entities?
eisenwave commentedon Jun 18, 2026
No, because [expr.eq] paragraph 1 states that the lvalue-to-rvalue conversions is applied to operands, which gets rid of these annoying cv qualifications.
I don't know what you mean by that specifically. A lot of things would break if we automatically included cv-qualified types in the category of signed and unsigned integer types for example, and you definitely need to distinguish cv-qualified fundamental types from cv-unqualified types in various places.
safocl commentedon Jun 18, 2026
Doesn't your own words imply that the
xobject will contain an equivalent value as a non-const object with the same initializer? In that case, I simply don't see any reason for such a question to exist.eisenwave commentedon Jun 18, 2026
Just because equality comparison gets rid of cv qualifiers doesn't fix the problem generally.
If the const object is not a reflection, it's also unclear how lvalue-to-rvalue conversion is supposed to work. Random garbage goes in, reflection comes out, and it's not specified how.
safocl commentedon Jun 18, 2026
Here, in my opinion, we're stuck in an infinite recursion loop with my post (#924 (comment)).
eisenwave commentedon Jun 18, 2026
Hmm, upon reading a bit further, there is a more fundamental and less obvious question here. Are values ever cv-qualified? What's our model here actually?
Does a
const int x = 0;object store the value "const zero" or just "zero"? It seems like [conv.lval] asssumes that values are never cv-qualified because https://eel.is/c++draft/conv.lval#3.5 doesn't describe any conversion mechanism from a cv-qualified value to the cv-unqualified value.So perhaps this issue really is NAD if a
const std::meta::infoobject is considered to hold a value of (cv-unqualified)std::meta::info, but do we actually make it clear that values have no cv-qualifications even if stored in const objects?https://eel.is/c++draft/basic.types.general#def:value isn't clear at all about what our model is. A "value" is simply determined by the bits of the value representation, which very well could mean that
const int x = 0;has a value representation determining the value "const zero", andint x = 0has a value representation determining the value "zero".I feel like the model of cv-unqualified values makes more sense, but perhaps we should clarify that this is our model by adding something to the definition of values.
frederick-vs-ja commentedon Jun 22, 2026
I feel like that the word "value" used here means some "pure value" that's not associated with certain objects. It might be possible to refer such a value as "prvalue" which automatically has cv-qualification dropped.
katzdm commentedon Jun 22, 2026
I think my understanding is that the values of "cv
T" are those ofTifTis scalar, and are distinct ifTis a class type. That said, I can't remember whether that idea stems from wording or from "CWG folklore".jensmaurer commentedon Jun 22, 2026
CWG3202
[-][basic.fundamental] `const std::meta::info` is not a reflection[/-][+]CWG3202 [basic.fundamental] `const std::meta::info` is not a reflection[/+]