From 6ee3de8728731e41c17f1df231c495f8b48bb732 Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Fri, 11 Sep 2026 01:23:30 -0500 Subject: [PATCH] Update PR for 3898 --- xml/issue3898.xml | 103 ++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 91 insertions(+), 12 deletions(-) diff --git a/xml/issue3898.xml b/xml/issue3898.xml index 30e2e49acc..3c59438df1 100644 --- a/xml/issue3898.xml +++ b/xml/issue3898.xml @@ -16,15 +16,15 @@ […] is_nothrow_invocable_v<CompletionFunction&> shall be true.

-This requirement introduces a kind of undefined behavior and permits implementation divergence. Currently +This requirement introduces a kind of undefined behavior and permits implementation divergence. Currently MSVC STL -enforces the requirement, while -libstdc++ -and -libc++ +enforces the requirement, while +libstdc++ +and +libc++ don't.

-If implementation divergence is not intended, I don't think it makes much sense to introduce UB in this way. +If implementation divergence is not intended, I don't think it makes much sense to introduce UB in this way. I guess we should either strengthen the requirement to require well-formedness affection or relax it.

@@ -40,8 +40,8 @@ This wording is relative to .

-[Drafting Note: Two mutually exclusive options are prepared, depicted below by Option A and -Option B, respectively.] +[Drafting Note: Two mutually exclusive options are prepared, depicted below by Option A and +Option B, respectively.]

@@ -56,8 +56,8 @@ This wording is relative to .

-5- CompletionFunction shall meet the Cpp17MoveConstructible (Table 32) and Cpp17Destructible (Table 36) -requirements. Instantiation of barrier<CompletionFunction> is ill-formed if -is_nothrow_invocable_v<CompletionFunction&> is not +requirements. Instantiation of barrier<CompletionFunction> is ill-formed if +is_nothrow_invocable_v<CompletionFunction&> is not trueis_nothrow_invocable_v<CompletionFunction&> shall be true.

@@ -79,7 +79,7 @@ requirements. Instantiation of barrier<CompletionFunction> i -3- The phase completion step that is executed at the end of each phase has the following effects:

    -

  1. (3.1) — Invokes the completion function, equivalent to completion(). If any invocation +

  2. (3.1) — Invokes the completion function, equivalent to completion(). If any invocation to the completion function throws an exception, the behavior is undefined.

  3. (3.2) — Unblocks all threads that are blocked on the phase synchronization point.

@@ -98,13 +98,92 @@ requirements. is_nothrow_invocable_v<CompletionFunction&>2023-03-22; Jonathan provides improved wording + +

This wording is relative to .

+ +
    + +

  1. Modify as indicated:

    + +
    +

    +-3- The phase completion step that is executed at the end of each phase has the following effects: +

    +
      +

    1. (3.1) — Invokes the completion function, equivalent to +completion(); if that invocation exits via an exception, +the function std::terminate is invoked. +

      2. +

    2. (3.2) — Unblocks all threads that are blocked on the phase synchronization point.

      3. +
    +

    +[…] +

    +

    +-5- CompletionFunction shall meet the Cpp17MoveConstructible (Table 32) and Cpp17Destructible (Table 36) +requirements. + +is_nothrow_invocable_v<CompletionFunction&> +shall be true. + + +A program that instantiates barrier<CompletionFunction> +is ill-formed if is_invocable_v<CompletionFunction&> +is false. + +

    +
    + +
    2. + +
+ + + +2026-09-11; Tim provides new wording +

Needs an update to the gigantic "when do we call `std::terminate`?" note.

-

This wording is relative to .

+

This wording is relative to .

    +

  1. Modify as indicated:

    +
    +

    +-1- Some errors in a program cannot be recovered from, such as when an exception is not handled or a `std::thread` object is destroyed +while its thread function is still executing. In such cases, the function `std::terminate` () is invoked. +

    +

    [Note 1: These situations are:

    +
      +

    1. (1.1) — […]

      2. +

    2. (1.2) — […]

      3. +

    3. (1.3) — […]

      4. +

    4. (1.4) — […]

      5. +

    5. (1.5) — […]

      6. +

    6. (1.6) — […]

      7. +

    7. (1.7) — […]

      8. +

    8. (1.8) — […]

      9. +

    9. (1.9) — […]

      10. +

    10. (1.10) — […]

      11. +

    11. (1.11) — […]

      12. +

    12. (1.12) — […]

      13. +

    13. (1.13) — […]

      14. +

    14. (1.14) — when a callback invocation exits via an exception when requesting stop on a `std::stop_source` +or a `std::inplace_stop_source` (, ), +or in the constructor of `std::stop_callback` or `std::inplace_stop_callback` (, ) +when a callback invocation exits via an exception, or

      15. +

    15. (1.?) — when an invocation of the completion function of a `std::barrier` object () exits via an exception, or

      16. +

    16. (1.15) — when a `run_loop` object is destroyed that is still in the `running` state (), or

      17. +

    17. (1.16) — […]

      18. +

    18. (1.17) — […]

      19. +

    19. (1.18) — […]

      20. +

    20. (1.19) — […]

      21. +
    +

    — end note ]

    +
    +

  2. Modify as indicated: