un-requested compiler optimisations

[Steven Schveighoffer]

On Thu, 14 Apr 2011 14:24:41 -0400, spir <denis.spir at gmail.com> wrote:

> On 04/14/2011 06:57 PM, Andrej Mitrovic 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, etc. E.g:
>>
>> auto a = [1, 2];
>> auto b = retro(a);
>> auto c = retro(b);
>> auto d = retro(c);
>>
>> Under the surface, I assume calling d.front would mean the following  
>> calls:
>> d.front()->c.back()->b.front()->a.back()
>>
>> 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?
>
> If it does optimise, then it is definitely a compiler bug. Since you  
> *explicitely* ask for a double reverse, it *must* just do it.  
> Suppressing them is here just breaking the language's semantics!

I feel like people aren't looking at my post :)

retro *specifically* returns the source range if you retro it again.

 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;
     }
...

-Steve