Error: shadowing declaration is deprecated

[Bill Baxter]

Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message 
> news:emn3rk$828$1 at digitaldaemon.com...
>> Ah ok, good point.  This is because foreach(u; blah) is always taken to 
>> mean foreach(auto u; blah).   It's a little special case to save some 
>> typing.  I think it's a bad idea to have such a special case, but oh well. 
>> Now that you mention it I do remember ranting about this one at one point, 
>> but I wasn't annoyed enough by it to follow through.  For one it means 
>> that you can't have a loop variable in a foreach that 'escapes', which 
>> eliminates some handy patterns like
>>    char[] u;
>>    foreach(u; FPUsers) { if match(u) break; }
>>    /* use u here */
>>
>> Maybe there's some reason for this that has to do with how foreach is 
>> implemented for classes?  But I don't see how that could be the case when 
>> this certainly works:
>>    char[] u;
>>    foreach(utmp; FPUsers) { u=utmp; if match(u) break; }
>>    /* use u here */
> 
> Foreach is implemented the same way for all types, not just classes -- the 
> body is always converted to a delegate which is used as a callback in some 
> kind of apply function.  The indices are nothing but the parameter list for 
> that delegate (which is why 'inout' is possible), hence this restriction. 
> Your example works fine because nested functions can access outer function 
> variables.  In this case, u is an outer variable to the loop body.

My understanding is that it is implemented the same way for all types 
*except* for built-in arrays, which don't use the delegate mechanism and 
instead get transformed into something more like a for loop.

Anyway, that's fine and all that it's implemented that way.  It makes 
sense if you understand the implementation details.  But to the casual 
user it's confusing that for and foreach appear to follow different 
rules with regard to variables declared outside the scope.  In my 
opinion the compiler should do everything within reason to make them 
appear to have the same behavior.

But maybe in this case nothing "within reason" is possible. 
Particularly when it comes to the inout there.  Still feels to me like 
it could be better, but maybe not.

>> Anyway foreach could certainly be smarter than it is.  For instance I 
>> believe the magic 'int' return value that opApply implementations must 
>> handle and diligently return back to their caller could be eliminated with 
>> some hidden variables on the stack.  But Walter and others here don't seem 
>> to see that as a wart for some reason.
> 
> That would be nice.  It would just be a hidden variable in the enclosing 
> function, and the foreach body would just set that result to the appropriate 
> value before returning.  It would still have to return something, though, to 
> let the apply function know when to stop iterating.  A bool would work fine. 

To me passing that int value around in my opApply feels akin to manually 
manipulating vtable offests or something.  It's an implementation detail 
that I shouldn't have to worry about, and is really too unsafe for me to 
be touching in the first place.

--bb