Repository navigation
CWG3058 "Program point" is not defined #749
Description
Activity
Since we're dealing with tokens (not individual characters) in phase 7, as long as the "point" we're talking about is a single token (e.g. an identifier), I don't think the difference between a zero-length point and a token matters at all when considering "program points".
I can see how it might not matter whether a point is an entire token or a single point within the token, but I think it might matter whether a point is between two tokens (or at the beginning or end of a TU).
It'd be helpful to have examples where our use of "program point" is unclear even given the "token" interpretation.
[temp.point] sometimes specifies that a point of instantiation immediately precedes or follows another point of instantiation. This can be chained:
template <int x> struct A; template <> struct A<0> {}; template <int x> struct A { A<x - 1> a; }; A<100> a;The point of instantiation of
A<100>is specified to immediately precede the namespace-scope definition ofa. The point of instantiation ofA<99>is specified to immediately precede that ofA<100>, and so on and so on. This doesn't make sense if points are at tokens: it would imply that every time you go to the immediately preceding point, you go back one token. That would mean eventually you get to a point where the specializationA<0>isn't even reachable, and then eventually to imaginary tokens before the beginning of the TU.I think this makes it sufficiently obvious that there must be an infinite number of program points between each pair of tokens, but there should be a definition somewhere that explicitly says this; readers should not have to infer it based on the intent of [temp.point]. I don't think we need program points at tokens, but I'm not sure.
- changed the title
[-]"Program point" is not defined[/-][+]CWG3058 "Program point" is not defined[/+]on Sep 10, 2025 I mostly like the suggested wording, but I'd prefer a clarifying note that there are other program points: This includes synthesized points ([expr.const]/29.1); it's also unclear as to whether the instantiation of a specialization produces "additional points" corresponding to the tokens describing the templated entity from which the specialization was instantiated (but I think the answer may be "yes").
I mostly like the suggested wording, but I'd prefer a clarifying note that there are other program points: This includes synthesized points ([expr.const]/29.1); it's also unclear as to whether the instantiation of a specialization produces "additional points" corresponding to the tokens describing the templated entity from which the specialization was instantiated (but I think the answer may be "yes").
The proposed resolution is wrong. It was just submitted to have a starting point for discussion. In reality there can be arbitrarily many program points between each pair of tokens---even prior to the introduction of synthesized points by P2996. In my example above, the points of instantiation of
A<100>,A<99>, ...,A<1>are all immediately before the declaration ofa, but are not the same point.I think the correct way to think of program points is as surreal numbers, although in a real program you'll never reach the transfinite cases.
I think the correct way to think of program points is as surreal numbers, although in a real program you'll never reach the transfinite cases.
This sounds a bit scary. IIUC we always only need a finite set of surreal numbers...
Full name of submitter: Alisdair Meredith
Link to reflector thread: https://lists.isocpp.org/core/2025/08/18396.php
Issue description: See reflector thread. Alisdair may decide to submit a NB comment for this, so I'm posting it here to ensure that there's an easily accessible permalink.