Are iterators and ranges going to co-exist?

[Peter Alexander]

On 20/07/10 2:52 PM, Andrei Alexandrescu wrote:
> I think there's a confusion somewhere. You may want to check out the
> SList definition in std.algorithm. A SList range is exactly one pointer
> thick. With singly-linked lists it's the iterator approach that is
> wasteful because it canonically transports a null pointer as end().

That wastefulness in C++ does not need to be replicated in D. 
Iterators/cursors would merely be abstract pointers, with ranges still 
providing the necessary abstractions for range traversal.


>> 2. I often store C++ iterators in container elements so that I can
>> quickly remove them when I want to. How can I do this with ranges? I
>> have to waste an extra word?
>
> Yes. What was the largest container of
> iterators-in-another-container-that-I-want-to-remove-later?

Arbitrarily large.

For example, in a physics system, each physics object might store an 
iterator to the PhysicsManager's container, so that it can quickly 
remove itself from the linked-list (or whatever container it uses). 
There's really no limit to how many physics objects there may be -- 
could easily be in the tens or hundreds of thousands, if not more.


> This is a rehash of the indexing argument. If interested in saving
> memory, you may want to use pointers, which, agreed, can only point to
> one element so they aren't as powerful as iterators. (But then you'd
> seldom want to modify an iterator in such a structure.) I don't think
> such scenarios are compelling enough to warrant introducing iterators
> alongside ranges.

Pointers are fine for arrays, but not lists, or sets etc. That's why you 
need iterators/cursors as an abstraction of pointers.

And yes, it is a rehash of the indexing argument, because that's the 
only argument. Indexing is what iterators/cursors do, so no argument 
could be anything other than an indexing argument. I'm just trying to 
provide examples of where indexing is needed.


> I've always thought that that chapter is rather weak. When did you use
> cycle_to last time?

It doesn't matter if its rarely (if ever) used; the point is that if you 
wanted to use it, you wouldn't be able to define it in a way that 
reflected its purpose.


> I agree (with qualifications) with the truthiness of the statement, but
> not with the alleged dimension of the problem. Also, like many one-sided
> arguments, this one presents introducing iterators as an all-win deal
> and neglects the associated costs.

Well, you asked me to present arguments for iterators, not against ;-)

I don't deny that there is an cost in implementing iterators, and I 
certainly appreciate the effort that you have put into developing 
Phobos. I wouldn't argue for iterators/cursors if I didn't believe their 
addition would benefit Phobos, and D in general.

Out of interest (with the understanding that you accept at least that 
iterators are useful in some situations), are there any other reasons 
that you argue against them, other than implementation costs?