VLERange: a range in between BidirectionalRange and RandomAccessRange

Steven Schveighoffer schveiguy at yahoo.com
Wed Jan 19 12:24:39 PST 2011


On Tue, 18 Jan 2011 01:11:04 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 1/17/11 11:48 PM, Jonathan M Davis wrote:
>> On Monday 17 January 2011 15:13:42 spir wrote:
>>> See range bug evoked above. opApply is the only workaround AFAIK.
>>> Also, ranges cannot yet provide indexed iteration like
>>> 	foreach(i, char ; text) {...}
>>
>> While it would be nice at times to be able to have an index with  
>> foreach when
>> using ranges, I would point out that it's trivial to just declare a  
>> variable
>> which you increment each iteration, so it's easy to get an index even  
>> when using
>> foreach with ranges. Certainly, I wouldn't consider the lack of index  
>> with
>> foreach and ranges a good reason to use opApply instead of ranges.  
>> There may be
>> other reasons which make it worthwhile, but it's so trivial to get an  
>> index that
>> the loss of range abilities (particularly the ability to use such  
>> ranges with
>> std.algorithm) dwarfs it in importance.
>>
>> - Jonathan M Davis
>
> It's a bit more difficult than that. When iterating a variable-length  
> encoded range, what you need more than the current item being iterated  
> is the physical offset reached inside the range. That's not all that  
> difficult either as the range can always provide an extra primitive, but  
> a bit annoying (e.g. because it makes iteration with foreach impossible  
> if you want the index, unless you return a tuple with each step).
>
> At any rate, I agree with two things - one, we need to fix the foreach  
> situation. Two, even before we find a fix, at this point committing to  
> iteration with opApply essentially commits the iteratee to an island  
> where all basic algorithms need to be reinvented from first principles.

opApply in no way disables the range interface.  It simply is used for  
foreach.  So the only "algorithm" which is different is foreach.  If you  
use the range primitives, opApply is nowhere to be found.

That being said, we have an annoying situation in all this.  opApply  
cannot be used to foreach using indexes *and* ranges are used to foreach  
elements.  If one opApply is found, the compiler gives up on using the  
range functions for foreach (this is reflected in my most recent string_t  
code).  This means you will have to implement a "wrapper" opApply around  
the range primitives in order to also implement indexing foreach.

-Steve


More information about the Digitalmars-d mailing list