Re: Interest in a Unicode library for Boost?

From: Gavin Lambert (boost_at_[hidden])
Date: 2019-10-30 04:06:00

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.