So why doesn't popFront return an element?

[Steven Schveighoffer]

On Thu, 14 Apr 2011 12:57:10 -0400, Andrej Mitrovic  
<andrej.mitrovich at gmail.com> wrote:

> This leads me to another question I've always wanted to ask. A call such  
> as:
>
> auto b=map!foo(map!bar1(map!bar2(a));
>
> This constructs a lazy range. What I'm wondering is if there are any
> performance issues when constructing long chains of ranges like that,
> since this basically routes one function to the next, which routes to
> the next

Of course.  Ranges are very dependent on inlining for their performance  
benefit.  Which means you are depending on the compiler inlining the code  
in order to achieve good performance.  The compiler doesn't always inline,  
and I'm not sure how deep it can go.

> Or another example:
> auto b = retro(retro(a));
>
> Can the compiler optimize the second case and convert b.front to just
> do one field access?

 from std.range:

auto retro(Range)(Range r)
if (isBidirectionalRange!(Unqual!Range))
{
     // Check for retro(retro(r)) and just return r in that case
     static if (is(typeof(retro(r.source)) == Range))
     {
         return r.source;
     }
...

So yeah, it can be optimized somewhat.

-Steve