"David Abrahams" <dave@boost-consulting.com> wrote in message news:ur7g69ifb.fsf@boost-consulting.com... | "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | | > "Eric Niebler" <eric@boost-consulting.com> wrote in message | > news:428926DB.2090108@boost-consulting.com... | > | | > | | > | Yes. It's exactly the same situation. You are giving collection<X> | > | different semantics than collection<Y>. | > | > I guess my objection is to the use "exactly". | > | > If I have | > | > template< class T > | > class my_vec | > { | > std::vector<T> vec; | > }; | > | > then I might need some traits for dealing with the bool case. | | What kind of traits? the kind of traits that you usually use when dealing with vector<bool>. :-) maybe you would replace vector<bool> with vector<int> under the hood. | > If I have | > | > template< class Range, class OutIter > | > void copy( const Range&, OutIter ); | > | > then I just need to be able to say what a Range means. | | Yes, that's what makes your case worse. It doesn't just change the | interface details as with vector<T>, it changes the fundamental | meaning of T[N], leading to potential undefined behavior in some very | common cases. are you saying that the couldn't happen if we change the defaults? Personally I don't care much about how most arrays are treated... but I do think having to write find( rng, as_string("foo") ); is simply wierd and would be much more common than fiddling with fixed-sized arrays with various sentinels. -Thorsten