@@ -317,16 +508,24 @@ given in the following diagram.
Like the old iterator requirements, we provide tags for purposes of
dispatching based on the traversal concepts. The tags are related via
inheritance so that a tag is convertible to another tag if the concept
-associated with the first tag is a refinement of the second tag. Our
-design reuses iterator_traits<Iter>::iterator_category as the
-access mechanism for the traversal tag. If an iterator wishes to meet
-the requirements of both a new iterator concept and an old iterator
-concept, it can use an iterator category type that inherits from both
-the the old iterator tag and the new traversal tag.
+associated with the first tag is a refinement of the second tag.
+Our design reuses iterator_traits<Iter>::iterator_category to
+indicate an iterator's traversal capability. To specify
+capabilities not captured by any old-style iterator category, an
+iterator designer can use an iterator_category type that is
+convertible to both the the most-derived old iterator category tag
+which fits, and the appropriate new iterator traversal tag.
+
We do not provide tags for the purposes of dispatching based on the
-access concepts. There are two reasons: we could not find a way to
-automatically infer the right access tags for old-style iterators and
-the need for dispatching based on the access concepts is not as great.
+access concepts, in part because we could not find a way to
+automatically infer the right access tags for old-style iterators.
+An iterator's writability may be dependent on the assignability of
+its value_type and there's no known way to detect whether an
+arbitrary type is assignable. Fortunately, the need for
+dispatching based on access capability is not as great as the need
+for dispatching based on traversal capability.
A difficult design decision concerned the operator[]. The direct
approach for specifying operator[] would have a return type of
reference; the same as operator*. However, going in this
@@ -355,7 +554,7 @@ object of type T.
for the value type T if the following expressions are valid and
respect the stated semantics. U is the type of any specified
member of type T.
-
+
@@ -402,6 +601,10 @@ to (*a).m
+
@@ -410,7 +613,7 @@ if the following expressions are valid and respect the stated
semantics. In addition, a model of
Writable Iterator must include
in its documentation the
set of value types that it allows for
output.
-
+
@@ -439,7 +642,7 @@ value types of X
A class or built-in type X models the Swappable Iterator concept
if the following expressions are valid and respect the stated
semantics.
-
+
@@ -470,7 +673,7 @@ exchanged
The Lvalue Iterator concept adds the requirement that the
reference type be a reference to the value type of the iterator.
-
+
@@ -507,7 +710,7 @@ type X, A class or built-in type X models the Incrementable Iterator
concept if the following expressions are valid and respect the stated
semantics.
-
+
@@ -544,13 +747,15 @@ semantics.
+
A class or built-in type X models the Single Pass Iterator
concept if the following expressions are valid and respect the stated
semantics.
-
+
@@ -590,13 +795,15 @@ relation over its domain
+
A class or built-in type X models the Forward Traversal Iterator
concept if the following expressions are valid and respect the stated
semantics.
-
+
@@ -637,13 +844,15 @@ the distance between iterators
+
A class or built-in type X models the Bidirectional Traversal
Iterator concept if the following expressions are valid and respect
the stated semantics.
-
+
@@ -689,6 +898,8 @@ implies r ==
+
@@ -697,7 +908,7 @@ Iterator concept if the following expressions are valid and respect
the stated semantics. In the table below,
Distance is
iterator_traits<X>::difference_type and
n represents a
constant object of type
Distance.
-
+
@@ -801,6 +1012,8 @@ ordering relation
+
@@ -861,5 +1074,11 @@ LocalWords: incrementable xxx min prev inplace png oldeqnew AccessTag struct
LocalWords: TraversalTag typename lvalues DWA Hmm JGS mis enum -->
+
+
diff --git a/doc/new-iter-concepts.rst b/doc/new-iter-concepts.rst
index 53835d4..d48f039 100644
--- a/doc/new-iter-concepts.rst
+++ b/doc/new-iter-concepts.rst
@@ -299,17 +299,27 @@ given in the following diagram.
Like the old iterator requirements, we provide tags for purposes of
dispatching based on the traversal concepts. The tags are related via
inheritance so that a tag is convertible to another tag if the concept
-associated with the first tag is a refinement of the second tag. Our
-design reuses ``iterator_traits::iterator_category`` as the
-access mechanism for the traversal tag. If an iterator wishes to meet
-the requirements of both a new iterator concept and an old iterator
-concept, it can use an iterator category type that inherits from both
-the the old iterator tag and the new traversal tag.
+associated with the first tag is a refinement of the second tag.
+
+Our design reuses ``iterator_traits::iterator_category`` to
+indicate an iterator's traversal capability. To specify
+capabilities not captured by any old-style iterator category, an
+iterator designer can use an ``iterator_category`` type that is
+convertible to both the the most-derived old iterator category tag
+which fits, and the appropriate new iterator traversal tag.
+
+.. dwa2003/1/2: Note that we are not *requiring* convertibility to
+ a new-style traversal tag in order to meet new concepts.
+ Old-style iterators still fit, after all.
We do not provide tags for the purposes of dispatching based on the
-access concepts. There are two reasons: we could not find a way to
-automatically infer the right access tags for old-style iterators and
-the need for dispatching based on the access concepts is not as great.
+access concepts, in part because we could not find a way to
+automatically infer the right access tags for old-style iterators.
+An iterator's writability may be dependent on the assignability of
+its ``value_type`` and there's no known way to detect whether an
+arbitrary type is assignable. Fortunately, the need for
+dispatching based on access capability is not as great as the need
+for dispatching based on traversal capability.
A difficult design decision concerned the ``operator[]``. The direct
approach for specifying ``operator[]`` would have a return type of
@@ -373,6 +383,10 @@ member of type ``T``.
| | |to ``(*a).m`` |
+-----------------------------------+------------------------+-------------------------+
+.. TR1: the originally-proposed requirement that typeof(*a) == R
+ was too restrictive. Now we just require that it's
+ convertible to R and that accessing a T through that conversion
+ is equivalent to accessing a T directly.
.. _Writable Iterator:
@@ -395,8 +409,6 @@ output.
| | | value types of ``X`` |
+-------------------------+--------------+----------------------------+
-
-
Swappable Iterators [lib.swappable.iterators]
---------------------------------------------
@@ -472,6 +484,8 @@ semantics.
| |``incrementable_traversal_tag``| |
+--------------------------------+-------------------------------+--------------------+
+.. TR1: incrementable_iterator_tag changed to
+ incrementable_traversal_tag for consistency.
Single Pass Iterators [lib.single.pass.iterators]
-------------------------------------------------
@@ -502,6 +516,9 @@ semantics.
| |``single_pass_traversal_tag``| |
+--------------------------------+-----------------------------+---------------------------+
+.. TR1: single_pass_iterator_tag changed to
+ single_pass_traversal_tag for consistency
+
Forward Traversal Iterators [lib.forward.traversal.iterators]
-------------------------------------------------------------
@@ -533,6 +550,9 @@ semantics.
| |``forward_traversal_tag`` | |
+---------------------------------------+-----------------------------------+---------------+
+.. TR1: forward_traversal_iterator_tag changed to
+ forward_traversal_tag for consistency
+
Bidirectional Traversal Iterators [lib.bidirectional.traversal.iterators]
-------------------------------------------------------------------------
@@ -570,6 +590,8 @@ the stated semantics.
| | | |
+------------------------------------+---------------------------------------------+---------------------+
+.. TR1: bidirectional_traversal_iterator_tag changed to
+ bidirectional_traversal_tag for consistency
Random Access Traversal Iterators [lib.random.access.traversal.iterators]
-------------------------------------------------------------------------
@@ -635,6 +657,8 @@ constant object of type ``Distance``.
| |``random_access_traversal_tag`` | | |
+-------------------------------------------+-------------------------------------------------+-------------------------+----------------------+
+.. TR1: random_access_traversal_iterator_tag changed to
+ random_access_traversal_tag for consistency
Addition to [lib.iterator.synopsis]
diff --git a/doc/sources.py b/doc/sources.py
new file mode 100644
index 0000000..a69b4a7
--- /dev/null
+++ b/doc/sources.py
@@ -0,0 +1,18 @@
+# This is where we list the ReStructuredText source files that form
+# the book. When you're ready to expose a new chapter, add the
+# filename here and put links in index.rst
+
+sources = [
+'counting_iterator.rst',
+'facade-and-adaptor.rst',
+'filter_iterator.rst',
+'function_output_iterator.rst',
+'index.rst',
+'indirect_iterator.rst',
+'iterator_adaptor.rst',
+'iterator_facade.rst',
+'new-iter-concepts.rst',
+'permutation_iterator.rst',
+'reverse_iterator.rst'
+ ]
+