Dave Abrahams wrote:
I don't think you can evaluate these choices just by looking at the implementations. Before anyone else votes option 1, I'd like to see
Well, I'm not so sure I like option 1 anymore... if option 1 was an oversight in STL then there is no sense in perpetuating the specification error in Boost.Algorithm (perhaps Boost.Algorithm should then go with option 2 and explain the rationale of why it's different than what STL does for example with std::find).
somebody write the description of the algorithm, including the concept requirements. With option 2, we know that == has to be an equivalence relation. The semantics in option 1 are a lot fuzzier.
Good point! I'll try to start :) template< typename Iter, typename Val > requires InputIterator<Iter>, EqualityComparable<iterator_traits<Iter>::value_type, Val> bool none_of_equal ( Iter first, Iter last, Val const& val ) ; // option 1a template< typename Iter > requires InputIterator<Iter>, EqualityComparable<iterator_traits<Iter>::value_type> bool none_of_equal ( Iter first, Iter last, iterator_traits<Iter>::value_type const& value ) ; // option 2 Essentially, I'd think option 1 requires operator== that satisfies has_equal_to<iterator_traits<Iter>::value_type, Val> while option 2 requires operator== that satisfies has_equal_to<iterator_traits<Iter>::value_type>. The alternative would be for option 1 to require instead: template< typename Iter, typename Val > requires InputIterator<Iter>, EqualityComparable<iterator_traits<Iter>::value_type>, Convertible<Val, iterator_traits<Iter>::value_type> bool none_of_equal ( Iter first, Iter last, Val const& val ) ; // option 1b What do you think? Thanks, --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Algorithm-design-question-tp3876424... Sent from the Boost - Dev mailing list archive at Nabble.com.