after bug 40497, an is_iterator machinery was added to restrict the C++0x
prototypes of std::next and std::prev.

An alternative solution seems to be to use this same machinery in the
definition of iterator_traits so that when a class T is not a pointer and does
not provide iterator_category (and possibly the 4 other types),
iterator_traits<T> is empty (instead of containing 5 broken typedefs). This way
iterator_traits can work with sfinae. It allows reverting the prototypes of
next and prev to the standard ones. It is also more or less what Howard
recommends (see

Now, this would incidentally let code with user-defined distance functions work
as people expect, which has been argued against strongly in the past by Gaby
(but then his arguments would likely forbid the resolution of bug 40497).

What is your current opinion on this?

           Summary: merge is_iterator into iterator_traits
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: marc dot glisse at normalesup dot org


Reply via email to