Hello,

It seems impossible to define a random-access range (opIndex + length) alone. In fact, I cannot have it used by the language. Am I missing something?
Random-access looks enough to provide fonctionality for both input and bidirectional ranges without any additional method. "Lowering" for forward iteration means I guess ;-)
	for (uint i=0 ; i < coll.length ; i++) {
	    element = coll[i];
	    doSomethingWith(element);
	}
What is the reason for requiring methods of lower-power range types to be defined? (This makes 5 methods!)

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

On Tue, 14 Dec 2010 09:09:33 +0100, spir wrote:

> Hello,
> 
> It seems impossible to define a random-access range (opIndex + length)
> alone. In fact, I cannot have it used by the language. Am I missing
> something? Random-access looks enough to provide fonctionality for both
> input and bidirectional ranges without any additional method. "Lowering"
> for forward iteration means I guess ;-)
> 	for (uint i=0 ; i < coll.length ; i++) {
> 	    element = coll[i];
> 	    doSomethingWith(element);
> 	}
> What is the reason for requiring methods of lower-power range types to
> be defined? (This makes 5 methods!)
> 
> Denis
> -- -- -- -- -- -- --
> vit esse estrany ☣
> 
> spir.wikidot.com


To avoid the boilerplate, you could write a mixin that defines the iteration primitives for you.

  mixin template IterationFuncs()
  {
      int index;
      bool empty() { return index == length; }
      auto front() { return opIndex(index); }
      void popFront() { ++index; }
      // ... etc.
  }

Then you'd just have to define opIndex() and length(), and the mixin does the rest for you.

  struct MyRange(T)
  {
      T opIndex(int i) { ... }
      @property int length() { ... }
      mixin IterationFuncs!();
  }

(I haven't tested the code above, so it probably has bugs, but you get the point.)

-Lars

On Tue, 14 Dec 2010 14:15:20 +0000 (UTC)
"Lars T. Kyllingstad" <public@kyllingen.NOSPAMnet> wrote:

> On Tue, 14 Dec 2010 09:09:33 +0100, spir wrote:
> 
> > Hello,
> > 
> > It seems impossible to define a random-access range (opIndex + length)
> > alone. In fact, I cannot have it used by the language. Am I missing
> > something? Random-access looks enough to provide fonctionality for both
> > input and bidirectional ranges without any additional method. "Lowering"
> > for forward iteration means I guess ;-)
> > 	for (uint i=0 ; i < coll.length ; i++) {
> > 	    element = coll[i];
> > 	    doSomethingWith(element);
> > 	}
> > What is the reason for requiring methods of lower-power range types to
> > be defined? (This makes 5 methods!)
> > 
> > Denis
> > -- -- -- -- -- -- --
> > vit esse estrany ☣
> > 
> > spir.wikidot.com
> 
> 
> To avoid the boilerplate, you could write a mixin that defines the iteration primitives for you.
> 
>   mixin template IterationFuncs()
>   {
>       int index;
>       bool empty() { return index == length; }
>       auto front() { return opIndex(index); }
>       void popFront() { ++index; }
>       // ... etc.
>   }
> 
> Then you'd just have to define opIndex() and length(), and the mixin does the rest for you.
> 
>   struct MyRange(T)
>   {
>       T opIndex(int i) { ... }
>       @property int length() { ... }
>       mixin IterationFuncs!();
>   }
> 
> (I haven't tested the code above, so it probably has bugs, but you get the point.)
> 
> -Lars

Thank you, Lars. Nice method!

Denis
-- -- -- -- -- -- --
vit esse estrany ☣

spir.wikidot.com

Lars T. Kyllingstad Wrote:

> To avoid the boilerplate, you could write a mixin that defines the iteration primitives for you.
> 
>   mixin template IterationFuncs()
>   {
>       int index;
>       bool empty() { return index == length; }
>       auto front() { return opIndex(index); }
>       void popFront() { ++index; }
>       // ... etc.
>   }
> 
> Then you'd just have to define opIndex() and length(), and the mixin does the rest for you.
> 
>   struct MyRange(T)
>   {
>       T opIndex(int i) { ... }
>       @property int length() { ... }
>       mixin IterationFuncs!();
>   }
> 
> (I haven't tested the code above, so it probably has bugs, but you get the point.)
> 
> -Lars

Maybe this should be added to std.range?

http://d.puremagic.com/issues/show_bug.cgi?id=5351