Title
nothrow-input-iterator constraints should not mention copying
Status
new
Section
[special.mem.concepts]
Submitter
Konstantin Varlamov

Created on 2021-11-30.00:00:00 last changed 1 month ago

Messages

Date: 2021-12-19.09:33:44

Proposed resolution:

This wording is relative to N4901.

  1. Modify [special.mem.concepts] as indicated:

    template<class I>
    concept nothrow-input-iterator = // exposition only
      input_iterator<I> &&
      is_lvalue_reference_v<iter_reference_t<I>> &&
      same_as<remove_cvref_t<iter_reference_t<I>>, iter_value_t<I>>;
    

    -2- A type I models nothrow-input-iterator only if no exceptions are thrown from increment, copy construction, move construction, copy assignment, move assignment, or indirection through valid iterators.

Date: 2021-12-15.00:00:00

[ 2021-12-19; Daniel comments ]

During LWG discussion of the issue one argument brought forward against the proposed wording was that it might be incomplete, because it doesn't adjust the nothrow-forward-iterator concept, which adds among other things the copyable requirements. But nothrow-forward-iterator also requires nothrow-sentinel-for<I, I>, which already extends this necessary no-throw requirement for copy operations by p. 4:

Types S and I model nothrow-sentinel-for only if no exceptions are thrown from copy construction, move construction, copy assignment, move assignment, or comparisons between valid values of type I and S.

It should also be emphasized that the definitions of move construction ([defns.move.constr]) and move assignment ([defns.move.assign]) are compatible even for copyable input iterator types, because these definitions refer just to expression conditions, and not to concrete operator overloads. So as long as an implementation applies these expression conditions, we are safe.

Date: 2021-11-30.00:00:00

[special.mem.concepts] states that a type qualifies as a nothrow-input-iterator only if no exceptions are thrown from, among other things, copy construction and copy assignment. However, being copyable isn't part of the requirements for an input_iterator on which nothrow-input-iterator is based (indeed, one of the things forward_iterator adds to input_iterator is copyability), and the nothrow-input-iterator concept doesn't add any new constraints related to copyability.

History
Date User Action Args
2021-12-19 09:33:44adminsetmessages: + msg12257
2021-12-04 14:24:59adminsetmessages: + msg12244
2021-11-30 00:00:00admincreate