Proposed resolution:

This wording is relative to N4910.

1. Modify [sequence.reqmts] as indicated:

   -3- In this subclause,

   1. (3.1) — […]

   2. […]

   3. (3.5) — i and j denote iterators that meet the Cpp17InputIterator requirements and refer to elements implicitly convertible to value_type,

   4. […]

[ 2022-04-24; Daniel rebases wording on N4910 ]

[ 2019-10-31 Issue Prioritization ]

Priority to 3 after reflector discussion.

Previous resolution [SUPERSEDED]:

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, […]

[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).