Dear all, The plan is to include range-based overloads of std algorithms in the next boost.range. We have several options for specifying the return type of functions that normally return an iterator that I would like your feedback on. 1. leave the return type as it is. 2. return an iterator_range describing the range [found,end) this allows us to do stuff like namespace br = boost::ranges; br::erase( rng, br::unique(rng) ); 3. inspired by John Torjo's range lib, provide a whole list of possible return values: std::vector<int> v; namespace br = boost::ranges; br::unique(v); br::unique<br::return_found>(v); br::unique<br::return_next>(v); br::unique<br::return_prior>(v); br::unique<br::return_begin_found>(v); br::unique<br::return_begin_next>(v); br::unique<br::return_begin_prior>(v); br::unique<br::return_found_end>(v); br::unique<br::return_next_end>(v); br::unique<br::return_prior_end>(v); the default would be the range [found,end), but the you can pick different slices or simply iterators. In the above scheme, "found" is the iterator normally returnes by the algorithm, "next" means boost::next(found) and "prior" means boost::prior(found). The advantage of the latter approach is - flexibility/power - safety (we can tjeck that next(found) and prior(found) stays in range) The disadvantage is that it will require twice as many overloads in C++03 (since we can't put defaults template arguments in function templates). Any opinions? -Thorsten