From 4df01e206b899cd29f56e715f0d8897c2b30b7a4 Mon Sep 17 00:00:00 2001 From: timsong-cpp Date: Fri, 28 Aug 2026 00:42:09 -0500 Subject: [PATCH] Add P/R for 3628 --- xml/issue3628.xml | 47 +++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 41 insertions(+), 6 deletions(-) diff --git a/xml/issue3628.xml b/xml/issue3628.xml index 61b9286edf..f322da8cd3 100644 --- a/xml/issue3628.xml +++ b/xml/issue3628.xml @@ -10,14 +10,14 @@

-Most uninitialized memory algorithms () are specified by -plain "Effects: Equivalent to:". According to /4, -such wording requires propagation of "Constraints" of selected constructors. The first two +Most uninitialized memory algorithms () are specified by +plain "Effects: Equivalent to:". According to /4, +such wording requires propagation of "Constraints" of selected constructors. The first two overloads of std::reduce () are specified similarly.

-I feel the wording for uninitialized memory algorithms is incorrect, because it means that the -constraints, especially for algorithms in the std, depend on "Constraints" in -the specifications of many standard library types (but not any user-defined type), which is +I feel the wording for uninitialized memory algorithms is incorrect, because it means that the +constraints, especially for algorithms in the std, depend on "Constraints" in +the specifications of many standard library types (but not any user-defined type), which is implementable but brings serious inconsistency.

Perhaps we should add "Mandates:" to these algorithms (except for algorithms in std::ranges). @@ -38,9 +38,44 @@ certainly doesn't really make a lot of sense to propagate Constraints: but not actual core-language constraints."

+2026-08-28; Tim provides wording +

I believe that a careful reading of the existing wording already shows that "Equivalent to:" has +no effect of the sort claimed. But since that appears to be a common misinterpretation, +this wording adds a note to put it to rest.

+

+This wording is relative to . +

+
    +
  1. +

    Modify as indicated:

    + +
    +

    +-4- Whenever the Effects element specifies that the semantics of some function `F` are +Equivalent to some code sequence, then the various elements are interpreted as follows. +If `F`'s semantics specifies any Constraints or Mandates elements, +then those requirements are logically imposed prior to the equivalent-to semantics. +Next, the semantics of the code sequence are determined by the Constraints, Mandates, +Constant When, Preconditions, Hardened preconditions, Effects, +Synchronization, Postconditions, Returns, Throws, Complexity, +Remarks, and Error conditions specified for the function invocations contained +in the code sequence. The value returned from `F` is specified by `F`'s Returns element, +or if `F` has no Returns element, a non-void return from `F` is specified by the return +statements () in the code sequence. If `F`'s semantics contains +a Throws, Postconditions, or Complexity element, then that supersedes +any occurrences of that element in the code sequence. [Note ?: In particular, +if a function call in the code sequence fails to find a viable candidate, whether by reason +of a Constraints element on the called function or otherwise, that function call +(and possibly the entire code sequence) is ill-formed. There is no requirement that `F` itself +not participate in overload resolution in such cases. +— end note] +

    +
    +
  2. +