Recommendations on avoiding range pipeline type hell

[Chris Piker]

Hi D

Since the example of piping the output of one range to another 
looked pretty cool, I've tried my own hand at it for my current 
program, and the results have been... sub optimal.

Basically the issue is that if one attempts to make a range based 
pipeline aka:

```d
auto mega_range = range1.range2!(lambda2).range3!(lambda3);
```
Then the type definition of mega_range is something in the order 
of:

```d
   TYPE_range3!( TYPE_range2!( TYPE_range1, TYPE_lamba2 ), 
TYPE_lambda3));
```
So the type tree builds to infinity and the type of `range3` is 
very much determined by the lambda I gave to `range2`.  To me 
this seems kinda crazy.

To cut through all the clutter, I need something more like a unix 
command line:
```bash
prog1 | prog2 some_args | prog3 some_args
```
Here prog2 doesn't care what prog1 *is* just what it produces.

So pipelines that are more like:

```d
ET2 front2(ET1, FT)(ET1 element, FT lambda){ /* stuff */ }
ET3 front3(ET2, FT)(ET2 element, FT lambda){ /* stuff */ }

void main(){

   for(; !range1.empty; range1.popFront() )
   {
     ET3 el3 = front3( front2(range1.front, lambda2), lamda3) );
     writeln(el3);
   }
}
```

But, loops are bad.  On the D blog I've seen knowledgeable people 
say all loops are bugs.  But how do you get rid of them without 
descending into Type Hell(tm).  Is there anyway to get some type 
erasure on the stack?

The only thing I can think of is to use Interfaces and Classes 
like Java, but we don't have the automagical JVM reordering the 
heap at runtime, so that means living life on a scattered heap, 
just like python.

Is there some obvious trick or way of looking at the problem that 
I'm missing?

Thanks for your patience with a potentially dumb question.  I've 
been working on the code for well over 12 hours so I'm probably 
not thinking straight it this point.

Cheers all,