RFC on range design for D2

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> "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.

I understand. My design predicates that you can't model such 
non-iterable iterators. Either you can use it to move along, in which 
case ranges will do just fine, or you can't, in which case my design 
doesn't support it.

Note that the STL does not have non-iterable iterators. I think 
constructing cases where they make sense are tenuous.


Andrei