Greetings!

this code,

  foreach(char[] u; FPUsers)
  {

  }

results in,

Error: shadowing declaration jic.libs.FPSDK.FindUser.u is deprecated.

Will anyone explain this to me?  I tried to do a search on it, but I couldn't anything related to this.  Found other integer arrays, but nothing about char[].  Any help would be greatly appreciated.  Thanks.

josé

jicman wrote:
> Greetings!
> 
> this code,
> 
>   foreach(char[] u; FPUsers)
>   {
> 
>   }
> 
> results in,
> 
> Error: shadowing declaration jic.libs.FPSDK.FindUser.u is deprecated.
> 
> Will anyone explain this to me?  I tried to do a search on it, but I couldn't
> anything related to this.  Found other integer arrays, but nothing about
> char[].  Any help would be greatly appreciated.  Thanks.
> 
> jos�

It means you have another variable named 'u' in the same function declared somewhere before that foreach loop.  The theory is that many times these are bugs, and when they are they can be hard to spot.

I'm not totally enamored with the feature myself, since I don't recall ever really been bitten by it, but I have happily shadowed variables in the past when it suited me.  Especially little dummy counter/placeholder variables like your 'c' above.

But anyway, that's what the error means.  Just rename 'c' to c2 or cc or d.
--bb

jicman wrote:
> Greetings!
> 
> this code,
> 
>   foreach(char[] u; FPUsers)
>   {
> 
>   }
> 
> results in,
> 
> Error: shadowing declaration jic.libs.FPSDK.FindUser.u is deprecated.
> 
> Will anyone explain this to me?  I tried to do a search on it, but I couldn't
> anything related to this.  Found other integer arrays, but nothing about
> char[].  Any help would be greatly appreciated.  Thanks.
> 
> jos�
> 

Code of the form

{
	int a;
	{
		int a;
	}
}

is not allowed. check to see if there is another variable in scope called "u". It or the "u" from the foreach needs to be renamed.

== Quote from Bill Baxter's article
> jicman wrote:
> > Greetings!
> >
> > this code,
> >
> >   foreach(char[] u; FPUsers)
> >   {
> >
> >   }
> >
> > results in,
> >
> > Error: shadowing declaration jic.libs.FPSDK.FindUser.u is
deprecated.
> >
> > Will anyone explain this to me?  I tried to do a search on it,
but I couldn't
> > anything related to this.  Found other integer arrays, but
nothing about
> > char[].  Any help would be greatly appreciated.  Thanks.
> >
> > jos�
> It means you have another variable named 'u' in the same function declared somewhere before that foreach loop.  The theory is that
many
> times these are bugs, and when they are they can be hard to spot. I'm not totally enamored with the feature myself, since I don't
recall
> ever really been bitten by it, but I have happily shadowed
variables in
> the past when it suited me.  Especially little dummy
counter/placeholder
> variables like your 'c' above.
> But anyway, that's what the error means.  Just rename 'c' to c2 or
cc or d.
> --bb

Ok, I'll buy that, but this is not working either:

char[] u;
foreach(u; FPUsers)
{
}

That should work.

jicman escribió:
> == Quote from Bill Baxter's article
>> jicman wrote:
>>> Greetings!
>>>
>>> this code,
>>>
>>>   foreach(char[] u; FPUsers)
>>>   {
>>>
>>>   }
>>>
>>> results in,
>>>
>>> Error: shadowing declaration jic.libs.FPSDK.FindUser.u is
> deprecated.
>>> Will anyone explain this to me?  I tried to do a search on it,
> but I couldn't
>>> anything related to this.  Found other integer arrays, but
> nothing about
>>> char[].  Any help would be greatly appreciated.  Thanks.
>>>
>>> jos�
>> It means you have another variable named 'u' in the same function
>> declared somewhere before that foreach loop.  The theory is that
> many
>> times these are bugs, and when they are they can be hard to spot.
>> I'm not totally enamored with the feature myself, since I don't
> recall
>> ever really been bitten by it, but I have happily shadowed
> variables in
>> the past when it suited me.  Especially little dummy
> counter/placeholder
>> variables like your 'c' above.
>> But anyway, that's what the error means.  Just rename 'c' to c2 or
> cc or d.
>> --bb
> 
> Ok, I'll buy that, but this is not working either:
> 
> char[] u;
> foreach(u; FPUsers)
> {
> }
> 
> That should work.

But probably in your code there is some other variable "u" defined, previous to the "char[] u" line. Check that.

Cheers,
Ary

jicman wrote:

> char[] u;
> foreach(u; FPUsers)
> {
> }
> 
> That should work.

the u in the foreach is a new variable. thus it shadows the outer u.

jicman wrote:
> == Quote from Bill Baxter's article
>> jicman wrote:
>>> Greetings!
>>>
>>> this code,
>>>
>>>   foreach(char[] u; FPUsers)
>>>   {
>>>
>>>   }
>>>
>>> results in,
>>>

> 
> Ok, I'll buy that, but this is not working either:
> 
> char[] u;
> foreach(u; FPUsers)
> {
> }
> 
> That should work.

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 */

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.

--bb

"Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:emn3rk$828$1@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.

If you're wondering why foreach loops are implemented this way, it's because it's a very clever solution to some iteration problems.  It makes it much easier to iterate through non-linear structures (like AAs), and it also doesn't require any allocation of an "iterator" object.  All the iteration is performed by the apply function, which makes the most sense.

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

Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup@billbaxter.com> wrote in message news:emn3rk$828$1@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

== Quote from Ary Manzana (ary@esperanto.org.ar)'s article
> jicman escribió:
> > == Quote from Bill Baxter's article
> >> jicman wrote:
> >>> Greetings!
> >>>
> >>> this code,
> >>>
> >>>   foreach(char[] u; FPUsers)
> >>>   {
> >>>
> >>>   }
> >>>
> >>> results in,
> >>>
> >>> Error: shadowing declaration jic.libs.FPSDK.FindUser.u is
> > deprecated.
> >>> Will anyone explain this to me?  I tried to do a search on it,
> > but I couldn't
> >>> anything related to this.  Found other integer arrays, but
> > nothing about
> >>> char[].  Any help would be greatly appreciated.  Thanks.
> >>>
> >>> jos�
> >> It means you have another variable named 'u' in the same
function
> >> declared somewhere before that foreach loop.  The theory is that
> > many
> >> times these are bugs, and when they are they can be hard to
spot.
> >> I'm not totally enamored with the feature myself, since I don't
> > recall
> >> ever really been bitten by it, but I have happily shadowed
> > variables in
> >> the past when it suited me.  Especially little dummy
> > counter/placeholder
> >> variables like your 'c' above.
> >> But anyway, that's what the error means.  Just rename 'c' to c2
or
> > cc or d.
> >> --bb
> >
> > Ok, I'll buy that, but this is not working either:
> >
> > char[] u;
> > foreach(u; FPUsers)
> > {
> > }
> >
> > That should work.
> But probably in your code there is some other variable "u" defined,
> previous to the "char[] u" line. Check that.
> Cheers,
> Ary

Ok, let's take a look at this small program:

void main()
{
  char[][] tArr = null;
  tArr.length = tArr.length + 1;
  tArr[0] = "hi";
  char[] u;
  foreach(u;tArr)
    printf(u);
}

As you can see, there are no other declaration of u in the program, and here is what I get when I use dmd:

 0:56:01.67>dmd test.d
test.d(7): Error: shadowing declaration test.main.u is deprecated

Ok, what is it that I am not understanding.