www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Error: shadowing declaration is deprecated

reply jicman <jic mail.com> writes:
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é
Dec 23 2006
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Dec 23 2006
parent reply jicman <jic mail.com> writes:
== 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.
Dec 24 2006
next sibling parent reply Ary Manzana <ary esperanto.org.ar> writes:
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
Dec 24 2006
parent reply %u <jic mail.com> writes:
== 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.
Dec 24 2006
parent jicman <jic mail.com> writes:
Sorry, didn-t read the other posts.  ignore this post.


== Quote from %u (jic mail.com)'s article

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


Sorr
Dec 24 2006
prev sibling next sibling parent BCS <BCS pathilink.com> writes:
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.
Dec 24 2006
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Dec 24 2006
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"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.
Dec 24 2006
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Dec 24 2006
prev sibling parent BCS <BCS pathilink.com> writes:
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.
Dec 23 2006