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 23The new iterator categories are intended to correspond to the old 24iterator categories, as specified in a diagram in N1550_. For example, 25an iterator categorized as a mutable Forward Iterator under the old 26scheme is now a Writable, Lvalue, and Foward Traversal iterator. 27However, there is a problem with this correspondance, the new iterator 28categories place requirements on the ``iterator_traits<X>::reference`` 29type whereas the standard iterator requirements say nothing about the 30``reference`` type . In particular, the new Readable Iterator 31requirements say that the return type of ``*a`` must be 32``iterator_traits<X>::reference`` and the Lvalue Iterator requirements 33says that ``iterator_traits<X>::reference`` must be ``T&`` or ``const 34T&``. 35 36 37==================== 38 Proposed Resolution 39==================== 40 41Change the standard requirements to match the requirements of the new 42iterators. (more details to come) 43 44 45========== 46 Rationale 47========== 48 49The lack of specification in the standard of the ``reference`` type is 50certainly a defect. Without specification, it is entirely useless in a 51generic function. The current practice in the community is generally 52to assume there are requirements on the ``reference`` type, such as 53those proposed in the new iterator categories. 54 55There is some danger in *adding* requirements to existing concepts. 56This will mean that some existing iterator types will no longer meet 57the iterator requirements. However, we feel that the impact of this is 58small enough to warrant going ahead with this change. 59 60An alternative solution would be to leave the standard requirements as 61is, and to remove the requirements for the ``reference`` type in the 62new iterator concepts. We are not in favor of this approach because it 63extends what we see as a defect further into the future. 64