Brian Silverman | 5962333 | 2018-08-04 23:36:56 -0700 | [diff] [blame^] | 1 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| 2 | Problem with ``reference`` and old/new iterator category correspondance |
| 3 | ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ |
| 4 | |
| 5 | .. _N1550: http://www.boost-consulting.com/writing/n1550.html |
| 6 | .. _N1530: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1530.html |
| 7 | |
| 8 | :Author: David Abrahams and Jeremy Siek |
| 9 | :Contact: dave@boost-consulting.com, jsiek@osl.iu.edu |
| 10 | :Organization: `Boost Consulting`_, Indiana University Bloomington |
| 11 | :date: $Date$ |
| 12 | :Copyright: Copyright David Abrahams, Jeremy Siek 2003. Use, modification and |
| 13 | distribution is subject to the Boost Software License, |
| 14 | Version 1.0. (See accompanying file LICENSE_1_0.txt or copy |
| 15 | at http://www.boost.org/LICENSE_1_0.txt) |
| 16 | |
| 17 | .. _`Boost Consulting`: http://www.boost-consulting.com |
| 18 | |
| 19 | ============== |
| 20 | Introduction |
| 21 | ============== |
| 22 | |
| 23 | The new iterator categories are intended to correspond to the old |
| 24 | iterator categories, as specified in a diagram in N1550_. For example, |
| 25 | an iterator categorized as a mutable Forward Iterator under the old |
| 26 | scheme is now a Writable, Lvalue, and Foward Traversal iterator. |
| 27 | However, there is a problem with this correspondance, the new iterator |
| 28 | categories place requirements on the ``iterator_traits<X>::reference`` |
| 29 | type whereas the standard iterator requirements say nothing about the |
| 30 | ``reference`` type . In particular, the new Readable Iterator |
| 31 | requirements say that the return type of ``*a`` must be |
| 32 | ``iterator_traits<X>::reference`` and the Lvalue Iterator requirements |
| 33 | says that ``iterator_traits<X>::reference`` must be ``T&`` or ``const |
| 34 | T&``. |
| 35 | |
| 36 | |
| 37 | ==================== |
| 38 | Proposed Resolution |
| 39 | ==================== |
| 40 | |
| 41 | Change the standard requirements to match the requirements of the new |
| 42 | iterators. (more details to come) |
| 43 | |
| 44 | |
| 45 | ========== |
| 46 | Rationale |
| 47 | ========== |
| 48 | |
| 49 | The lack of specification in the standard of the ``reference`` type is |
| 50 | certainly a defect. Without specification, it is entirely useless in a |
| 51 | generic function. The current practice in the community is generally |
| 52 | to assume there are requirements on the ``reference`` type, such as |
| 53 | those proposed in the new iterator categories. |
| 54 | |
| 55 | There is some danger in *adding* requirements to existing concepts. |
| 56 | This will mean that some existing iterator types will no longer meet |
| 57 | the iterator requirements. However, we feel that the impact of this is |
| 58 | small enough to warrant going ahead with this change. |
| 59 | |
| 60 | An alternative solution would be to leave the standard requirements as |
| 61 | is, and to remove the requirements for the ``reference`` type in the |
| 62 | new iterator concepts. We are not in favor of this approach because it |
| 63 | extends what we see as a defect further into the future. |