ideas about ranges

[Steven Schveighoffer]

On Fri, 22 May 2009 20:43:22 -0400, Lionello Lunesu  
<lio at lunesu.remove.com> wrote:

> Andrei Alexandrescu wrote:
>> Steven Schveighoffer wrote:
>>> Another idea is to make the T the ref'd arg, similar to how the system  
>>> call read() works:
>>>
>>> bool popNext(ref T);
>>>
>>> This has some benefits:
>>>
>>> 1) you aren't checking a temporary for emptyness, so it fits well  
>>> within a loop construct
>>> 2) you can avoid returning a dummy element in the empty range case.
>>> 3) you avoid returning a piece of possibly large data on the stack  
>>> when it's probably just going to get copied anyways (although the  
>>> compiler can sometimes optimize this).
>>  We considered that as well. It is problematic because looking at  
>> elements always entails copying them, which is rather silly if you do  
>> it for e.g. an array.
>>  By golly, I kid you not but the interface I personally like the most  
>> is:
>>  struct ArchetypalInputRange(T)
>> {
>>     T* popNext();
>> }
>>  popNext returns a pointer to a T (the value may be reused) or null  
>> when the range is done. Iteration becomes easy and efficient for all  
>> types. An input range would still have to keep a buffer (and return a  
>> pointer to it), but things are not awkward to implement.
>>  Given the bad reputation that pointers have, I guess people wouldn't  
>> like this all that much.
>
> You don't need a pointer to T, you need a nullable T :)
> ...which doesn't exist...

No, you need a pointer.  If T is a reference type, how do you distinguish  
a null element from the end of the iteration?

-Steve