Proposed resolution:

This wording is relative to N5054.

1. Modify [structure.specifications] 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 ([stmt.return]) 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]

[ 2026-08-28 LWG telecon; Status changed: New → Ready. ]

[ 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.

[ 2022-01-29; Reflector poll ]

Set priority to 3 after reflector poll.
Tim: "P2. Not for this particular case (I'm pretty sure there'll be agreement that this shouldn't induce any constraint), but for the more general issue of "Effects: Equivalent to" propagating Constraints:; I'm not sure that's the right approach in general (unlike the other elements, Constraints: requires special handling beyond "use this code" and is pretty hard to work through if we have a lengthy code block) - and it certainly doesn't really make a lot of sense to propagate Constraints: but not actual core-language constraints."

Most uninitialized memory algorithms ([specialized.algorithms]) are specified by plain "Effects: Equivalent to:". According to [structure.specifications]/4, such wording requires propagation of "Constraints" of selected constructors. The first two overloads of std::reduce ([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 implementable but brings serious inconsistency.

Perhaps we should add "Mandates:" to these algorithms (except for algorithms in std::ranges).