CWG3150 [basic.types.general] consteval-only types vs. incomplete class types

[jakubjelinek]

Full name of submitter (unless configured in github; will be published with the issue): Jakub Jelinek

Reference (section label): [basic.types.general]/12, [expr.const]

Link to reflector thread (if any):

Issue description:
Most of the places in the standard which refer to consteval-only types mention it as if it was a property of a type unchangeable during the whole translation unit, if something is of consteval-only type, then this or that.
As the definition of consteval-only type includes pointers/references to those, I'm afraid what is or isn't a consteval-only type can change during the parsing of a translation unit.

struct A;                                                                                                                                                                             
struct B { A *p; constexpr B (A *x) : p (x) {} };                                                                                                                                     
struct A { decltype (^^::) a = ^^::; };

In between the struct B and struct A definition, B is not consteval-only type but after it it is consteval-only. If there is a variable definition with B type,shall it be treated as a variable with consteval-only type or not? If there is an immediate-escalating with a non-constexpr B variable inside of its body, shall it be escalared to immediate function?
Shouldn't the standard talk about consteval-only type at point P to make it clear what exactly it means?
Either some of the decisions on whether something has consteval-only type need to be deferred until the end of a translation unit (but say std::meta::is_consteval_only_type metafn/std::is_consteval_only need to be evaluated at the point of use, or whether something has consteval-only type needs to be remembered (say for a variable on its definition) and not changed afterwards even if a type later on becomes consteval-only. Or the definition of consteval-only type should be changed, so that for a class definition (or template instantiation point) whether any non-static data members had consteval-only type or not matters at the point of that definition/instantiation and doesn't change later on. So, for class types the implementations would then remember whether it is a consteval-only type or not and that wouldn't change later on. Even in that case

struct A;
A *p;
struct A { decltype (^^::) a = ^^::; };

whether some pointer/function type could change later on.

[jakubjelinek]

@katzdm

[frederick-vs-ja]

Do we also want/need to specify that properties in [class.prop] and the literalness ([basic.types.general] p10) of a class is determined at given points?

[katzdm]

This is a good point, and it raises a good question as to whether pointers and references to consteval-only types should be ipso facto consteval-only.

Suppose that they aren't - The following becomes possible:

constexpr std::meta::info R = ^^int;
std::meta::info &Ref = R;

That's not (necessarily) a problem: The problem (I think) comes when an lvalue-to-rvalue conversion is applied to Ref:

bool b = (Ref == std::meta::info{});

But the lvalue-to-rvalue conversion is of consteval-only type, and therefore immediate-escalates ([expr.const]/24.3) - so such things, unless in a (possibly escalated) immediate function context, remain ill-formed.

My initial feeling is that this seems promising, but I need to give it more thought. It would also be nice if we could strike the [expr.const]/21 "aliasing" rules pertaining to consteval-only types, but I'm not sure yet.

The goal remains to keep these things from leaking to runtime. Would welcome others' thoughts here, too.

[jakubjelinek]

References are less of a problem, struct S; S &s = whatever; is invalid, it needs complete type. But pointers and function types can refer to incomplete types which are completed later at will.

[lprv]

In principle, as long as operations on std::meta::info remain immediate-escalating, I don't see why having the "variables of consteval-only type must be constexpr" rule (or the notion of "consteval-only types" in general) is necessary at all. What exactly would go wrong if an implementation had to emit a std::meta::info object to runtime, considering that its value is unobservable outside of constant evaluation?

---

References are less of a problem, struct S; S &s = whatever; is invalid, it needs complete type.

That's not true - extern struct S &x, &y = x; is valid code.

[jensmaurer]

CWG3150

[t3nsor]

In principle, as long as operations on std::meta::info remain immediate-escalating, I don't see why having the "variables of consteval-only type must be constexpr" rule (or the notion of "consteval-only types" in general) is necessary at all. What exactly would go wrong if an implementation had to emit a std::meta::info object to runtime, considering that its value is unobservable outside of constant evaluation?

I guess the motivation is probably to ensure that reflection is zero-cost at runtime, and a nice additional feature is that you can't inspect the object representation of a meta::info (but that seems much less important).

[lprv]

I guess the motivation is probably to ensure that reflection is zero-cost at runtime, and a nice additional feature is that you can't inspect the object representation of a meta::info (but that seems much less important).

Well, to me at least, the first part doesn't seem terribly important either, considering that:

• the users would typically have to go out of their way to leak these objects to runtime,
• there is no apparent technical reason why the standard must prevent them from doing so, and
• imposing this restriction anyway has a high cost in specification complexity.

Consider that any resolution to this issue that aims to preserve these rules would also have to handle cases like this:

// TU 1
struct S { std::meta::info x; };
extern constexpr S s {^^int};

// TU 2
extern const struct S s;
const void* p = &s; // oops

[jicama]

The motivation is that there cannot be an object representation of a meta::info; it's inherently a handle for some compiler internals.

It seems fine to me to defer the decision of whether a variable has consteval-only type until end of file; we already do that for other linkage decisions. And we do that for immediate-escalating functions where we don't know whether a function they call will become consteval. This seems not all that different.

[lprv]

The motivation is that there cannot be an object representation of a meta::info

Why not? Any arbitrary bit pattern will do, since these objects are not read at runtime for their value, and the standard makes no guarantees about their representation.