On Saturday, 21 April 2012 at 13:32:28 UTC, Marco Leise wrote:
> Am Thu, 19 Apr 2012 18:58:26 +0200
> schrieb "Roman D. Boiko" <rb@d-coding.com>:
>
>> I doubt specifying symbol it would be any better than location. For example, you would not be able to rename a local variable or any other symbol nested in a function.
>
> Yes you can! Try to compile this:
>
> 	void x() {
> 		int i = 1;
> 		void y() {
> 			int i = 2;
> 			{
> 				int i = 3;
> 			}
> 		}
> 	}
>
> Prints: Error: shadowing declaration x.y.i is deprecated
> Local variables have unique names and creating duplicate names is deprecated since a while.

I guess x.y.i is just a convenience naming used by DMD, and it does not appear in specification.

Also, Artur Skawina provided a nice counter-example where it would not work.

I'll answer you both here...

Am Sat, 21 Apr 2012 16:11:02 +0200
schrieb Artur Skawina <art.08.09@gmail.com>:

> On 04/21/12 15:32, Marco Leise wrote:
> > Am Thu, 19 Apr 2012 18:58:26 +0200
> > schrieb "Roman D. Boiko" <rb@d-coding.com>:
> > 
> >> I doubt specifying symbol it would be any better than location. For example, you would not be able to rename a local variable or any other symbol nested in a function.
> > 
> > Yes you can! Try to compile this:
> > 
> > 	void x() {
> > 		int i = 1;
> > 		void y() {
> > 			int i = 2;
> > 			{
> > 				int i = 3;
> > 			}
> > 		}
> > 	}
> > 
> > Prints: Error: shadowing declaration x.y.i is deprecated
> > Local variables have unique names and creating duplicate names is deprecated since a while.
> 
>    void x() {
>       int i = 1;
>       {
>          int i = 2;
>          writeln(i);
>       }
>       writeln(i);
>    }
> 
> artur

That gives the same error message as before for me. I'm using GDC with DMD 2.057 frontend. Maybe the behavoir has changed. :-(

Am Sat, 21 Apr 2012 16:28:15 +0200
schrieb "Roman D. Boiko" <rb@d-coding.com>:

> On Saturday, 21 April 2012 at 13:32:28 UTC, Marco Leise wrote:
> > Am Thu, 19 Apr 2012 18:58:26 +0200
> > schrieb "Roman D. Boiko" <rb@d-coding.com>:
> >
> >> I doubt specifying symbol it would be any better than location. For example, you would not be able to rename a local variable or any other symbol nested in a function.
> >
> > Yes you can! Try to compile this:
> >
> > 	void x() {
> > 		int i = 1;
> > 		void y() {
> > 			int i = 2;
> > 			{
> > 				int i = 3;
> > 			}
> > 		}
> > 	}
> >
> > Prints: Error: shadowing declaration x.y.i is deprecated Local variables have unique names and creating duplicate names is deprecated since a while.
> 
> I guess x.y.i is just a convenience naming used by DMD, and it does not appear in specification.
> 
> Also, Artur Skawina provided a nice counter-example where it would not work.

I just returned from the toilet where I flushed down this idea, because it doesn't work with overloads:

void x(int i) { ... }

void x(float i) { ... }

"x.i" is ambiguous to the refactoring tool. It would only work on the mangled names and before I go into the depths of what to do with extern(C) and so on... we can just go with the line/column lookup of symbols.

-- 
Marco

On 2012-04-21 15:32, Marco Leise wrote:
> Am Thu, 19 Apr 2012 18:58:26 +0200
> schrieb "Roman D. Boiko"<rb@d-coding.com>:
>
>> I doubt specifying symbol it would be any better than location.
>> For example, you would not be able to rename a local variable or
>> any other symbol nested in a function.
>
> Yes you can! Try to compile this:
>
> 	void x() {
> 		int i = 1;
> 		void y() {
> 			int i = 2;
> 			{
> 				int i = 3;
> 			}
> 		}
> 	}
>
> Prints: Error: shadowing declaration x.y.i is deprecated
> Local variables have unique names and creating duplicate names is deprecated since a while.
>

It's possible to have an instance variable and a local variable with the same name.

-- 
/Jacob Carlborg

> It's possible to have an instance variable and a local variable with the same name.

According to Marco's idea, those would be qualified differently: className.x vs className.funcName.x, but he recently provided an example where that is ambiguous.

Also it would be a problem for symbols declared inside anonimous members.

In general, I like symbol location ("file.d:50:7"). It should always be available to the tool which uses API.

On Thursday, 19 April 2012 at 16:38:31 UTC, Marco Leise wrote:
> Doesn't the D module system make symbols unique?

---
void someFunction() {
  {
    int someVariable = 3;
    // ...
  }
  {
    int someVariable = 1000;
    // ...
  }
}
---

How do you target the someVariable symbol from the second block?

David