This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++20 status.
match_results
assignmentsSection: 28.6.9.2 [re.results.const], 28.6.9.7 [re.results.all] Status: C++20 Submitter: Pete Becker Opened: 2012-08-29 Last modified: 2021-02-25
Priority: 3
View all other issues in [re.results.const].
View all issues with C++20 status.
Discussion:
The effects of the two assignment operators are specified in Table 141. Table 141 makes no mention of allocators,
so, presumably, they don't touch the target object's allocator. That's okay, but it leaves the question:
match_results::get_allocator()
is supposed to return "A copy of the Allocator that was passed to the
object's constructor or, if that allocator has been replaced, a copy of the most recent replacement"; if assignment
doesn't replace the allocator, how can the allocator be replaced?
[2018-06-04, Daniel comments and provides wording]
Similar to the reasoning provided in the 2018-06-02 comment in LWG 2183(i), it is possible to refer to
the introductory wording of match_results
which says in 28.6.9 [re.results] p2:
The class template
match_results
satisfies the requirements of an allocator-aware container and of a sequence container (26.2.1, 26.2.3) except that only operations defined for const-qualified sequence containers are supported and that the semantics of comparison functions are different from those required for a container.
Again, similar to LWG 2183(i), this allows us to deduce the required effects of the copy/move assignment operators discussed here, because 23.2.2 [container.requirements.general] p8 also says:
[…] The allocator may be replaced only via assignment or
swap()
. Allocator replacement is performed by copy assignment, move assignment, or swapping of the allocator only ifallocator_traits<allocator_type>::propagate_on_container_copy_assignment::value
,allocator_traits<allocator_type>::propagate_on_container_move_assignment::value
, orallocator_traits<allocator_type>::propagate_on_container_swap::value
istrue
within the implementation of the corresponding container operation. In all container types defined in this Clause, the memberget_allocator()
returns a copy of the allocator used to construct the container or, if that allocator has been replaced, a copy of the most recent replacement. […]
So this wording already specifies everything we need, except for the problem that
28.6.9 [re.results] p2 quoted above restricts to operations supported by a const-qualified sequence
container, which of-course would exclude the copy assignment and the move assignment operators.
But given that these mutable definitions are defined for match_results
, it seems that the only fix
needed is to adjust 28.6.9 [re.results] p2 a bit to ensure that both assignment operators are
covered (again) by the general allocator-aware container wording.
[2018-06, Rapperswil]
The group generally likes the suggested direction, but would prefer the changed wording to say effectively "except that only copy assignment, move assignment, and operations defined...". Once applied, move to ready.
Previous resolution [SUPERSEDED]:
This wording is relative to N4750.
Edit 28.6.9 [re.results] as indicated:
-2- The class template
match_results
satisfies the requirements of an allocator-aware container and of a sequence container (23.2.2 [container.requirements.general], 23.2.4 [sequence.reqmts]) except that besides copy assignment and move assignment only operations defined for const-qualified sequence containers are supported and that the semantics of comparison functions are different from those required for a container.
[2018-06-06, Daniel updates wording]
[2018-11, Adopted in San Diego]
Proposed resolution:
This wording is relative to N4750.
Edit 28.6.9 [re.results] as indicated:
-2- The class template
match_results
satisfies the requirements of an allocator-aware container and of a sequence container (23.2.2 [container.requirements.general], 23.2.4 [sequence.reqmts]) except that only copy assignment, move assignment, and operations defined for const-qualified sequence containers are supported and that the semantics of comparison functions are different from those required for a container.