CWG2816 [intro.progress] The meaning of "eventually" is unclear

[frederick-vs-ja]

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

Reference (section label): [intro.progress]

Link to reflector thread (if any):

Issue description:

[intro.progress] p1 currently says

The implementation may assume that any thread will eventually do one of the following:

• terminate,
• make a call to a library I/O function,
• perform an access through a volatile glvalue, or
• perform a synchronization operation or an atomic operation.

Note that P2809R0 wants to add trivial potentially infinite loops to the list.

It is unclear whether once one of these operations (except for termination) has been done, the rest of execution can still be affected by such assumption. Transformation of potentially infinite loops would be seriously restricted if the assumption can't be done after these operations.

Presumably the assumption is allowed in every point of the execution except for those in these operations themselves, and we should avoid the possibly ambiguity of "eventually".

Suggested resolution:

Change [intro.progress] p1 as indicated:

The implementation may assume that any thread will eventually do one of the following An abstract jump point is a goto statement (8.7.6 [stmt.goto]), the beginning of a function, or the beginning of the statement of a loop (8.6.1 [stmt.iter.general]) Once a thread has started or completed one of the following operations except for termination, if the thread will execute abstract jump point for infinite times before executing any of the following operations, the behavior is undefined:
[...]

[FrankHB]

I don't see much room of improvement here. And the change may even incur more problems. One of the question: what is the precise meaning of termination as an operation? This is not a problem (that significant) in the old wording.

Note the revised P2809R1 still has more gaps in the wording compared to the quality of the current standard, e.g. incorrect use of "must" in normative text. Moreover, I don't buy that direction much. There are many technical problems remain unresolved, if not more. The "Current equivalence in C++" column in that paper is incorrect as per the literal meaning of the current wording; concerns of llvm/llvm-project#60622 (comment) and cplusplus/draft#5377 are never completely addressed. That paper only confirms that we (or most of us) need to respect the valid needs of having some ways to express syntactically infinite loops allowed by the language rules, but far from the need of clarifying the criteria to keep which design in the language, which is about the overall design of the abstraction machine semantics. I see little feasibility to improve the status quo, esp. since P2809R1 has introduced many questionable conclusions about the current status, which may likely lead to more confusion than the wording already in the standard.

I'd prefer an enhancement at first: formally admitting non-termination as a kind of side effects (following to the tradition of PL research), and rewording [intro.progress] with more succinct rules equivalent to the status quo. Then we may need less changes elsewhere. (That will need at least one more paper, of course.)

CC @jfbastien .

[jensmaurer]

P2809R1 isn't anywhere close to getting adopted for the Working Draft.

Could you be more specific about

The "Current equivalence in C++" column in that paper is incorrect as per the literal meaning of the current wording

Which row(s) are incorrect? Why?

[frederick-vs-ja]

One of the question: what is the precise meaning of termination as an operation? This is not a problem (that significant) in the old wording.

We can switch to use another noun if you believe that "this is not a problem (that significant) in the old wording".

Another concern: the list in [intro.progress] p1 is highly overlapping with but not equivalent to the definition of execution step in p3. Can we do deduplication?

[FrankHB]

P2809R1 isn't anywhere close to getting adopted for the Working Draft.

Could you be more specific about

The "Current equivalence in C++" column in that paper is incorrect as per the literal meaning of the current wording

Which row(s) are incorrect? Why?

As disscussed in the given issues, the current wording ("may assume") does not imply undefined behavior. Such wording has room of the interpretation towards undefined behavior as per Clause 4 in ISO C, but this is not the case in ISO C++, which only permits implementation-specific variants of well-defined behaviors, i.e. unspecified behavior, effectively. OTOH, [dcl.attr.noreturn]/2 explicitly renders the violation of [[noreturn]] undefined behavior. The requirements about undefined behavior and unspecified behavior certainly differ. Thus, all instances "undefined behavior" mentioned in "Current equivalence in C++" are technically incorrect.

[FrankHB]

One of the question: what is the precise meaning of termination as an operation? This is not a problem (that significant) in the old wording.

We can switch to use another noun if you believe that "this is not a problem (that significant) in the old wording".

This will not solve the problem. When there is doubt on the meaning, it can be problems about the intension, the extention, or both - of the concept named by the noun. The descriptions about intension of such concepts may be difficult to construct. Alternatively, to eliminate the doubt of precision, one may enumerate all the intentionally allowed instances. Insufficient of such work will not be addressed by merely using some other nouns.

There are occasionally less problems in the old wording because "termination" is mentioned in other clauses, and at least the conditions of program termination should be clearer (a bit). I cannot conclude more before you happen to determine which noun can be the candidates.

[frederick-vs-ja]

There are occasionally less problems in the old wording because "termination" is mentioned in other clauses, and at least the conditions of program termination should be clearer (a bit). I cannot conclude more before you happen to determine which noun can be the candidates.

I haven't got any idea of a better noun. My intent was merely referring to following "items (things/operations/actions/...)" in [intro.progress] p1 without repitition, given p3 is already somehow repititive.

[jensmaurer]

CWG2816