RFC on range design for D2

[Steven Schveighoffer]

"Andrei Alexandrescu" wrote
> Steven Schveighoffer wrote:
>> "Andrei Alexandrescu" wrote
>> I thought you stated that 'pointers' shouldn't be allowed, only ranges? 
>> In general, I agree with that, but I think the ability to use a pointer 
>> type instead of ranges has advantages in some cases.
>
> I think there's a little confusion. There's three things:
>
> 1. Ranges
> 2. Iterators
> 3. Pointers, e.g. the exact address where the object sits in memory

Yes, I have been using the terms iterator and pointer interchangably, my bad 
:)  I look at pointers as a specialized type of iterator, ones for which 
only 'dereference' is defined (and on contiguous memory types such as 
arrays, increment and decrement).

>
> My address uses 1 and drops 2. You still have access to 3 if you so need.
>
> void showAddresses(R)(R r)
> {
>     for (size_t i = 0; !r.isEmpty; r.next, ++i)
>     {
>         writeln("Element ," i, " is sitting at address: ", &(r.first));
>     }
> }

Let me explain by example:

HashMap!(uint, myResource) resources;

....

// returns something that allows me to later remove the element
auto r = resources.find(key);

useResource(r);

resources[newkey] = new myResource;

resources.erase(r);

Now, assuming that adding the new resource rehashes the hash map, what is in 
r such that it ONLY points to the single resource?  A marker saying 'only 
one element'?  Perhaps you just deleted a range you didn't mean to delete, 
when you only wanted to delete a single resource.  Perhaps r is now 
considered 'invalid'.  Granted, this example can be fixed by reordering the 
lines of code, and perhaps you don't care about the penalty of looking up 
the key again, but what if I want to save the iterator to the resource 
somewhere and delete it later in another function?  And what if the cost of 
lookup for removal is not as quick?

I think with a range being the only available 'iterator' type for certain 
containers may make life difficult for stuff like this.  I really don't 
think iterator is the right term for what I think is needed, what I think is 
needed is a dumbed down pointer.  Something that has one operation --  
opStar.  No increment, no decrement, just 'here is a reference to this 
element'  that can be passed into the container to represent a pointer to a 
specific element.

-Steve