------- Comment #4 from marc dot glisse at normalesup dot org 2010-09-06 11:01 ------- (In reply to comment #3) > Well, I think we are comparing two changes of very different impact and size.
You are right. > 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... I completely agree here. After the removal of concepts, the library is in need of more concept-related work in the standard, it shouldn't be up to the implementers. > 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. Ok. It seemed safe enough to me (especially since some other implementations do it), so I thought I should ask. > Do you have in mind a simpler > way to implement the "smart" iterator_traits? No, I was going with the small hierarchy (ie keep the partial specializations for pointers, and have the generic implementation derive from helper<Iter, has_iterator_category<Iter>::value> where helper is empty by default and has a partial specialization for T,true that contains 5 typedefs). It looked like the safest option. Feel free to close the bug if you think it is a bad idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45549
