From: Jeffrey Hellrung <jhellrung@ucla.edu> To: boost@lists.boost.org Subject: Re: [boost] Iterator facade example could use some        changes/documentation adjustments

I think this is a valid concern, though I'm guessing this would cause problems at most infrequently.  I'm having difficulty coming up with a use case where this would be a problem.  Did you stumble upon this while writing "real" code?

It just came to mind while I was writing some of my own iterators. I wasn't even using iterator facade to do it, as I ended up using raw pointers for iterators in my use case, but I started looking at the documentation for is_convertible to figure out why they chose that conversion, and noticed the other behavior. And, though I personally haven't used that in real code, I could imagine a developer having the bright idea of converting a derived iterator into a base one thinking it will _only_ remove his need to explicitly cast the value provided by the derived iterator for whatever purpose. But, even disregarding that, on a more basic level... using is_convertible to allow conversion from non-const to const iterators is really doing more than just that. It's letting you do a host of other things as well... and though my example involved derived classes, The same would happen in cases like converting an integer iterator into a double iterator, as is_convertible returns true in that case as well. Any time the size of the types is different, it could cause problems. This is arguably a very stupid usage of iterators, but if we can enforce proper usage via compile time errors rather than runtime errors... why not?

Would this motivate the existence of an is_iterator_convertible metafunction, which is identical to is_convertible except for pointers?

- Jeff

I'm not sure what there is to gain from this, would have to see what functionality is_iterator_convertible would provide. IMO, it doesn't make a whole lot of sense to convert an iterator<A> to iterator<B> unless A == const B. Converting a const iterator to non-const iterator wouldn't enforce the access of the const iterator, and doing so in a copy constructor removes the need to const_cast for clarity. And converting an iterator<derived> to iterator<base>... or iterator<int> to iterator<double> doesn't seem to make much sense, to me. - Jacob