This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.

### 3645. `resize_and_overwrite` is overspecified to call its callback with lvalues

Section: 23.4.3.5 [string.capacity] Status: New Submitter: Arthur O'Dwyer Opened: 2021-11-28 Last modified: 2022-01-30

Priority: 2

View all other issues in [string.capacity].

View all issues with New status.

Discussion:

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

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

[2022-01-30; Reflector poll]

Set priority to 2 after reflector poll.

Proposed resolution:

This wording is relative to N4901.

1. Modify 23.4.3.5 [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 (6.7.4 [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 (25.3.4.4 [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`.