Proposed resolution:

This wording is relative to N4917.

1. Modify [string.capacity] as indicated:

   template<class Operation> constexpr void resize_and_overwrite(size_type n, Operation op);
   

   -7- Let

   1. (7.1) — o = size() before the call to resize_and_overwrite.

   2. (7.2) — k be min(o, n).

   3. (7.3) — p be a value of type charT* or charT* const, such that the range [p, p + n] is valid and this->compare(0, k, p, k) == 0 is true before the call. The values in the range [p + k, p + n] may be indeterminate ([basic.indet]).

   4. (7.?) — m be a value of type size_type or const size_type equal to n.

   5. (7.4) — OP be the expression std::move(op)(p, nm).

   6. (7.5) — r = OP.

   -8- Mandates: OP has an integer-like type ([iterator.concept.winc]).

   -9- Preconditions:

   1. (9.1) — OP does not throw an exception or modify p or nm.

   2. (9.2) — r ≥ 0.

   3. (9.3) — r ≤ nm.

   4. (9.4) — After evaluating OP there are no indeterminate values in the range [p, p + r).

   -10- Effects: Evaluates OP, replaces the contents of *this with [p, p + r), and invalidates all pointers and references to the range [p, p + n].

   -11- Recommended practice: Implementations should avoid unnecessary copies and allocations by, for example, making p a pointer into internal storage and by restoring *(p + r) to charT() after evaluating OP.

[ 2023-02-13 Approved at February 2023 meeting in Issaquah. Status changed: Immediate → WP. ]

[ Issaquah 2023-02-07; LWG ]

Move to Immediate for C++23

[ 2023-01-11; Jonathan Wakely provides new wording requested by LWG ]

[ 2022-01-30; Reflector poll ]

Set priority to 2 after reflector poll.

Previous resolution [SUPERSEDED]:

This wording is relative to N4901.

1. Modify [string.capacity] as indicated:

   template<class Operation> constexpr void resize_and_overwrite(size_type n, Operation op);
   

   -7- Let

   1. (7.1) — o = size() before the call to resize_and_overwrite.

   2. (7.2) — k be min(o, n).

   3. (7.3) — p be a charT*, such that the range [p, p + n] is valid and this->compare(0, k, p, k) == 0 is true before the call. The values in the range [p + k, p + n] may be indeterminate ([basic.indet]).

   4. (7.4) — OP be the expression std::move(op)(auto(p), auto(n)).

   5. (7.5) — r = OP.

   -8- Mandates: OP has an integer-like type ([iterator.concept.winc]).

   -9- Preconditions:

   1. (9.1) — OP does not throw an exception or modify p or n.

   2. (9.2) — r ≥ 0.

   3. (9.3) — r ≤ n.

   4. (9.4) — After evaluating OP there are no indeterminate values in the range [p, p + r).

   -10- Effects: Evaluates OP, replaces the contents of *this with [p, p + r), and invalidates all pointers and references to the range [p, p + n].

   -11- Recommended practice: Implementations should avoid unnecessary copies and allocations by, for example, making p a pointer into internal storage and by restoring *(p + r) to charT() after evaluating OP.

[ 2021-11-29; Arthur O'Dwyer provides wording ]

[string.capacity] p7 says:

• [Let] OP be the expression std::move(op)(p, n).

• [Precondition:] OP does not throw an exception or modify p or n.

Notice that p and n above are lvalue expressions.

Discussed with Mark Zeren, Casey Carter, Jonathan Wakely. We observe that:

A. This wording requires vendors to reject

s.resize_and_overwrite(100, [](char*&&, size_t&&){ return 0; });

which is surprising.

B. This wording requires vendors to accept

s.resize_and_overwrite(100, [](char*&, size_t&){ return 0; });

which is even more surprising, and also threatens to allow the user to corrupt the internal state (which is why we need to specify the Precondition above).

C. A user who writes

s.resize_and_overwrite(100, [](auto&&, auto&&){ return 0; });

can detect that they're being passed lvalues instead of rvalues. If we change the wording to permit implementations to pass either lvalues or rvalues (their choice), then this will be detectable by the user, so we don't want that if we can help it.

1. X. We want to enable implementations to say move(op)(__p, __n) and then use __p and __n.

2. Y. We have one implementation which wants to say move(op)(data(), __n), which is not currently allowed, but arguably should be.

3. Z. We have to do or say something about disallowing writes to any internal state to which Op might get a reference.

Given all of this, Mark and Arthur think that the simplest way out is to say that the arguments are prvalues. It prevents X, but fixes the surprises in A, B, Y, Z. We could do this in the Let bullets. Either like so:

• [Let] p be a prvalue of type charT* …

• m be a prvalue of type size_type equal to n,

• OP be the expression std::move(op)(p, m).

or (Arthur's preference) by specifying prvalues in the expression OP itself:

• [Let] OP be the expression std::move(op)(auto(p), auto(n)).

No matter which specification approach we adopt, we can also simplify the Preconditions bullet to:

• [Precondition:] OP does not throw an exception.

because once the user is receiving prvalue copies, it will no longer be physically possible for the user to modify the library's original variables p and n.