Title
Useless sequence container requirement
Status
new
Section
[sequence.reqmts]
Submitter
Casey Carter

Created on 2019-09-17.00:00:00, last changed 2019-10-31.18:46:30.

Messages

Date: 2019-10-31.18:46:30

Proposed resolution:

This wording is relative to N4830.

  1. Modify [sequence.reqmts] as indicated:

    -3- In Tables 76 and 77, X denotes a sequence container class, a denotes a value of type X containing elements of type T, u denotes the name of a variable being declared, A denotes X::allocator_type if the qualified-id X::allocator_type is valid and denotes a type ([temp.deduct]) and allocator<T> if it doesn't, i and j denote iterators that meet the Cpp17InputIterator requirements and refer to elements implicitly convertible to value_type, [i, j) denotes a valid range, […]

Date: 2019-10-31.00:00:00

[ 2019-10-31 Issue Prioritization ]

Priority to 3 after reflector discussion.

Date: 2019-09-17.00:00:00

[sequence.reqmts] paragraph 3 says that the names i and j denote "iterators that meet the Cpp17InputIterator requirements and refer to elements implicitly convertible to value_type". Ignoring for the moment that this is an occurrence of LWG 3105 — we really mean that *i and *j must be implicitly convertible to value_type — this requirement seems to be completely extraneous.

The names i and j are used in three places in the requirements table:

  • The range constructors X(i, j) and X u(i, j), which require that the container's value type is Cpp17EmplaceConstructible into the container from *i; implicit conversion is neither necessary nor sufficient.

  • The range insert overload a.insert(p, i, j) which also requires Cpp17EmplaceConstructible, as well as the capability to move elements around for vector and deque; again, implicit conversion is neither necessary nor sufficient. It would be useful / performant here to require that the container's value type is assignable from *i, which may have been the intent of the implicit conversion requirement — would doing so be too breaking?

  • The range assign overload a.assign(i, j) which requires both Cpp17EmplaceConstructible as above and that it can assign the result of dereferencing an iterator directly to the container's value type; again, implicit conversion is not useful here.

We should strike the implicit conversion requirement since it is not useful and only serves to confuse readers of the Standard (see e.g. here).

History
Date User Action Args
2019-10-31 18:46:30adminsetmessages: + msg10713
2019-09-23 17:15:38adminsetmessages: + msg10665
2019-09-17 00:00:00admincreate