------- Comment #3 from paolo dot carlini at oracle dot com  2010-09-06 09:42 
(In reply to comment #2)
> It doesn't seem less conforming than what is used for
> next/prev.

Well, I think we are comparing two changes of very different impact and size.
In the case of next / prev we have two functions, completely new in C++0x,
getting a bit of constraining in the return type, no additional defaulted
template parameters, only constraining in the return type: I would argue tha,
in general, the way we are living the post-concepts era, this is more or less
something the user looking inside headers of C++ library implementations is
going to find in *many* more places than those where the Standard explicitly
talks about "does not participate to overload resolution". I can also add that
this very thing makes me a little nervous, but I didn't raise the issue
explicitly anywhere, thus... Anyway, in the other case, we are talking about
changing a fundamental building block of the library. Certainly we would do
that only in C++0x mode, agreed, still we are diverging more from C++03 in an
area where the Standard is *not* diverging at all: as far as I can see, either
we could use a defaulted template parameter with the enable_if on __is_iterator
for the default; or we could create a small hierarchy, without enable_if. This
is not something I would deliver for C++03 too, after so many years with a
straightforward implementation, definitely not. Do you have in mind a simpler
way to implement the "smart" iterator_traits?



Reply via email to