[LLVMdev] [RFC] Add empty() method to iterator_range.

[Chandler Carruth]

Since Richard first poked me about this, I'm still debating this.

I'm torn in a bunch of different ways:

1) iterator_range is *not* a container. It shouldn't and can't be used like
one.
2) members are really hard to extend. they make templates harder not easier
because the widen the set of interfaces which *must* be on a given container
3) the concept of testing for emptiness is actually inherently useful for
all ranges, unlike many other proposed extensions to the member interface,
so maybe its OK to grow the interface in this direction
4) basing emptiness on iterators seems really bad because one of the
important utilities of ranges is that they may expose concepts which are
more flexible and efficient than a pair of iterators

However, one thing makes me inclined to say "no" to this: the benefit is
miniscule. It is too simple to just compare the iterators and not cross any
of these bridges today.

On Wed, Mar 19, 2014 at 11:57 AM, Duncan P. N. Exon Smith <
dexonsmith at apple.com> wrote:

> > This is a pattern I ran into a handful of times when range-ifying
> > parts of clang (but not so frequently that I felt it was a major win),
> > so I'm roughly in favor of the API. However, if there's been
> > standardization efforts for range, we should be sure that we're doing
> > something compatible there.
>
> There are a couple of proposals [1][2] that I can find.  It sounds like the
> exact set of methods to provide is somewhat contentious [3].  empty() seems
> pretty innocuous though.  Note that the standard proposals use std::range
> instead of std::iterator_range.
>
> In my opinion, other methods (e.g., front(), back(), and (for random access
> iterators) operator[]) would also be useful.
>

I think front, back, and [] are extremely contentious. =] While empty may
be the most innocuous, it also seems the least useful today.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140320/3357c62e/attachment.html>