3645. resize_and_overwrite is overspecified to call its callback with lvalues

Section: 27.4.3.5 [string.capacity] Status: C++23 Submitter: Arthur O'Dwyer Opened: 2021-11-28 Last modified: 2023-11-22

Priority: 2

View all other issues in [string.capacity].

View all issues with C++23 status.

Discussion:

27.4.3.5 [string.capacity] p7 says:

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:

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

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

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.

Previous resolution [SUPERSEDED]:

This wording is relative to N4901.

  1. Modify 27.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 (24.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.

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

[Issaquah 2023-02-07; LWG]

Move to Immediate for C++23

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

Proposed resolution:

This wording is relative to N4917.

  1. Modify 27.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 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 (6.7.4 [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 (24.3.4.4 [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.