On Sunday, June 23, 2013 07:47:16 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.
I think that we should be very leery of any case where iterators can do more than ranges. That doesn't necessarily mean that when we find something that iterators can do that ranges can't that we should add something new to ranges, but I think that when we find such cases, we should look at them very closely and figure out the best way to work around the problem and how critical a problem it is. There's also a definite cost to adding new range primitives, so I don't think that we want to jump the gun in favor of either adding or not adding new range primitives in order to overcome deficiencies in comparison to iterators. Unfortunately, I never got around to reading the rfind discussion, so I don't know the details on that (I really should go back and read it), but not being able to do rfind is a major negative IMHO. Bidirectional ranges in general suffer when it comes to doing stuff with their back end, and I think that that becomes particularly clear when doing stuff with containers. So, we may really want to look at what we can do to improve support for stuff on the back end of ranges without having to add a whole lot of new stuff to do it. However, I'll have to study up on the suggested before primitive before I can really comment on whether that particular primitive is something that we should add or not. Regardless, I think that we would do well to play around more with ranges and std.container in order to determine where the std.container API is weak with regards to ranges. In some cases, that probably means improving the API. In others, it may entail looking closer at whether we need to make any adjustments to the range primitives. Hopefully, we can make everything work well with little to no adjustments to the range API itself, but thus far, containers appear to be one area where iterators are actually considerably better than ranges (at least when it comes to using the iterator or range with the container's functions rather than simply iterating over the elements or passing the iterators or ranges to functions unrelated to the container). - Jonathan M Davis
