On Sunday, 23 June 2013 at 14:47:17 UTC, Andrei Alexandrescu
wrote:
On 6/23/13 7:39 AM, Andrei Alexandrescu wrote:
Again, we can make things work by introducing a primitive for
bidirectional ranges:
R before(R r1, R r2);
Assuming r2 is reachable from r1, returns the portion of r1
that lies
before r2. (Definition: a range r2 is reachable from another
range r1 if
calling r1.popFront() repeatedly will at some point make
r1.front and
r2.front refer to the same value.)
The question is, should we add this primitive? There's
discussion on adding ranges to C++, and discussion inevitably
reaches an impasse when it gets to this particular matter.
I personally think we should and am amazed that we made it so
far without that primitive. However, unlike others, I don't
think it's an essential matter. Some C++ people tend to be
apprehensive when they figure they can do something with
iterators that's not doable with ranges.
Andrei
Just for the record (because I'm the one that usually brings this
up), I think ranges are a big win overall. I just find it
frustrating every time the "always shrink never grow" problem
gets in my way of writing simple and efficient algorithms.
"before" might work, but it would also introduce a new primitve,
as well as a new trait ("isSpliceable?"). There is a real gain to
cost ratio, which I'm not sure is worth it. The semantics for it
would also be kind of complicated: you'd have "before", "after",
"beforeIncluding", "merge"...
I'm wondering if something along the lines of an "iterable" range
might not be much more simple? Probably not :(
