Meeting Agenda - February 6th, 2026
- Nhat’s progress
- PR about reflection operator parsing got merged
- Going to focus on remaining items for reflect-expression next
- Hubert: my concern is that we’re doing parsing, and then I’m not sure what we’re generating out of it. We need meta::info, even as an opaque type, to do meaningful testing.
- Nhat: agree. Implementing meta::info might be the next step
- Dan: there’re developments on consteval-only types that might influence this
- Hubert: now compiler doesn’t enforce some restrictions around consteval-only types
- Dan: you mean trunk?
- Hubert: yes
- Hubert: it would alleviate my concerns if we run tests through the other compiler (Dan’t fork)
- Shafik: Hubert, do you have a suggestion or this is a general concern?
- Hubert: I think we want to have an informal policy that tests should be tested against Dan’s fork
- Vlad: makes sense to me. How is it going to work? Locally? Godbolt?
- Hubert: godbolt links in the review, I guess
- Shafik: makes sense to me
- Dan: happy to review any tests
- Vlad: Dan, is your fork separate from Bloomberg’s?
- Dan: Bloomberg’s fork is dated, but the best we have
- Hubert: Dan, do you have an opinion on whether we should ignore EDG? It’s not up-to-date
- Dan: I agree that we should ignore it
- Hubert: going back to parsing. Not having meta::info made tests less useful, with weird limitations. There’s still a scoping issue. Going breadth-first leaves us with a lot of danger in the future. Can we go depth-first?
- Hubert: limit parsing, but take it forward, create meta::info, maybe even down to splices.
- Dan: I’ve always thought of splicing, expressions, and metafunctions as separate branches of P2996. There’s a separate question of how we’re going to implement it upstream. Tablegen? You might be right that meta::info is the right approach. Maybe omitting consteval-only semantics, since it’s still in flux. What do you think, Hubert?
- Hubert: makes sense
- Dan: or implement the tracking of consteval-only, but not the semantic restrictions
- Hubert: maybe we want to avoid the consteval-only question for now
- Hubert: if we have meta::info, we can have metafunctions. Let’s try to get one query in
- Vlad: what about instantiation problem that we want to discuss in Core?
- Dan: we can implement scaffolding, then implement metafunctions that do not implicitly instantiate
- Hubert: the ship has sailed on whether you need to instantiate during constant evaluation
- Dan: agreed
- Hubert: in which instances do synthesized point appear, going back to the issue of point of instantiation
- Dan: we could have a call to members_of, which needs an implicit instantiation. The question is that compilers like yours what to constant-fold everything. We want to specify that point of instantiation is right after the expression. But then we have tentative evaluations
- Hubert: the are treated as manifestly constant-evaluated
- Dan: but we can’t treat them this way
- Hubert: I don’t agree
- Dan: if we were to pursue this, which I think we should, while you determining
- Hubert: it’s time travel, but not time travel
- Dan: it’s about evaluations you hit before you give up
- Hubert: yes, but I was trying to explain what it was not
- Hubert: compile is a process during which we have evaluations, but the standard doesn’t describe it this way: it will state facts, like whether something is a core constant expression. It’s something that compiler determines after following a process. If side effects happened, this is bad. WE’re trying to say that there’s a portion of evaluation that is going to happen anyway. The other prong of the discussion is where the point of instantiation is. We’re trying to tie to where the evaluation emanates.
- Shafik: it almost feels like we need a design paper
- Dan: probably
- Shafil: every time we discuss this, I feel like I’m diving into a cold water. This needs to be laid down on a paper.
- Hubert: sometimes we’re writing papers to resolve core issue, not always going through evolution
- Shafik: sure
- Hubert: I thought you want a trade-off review
- Shafik: no, trade-off within core
- Dan: I’d already written it if I had time
- Shafik: Hubert, are we going to discuss this in core?
- Hubert: it is one of those places where you need a paper before discussion in core can happen
- Dan: I won’t have time to put a paper before Croydon. I have ideas which someone else can put into a paper. This is one of the places where we can strengthen the specification
- Shafik: what is it blocking? Or we can go forward assuming it’s going to be resolved in a particular way
- Hubert: it’s safe to assume that our ideas to resolve this will be accepted, because it feels natural to me. Dan, when one of the metafunctions get to a point where it needs instantiation, we stop?
- Dan: yes, we do it in many places
- Hubert: compilers arelady separately establish the idea where the point of instantiation comes from. Dan, you have a wording, but we don’t have a Core issue that Jens can open
- Hubert: in the end, I think this issue is to reflect in the wording what the implementation reality is. Fixing the wording gives us a better idea how things work, but it doesn’t block us
- Dan: status quo is not worse than the rest of the template wording
- Shafik: sure, makes sense
- Hubert: I think we haven’t confirmed how we’re going to proceed. We discussed a lot of things, now need to decide. Does Nhat understand how to do meta::info.
- Nhat: we’re doing meta::Info, but without consteval-only
- Hubert: we don’t need to do anything on codegen for meta::info
- Nhat: works for me, I’ll follow-up when I start working
- Dan: “Constification fails to apply to splice-expressions”
- Dan: I was reading about contracts and ran into this. Constification says that if you name outside variables, they are const. Reflection and contracts went in parallel through the committee. If you designate a variable through a splice, constification doesn’t happen. Compilers should be able to diagnose the example. We need to integrate splicing into constificatin wording
- Vlad: not a fan of constification, so this might be a feature, but still worth bringing up for consistency.
- Dan: me neither
- Hubert: makes sense to me
- Aaron: is this applicable when the variable is not named directly?
- Dan: yes
- Vlad: constification would apply to the result of splice-expreesion, irrespecituve of what’s within
- Aaron: makes sense, thank you
- Dan: pointers to consteval-only types
- Dan: let’s open CWG3150
- Dan: I hate this issues
- Dan: we look at consteval-only as being a global property of a type, but from a given point you don’t know whether a type is consteval. Especially fun if you go cross-TU. My current thinking is that GCC does a good thing. They don’t care and don’t emit anything that is consteavl-only. You get a linker error.
- Hubert:
- Dan: my goal is to never force an implementation to emit meta::info. Maybe it’s fine to emit composite types with it, as long as you don’t need to emit info itself. Something like function with info* parameter.
- Hubert: so this is why you’re saying IFNDR
- Hubert: this direction leads to question of what is the value of having consteval-only types in the specification.
- Corentin: if nothing in your type is odr-used, it won’t be emitted anyway
- Hubert: one of the more recent core issues opened was that there is a way to make compiler emit it, which caused Clang ICE
- Dan: I think that crux motivation to have consteval-only types was that by prevening emitting info you ‘re more strict on zero-cost nature of reflection.
- Hubert: this pointer concern doens’t hold. You have a ponter to meta::Info. If it’s null, you’re good.
- Dan: if pointer type is not consteval-only, why can’t you use it
- Hubert: hmm, you might be right
- Corentin: we’re forcing frontend to do a lot of work to prevent emitting an integer that is meaningless. I don’t think we need to do anything
- Dan: if you can have infos at runtime, people would try to have hashsets of them at runtime
- Dan: I wouldn’t underestimate reflection being zero-cost
- Hubert: we made this mistake with inline variables
- Hubert: but with info it’s IFNDR, so you’re just allowing it to be zero-cost
- Dan: standard can’t guarantee zero-cost