Proposed resolution:

This wording is relative to N4750.

1. Edit [re.results] as indicated:

   -2- The class template match_results satisfies the requirements of an allocator-aware container and of a sequence container ([container.requirements.general], [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.

[ 2018-11, Adopted in San Diego ]

[ 2018-06-06, Daniel updates 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.

1. Edit [re.results] as indicated:

   -2- The class template match_results satisfies the requirements of an allocator-aware container and of a sequence container ([container.requirements.general], [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-04, Daniel comments and provides wording ]

Similar to the reasoning provided in the 2018-06-02 comment in LWG 2183, it is possible to refer to the introductory wording of match_results which says in [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, this allows us to deduce the required effects of the copy/move assignment operators discussed here, because [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 if allocator_traits<allocator_type>::propagate_on_container_copy_assignment::value, allocator_traits<allocator_type>::propagate_on_container_move_assignment::value, or allocator_traits<allocator_type>::propagate_on_container_swap::value is true within the implementation of the corresponding container operation. In all container types defined in this Clause, the member get_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 [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 [re.results] p2 a bit to ensure that both assignment operators are covered (again) by the general allocator-aware container wording.

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?