You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
CWG3038 [dcl.attr.assume] Ignorability VS stateful template metaprogramming #716
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [dcl.attr.assume]
Link to reflector thread (if any):
Issue description:
Given the following well-formed program, removing the assumption statement renders it ill-formed (Godbolt link). This is because [[assume]] makes its condition potentially evaluated, and every potentially evaluated occurrence of next() modifies the state of overload resolution.
The example also shows that Note 5 in [dcl.attr.grammar] is incorrect for [[assume]], as removing all instances of [[assume]] can make a well-formed program (using stateful metaprogramming) ill-formed or have different semantics.
The original direction of CWG2118 would reject this program. But CWG2118 seems inactive and possibly NAD, as arcane things are (and will be) introduced later:
Unevaluated lambda expression whose type is difference between occurrences (introduced in P0315R4), and
CWG2118 hasn't changed direction; we still want that case to be unsupported. (If we do support that case, we might need a concept like "evaluation context", as introduced by P2996.)
P2996 is explicitly supporting compile-time state, though.
The note in question is already arguably incorrect for [[no_unique_address]], and it's probably easy to combine the ticket counter enabled with P2996 with any potentially-evaluated expression appearing in an attribute, including the one in [[assume]].
However, the note was the result of a long struggle in EWG, so the best I can do is document the tension as a CWG issue and assign that to EWG.
changed the title [-][dcl.attr.assume] Ignorability VS stateful template metaprogramming[/-][+]CWG3038 [dcl.attr.assume] Ignorability VS stateful template metaprogramming[/+]on Jul 27, 2025
Activity
jensmaurer commentedon Jun 17, 2025
CWG2118 hasn't changed direction; we still want that case to be unsupported. (If we do support that case, we might need a concept like "evaluation context", as introduced by P2996.)
P2996 is explicitly supporting compile-time state, though.
The note in question is already arguably incorrect for [[no_unique_address]], and it's probably easy to combine the ticket counter enabled with P2996 with any potentially-evaluated expression appearing in an attribute, including the one in [[assume]].
However, the note was the result of a long struggle in EWG, so the best I can do is document the tension as a CWG issue and assign that to EWG.
jensmaurer commentedon Jul 27, 2025
CWG3038
[-][dcl.attr.assume] Ignorability VS stateful template metaprogramming[/-][+]CWG3038 [dcl.attr.assume] Ignorability VS stateful template metaprogramming[/+]