ceph/src/boost/libs/iterator/doc/ref_problem.rst

   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.