responses to Dave's comments

[SVN r20835]
This commit is contained in:
Jeremy Siek
2003-11-17 20:21:40 +00:00
parent f25ff7a1a4
commit 50e645261c

View File

@ -86,20 +86,32 @@ The same problem applies to ``is_swappable``.
which requires the trait to be derived from either true_type or
false_type (as of the last LWG meeting).
.. I must not have been there for that. Could you handle
giving it attention? -JGS
3. Change ``iterator_tag`` to::
template <class Value, class Reference, class Traversal>
struct iterator_tag;
The argument for ``Value`` must be the ``value_type`` of the
iterator, possibly const-qualified, ``Reference`` must be the
return type of ``operator*`` [*]_, and ``Traversal`` the
traversal tag for the iterator.
If ``iterator_tag`` is to be used as the ``iterator_category``
for iterator type ``X``, then the argument for ``Value`` must be
the ``value_type`` for iterator ``X``, possibly const-qualified
to indicate a non-writable iterator. The argument for
``Reference`` must be the
return type of ``operator*`` [*]_, and the argument for ``Traversal``
must be the traversal tag for the iterator.
.. I think the language above is still too informal. There is no
"the iterator", when considering iterator_tag in isolation.
Perhaps that language belongs in a non-normative note
.. I'm not so sure it makes sense to talk of iterator_tag in
isolation. I've added some more words to spell out the
connection between "the iterator" and the iterator_tag. -JGS
``iterator_tag<Value,Reference,Traversal>`` is required to be
convertible to both ``Traversal`` tag and also to the
``iterator_category`` type specified by the following
@ -127,6 +139,7 @@ The same problem applies to ``is_swappable``.
return output_iterator_tag;
.. I reformatted the code for legibility; sorry.
.. No problemo. -JGS
.. [*] Instead of saying "return type of operator*", we could have
said ``iterator_traits<X>::reference``. However, the standard
@ -135,6 +148,13 @@ The same problem applies to ``is_swappable``.
cases it explicitly differs from the return type of
``operator*``, for example see ``istreambuf_iterator``.
.. Hmm, istreambuf_iterator does not fit nicely into the new iterator
categories. It's reference type is charT& but the return type
of operator* is charT. In the new concepts, these are required to be
the same type. We'll have to deal with this in the
reference problem paper. -JGS
4. Change the specification of ``traversal_category`` to::
@ -195,8 +215,8 @@ The same problem applies to ``is_swappable``.
deduce the appropriate old iterator category. The
``Value`` and ``Reference`` parameters fill this need.
Note that this solution cleans up the issue that John
Maddock raised on the reflector (``c++std-lib-12187``) about the non-uniformity
of the lvalue bit.
Maddock raised on the reflector (``c++std-lib-12187``) about the
non-uniformity of the lvalue bit.
4. The changes to the specification of ``traversal_category`` are a
direct result of the changes to ``iterator_tag``.