------- 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

> 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.



Reply via email to