On 30/10/2019 15:03, Jon Kalb wrote:
On Oct 29, 2019, at 4:26 PM, Gavin Lambert wrote:
Returning end of range on failure is incredibly inconvenient (for the consumer; granted it's usually more convenient for the algorithm implementer), and I'd be happier if STL algorithms didn't do that either.
“incredibly inconvenient”?
Is it possible that you are over stating your case?
Granted most existing algorithms require making two calls to the collection to get .begin() and .end(), which requires assigning the collection to some lvalue -- and once you've done that, the inconvenience is small (though "== list.end()" is still a bit ugly). But once you start working with range-based rather than iterator-based algorithms, it happens a lot more frequently that your collection is an rvalue that you don't want to have to assign to an lvalue -- but you end up having to do so just so that you can get its .end() to check for failure. Or you end up writing a helper method just so that you can have a named parameter lvalue without cluttering the original source. (Already cited in this thread was a similar example for string rvalues, where npos was more convenient than end(). Granted strings are more often rvalues than collections are, but the principle applies to both.) I'm sure many people have written helper methods to avoid having to write "map.find(key) == map.end()" patterns repeatedly. And for associative containers in particular, an interface based around Optional or Outcome would be a lot more convenient than one based around iterators.