> I'm trying to understand the design of ranges. Why does popFront only set the front() property to return the next element in the range? Why not return the element in the call to popFront right away? > > For example code like this (which doesn't work since popFront doesn't return): > void main() > { > int[] a = [1, 2]; > auto b = a.popFront; > assert(a == [2]); > assert(b == 1); > } > > Isn't it wasteful to have to call both popFront() and front() to > simultaneously remove an element from a range and return it? I mean it's an extra function call, right?
Those ranges are intended for functional programming! Most of the time, not returning anything means much much less work. Most ranges you'll encounter are _lazily_ evaluated. Eg: int[]a=[1,2,...]; auto b=map!foo(map!bar1(map!bar2(a)); auto c=chain(a,b); auto d=zip(a,b); auto e=zip(take(repeat(d),c.length));//note infinite range here... //etc, you get the idea Note that this code NEVER actually calls any of foo or bar1/bar2. (if this was not so, the code would enter an infinite loop at repeat(d)) It keeps not calling them when you call popFront(). (why would you want to do this anyways? I think it has only few applications, one of them is the implementation of opApply or new lazy range returning functions). When you now do e.front(), suddenly, a lot of stuff gets computed, so that you get a look at the first element of the range, again you usually don't really want to do this. It is more likely that you will call "take" or a fold/reduce on that range.