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.

### 2183. Muddled allocator requirements for `match_results` constructors

Section: 32.9.2 [re.results.const], 32.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:

32.9.2 [re.results.const] p1 says:

> In all `match_results` constructors, a copy of the `Allocator` argument shall be used for any memory allocation performed by the constructor or member functions during the lifetime of the object.

There are three constructors:

>     match_results(const Allocator& = Allocator());
>     match_results(const match_results& m);
>     match_results(match_results&& m) noexcept;

The second and third constructors do no have an `Allocator` argument, so despite the "all `match_results` constructors", it is not possible to use "the `Allocator` argument" for the second and third constructors.

The requirements for those two constructors also does not give any guidance. The second constructor has no language about allocators, and the third states that the stored `Allocator` value is move constructed from `m.get_allocator()`, but doesn't require using that allocator to allocate memory.

The same basic problem recurs in 32.9.7 [re.results.all], which gives the required return value for `get_allocator()`:

> Returns: 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.

Again, the second and third constructors do not take an `Allocator`, so there is nothing that meets this requirement when those constructors are used.

[2018-06-02, Daniel comments and provides wording]

The introductory wording of `match_results` says in 32.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.

This wording essentially brings us to 24.2.2.1 [container.requirements.general] which describes in p8 in general the usage of allocators:

> […] Copy constructors for these container types obtain an allocator by calling `allocator_traits<allocator_ type>::select_on_container_copy_construction` on the allocator belonging to the container being copied. Move constructors obtain an allocator by move construction from the allocator belonging to the container being moved. […]

The constructors referred to in the issue discussion are the copy constructor and move constructor of `match_results`, so we know already what the required effects are supposed to be.

24.2.2.1 [container.requirements.general] p8 also says more to this allocator topic a bit latter:

> […] All other constructors for these container types take a `const allocator_type&` argument. [Note: If an invocation of a constructor uses the default value of an optional allocator argument, then the Allocator type must support value-initialization. — end note] A copy of this allocator is used for any memory allocation and element construction performed, by these constructors and by all member functions, during the lifetime of each container object or until the allocator is replaced. […]

Further requirements imposed on two of the three `match_results` constructors can be derived from Table 80 — "Allocator-aware container requirements" via the specified expressions

>     X()
>     X(m)
>     X(rv)

In other words: The existing wording does already say everything that it said by 32.9.2 [re.results.const] p1 (end even more), except for possibly the tiny problem that

>     match_results(const Allocator& a = Allocator());

uses "`const Allocator&`" instead of "`const allocator_type&`" in the signature, albeit even that deviation shouldn't change the intended outcome, which is IMO crystal-clear when looking at sub-clauses 24.2.2.1 [container.requirements.general] and 24.2.4 [sequence.reqmts] as a whole.

That directly makes two mutually exclusive solutions feasible:

- Either strike 32.9.2 [re.results.const] p1 completely; or

- Replace 32.9.2 [re.results.const] p1 by referring to the specification of allocators in 24.2.2.1 [container.requirements.general] and 24.2.4 [sequence.reqmts].

My suggestion is to favour for the first option, because attempting to provide extra wording that refers to allocators and the three constructors may lead to the false impression that no further allocator-related requirements hold for type `match_results` which are not explicitly repeated here again.

[2018-06, Rapperswil]

The group agrees with the provided resolution. Move to Ready.

[2018-11, Adopted in San Diego]

Proposed resolution:

This wording is relative to N4750.

1. Edit 32.9.2 [re.results.const] as indicated:

   > -1- In all `match_results` constructors, a copy of the `Allocator` argument shall be used for any memory allocation performed by the constructor or member functions during the lifetime of the object.