------- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
