2183. Muddled allocator requirements for match_results constructors

Section: 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:

28.6.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 28.6.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 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.

This wording essentially brings us to 23.2.2 [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.

23.2.2 [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 28.6.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 23.2.2 [container.requirements.general] and 23.2.4 [sequence.reqmts] as a whole.

That directly makes two mutually exclusive solutions feasible:

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 28.6.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.