• Dibyendu Majumdar (15/15) Nov 14 2020 In this example:
• Paul Backus (7/10) Nov 14 2020 It doesn't appear to be spelled out anywhere in the language
• Dibyendu Majumdar (14/24) Nov 14 2020 Thank you.
• Paul Backus (10/22) Nov 14 2020 Yes, exactly. Symbols in an inner scope are (mostly) allowed to
• Dibyendu Majumdar (3/11) Nov 28 2020 Not only parameters, it seems that inside a function, a name
• Dibyendu Majumdar (6/9) Nov 28 2020 module scopes;
• Adam D. Ruppe (7/8) Nov 28 2020 Yes.
• Dibyendu Majumdar (7/9) Nov 28 2020 That doesn't seem to be true.
• Adam D. Ruppe (9/14) Nov 28 2020 That's overloading, not shadowing. How would you disambiguate
• Dibyendu Majumdar (7/19) Nov 28 2020 Yes I got that. I am trying to understand why it isn't ambiguous.
• Paul Backus (5/15) Nov 28 2020 The reason these do not conflict is that they are not in the same
• Dibyendu Majumdar (2/15) Nov 29 2020 Yes okay, that makes sense.

Dibyendu Majumdar <d.majumdar gmail.com> writes:

In this example:

module scopes;

int foo;
struct foo {
     int a;
}

void foo() {
     foo foo;
     foo.a = 5;
}


I see that the compiler complains about conflict in the use of 
foo.

I couldn't find the rules that D uses to decide whether a name 
conflicts or not. If I missed something please can someone point 
me to it?

Paul Backus <snarwin gmail.com> writes:

On Saturday, 14 November 2020 at 17:06:49 UTC, Dibyendu Majumdar 
wrote:
 I couldn't find the rules that D uses to decide whether a name 
 conflicts or not. If I missed something please can someone 
 point me to it?

It doesn't appear to be spelled out anywhere in the language 
spec, but the rule is that two symbols in the same scope with the 
same name conflict unless they form an overload set. The rules 
for overload sets are laid out in the sections of the spec that 
deal with functions, templates, and aliases (iirc).

Dibyendu Majumdar <d.majumdar gmail.com> writes:

On Saturday, 14 November 2020 at 17:22:13 UTC, Paul Backus wrote:
 On Saturday, 14 November 2020 at 17:06:49 UTC, Dibyendu 
 Majumdar wrote:
 I couldn't find the rules that D uses to decide whether a name 
 conflicts or not. If I missed something please can someone 
 point me to it?

 It doesn't appear to be spelled out anywhere in the language 
 spec, but the rule is that two symbols in the same scope with 
 the same name conflict unless they form an overload set. The 
 rules for overload sets are laid out in the sections of the 
 spec that deal with functions, templates, and aliases (iirc).

Thank you.

If I do this, compiler accepts it:

//int foo;
struct foo {
     int a;
}

void bar() {
     foo foo;
     foo.a = 5;
}

So if I read your reply correctly the variable 'foo' in bar() 
doesn't conflict with the struct 'foo' because it is in a 
different scope?

Paul Backus <snarwin gmail.com> writes:

On Saturday, 14 November 2020 at 17:37:48 UTC, Dibyendu Majumdar 
wrote:
 If I do this, compiler accepts it:

 //int foo;
 struct foo {
     int a;
 }

 void bar() {
     foo foo;
     foo.a = 5;
 }

 So if I read your reply correctly the variable 'foo' in bar() 
 doesn't conflict with the struct 'foo' because it is in a 
 different scope?

Yes, exactly. Symbols in an inner scope are (mostly) allowed to 
shadow symbols in an outer scope.

The one exception is that local variables are not allowed to 
shadow parameters:

void fun(int x)
{
     int x; // error
}

Dibyendu Majumdar <mobile majumdar.org.uk> writes:

On Saturday, 14 November 2020 at 17:54:17 UTC, Paul Backus wrote:

 Yes, exactly. Symbols in an inner scope are (mostly) allowed to 
 shadow symbols in an outer scope.

 The one exception is that local variables are not allowed to 
 shadow parameters:

 void fun(int x)
 {
     int x; // error
 }

Not only parameters, it seems that inside a function, a name 
cannot be re-declared in  any inner scope.

Dibyendu Majumdar <mobile majumdar.org.uk> writes:

On Saturday, 14 November 2020 at 17:06:49 UTC, Dibyendu Majumdar 
wrote:

 I couldn't find the rules that D uses to decide whether a name 
 conflicts or not. If I missed something please can someone 
 point me to it?

module scopes;

int scopes;

This is accepted by the compiler which surprised me.
Is this intentional?

Adam D. Ruppe <destructionator gmail.com> writes:

On Saturday, 28 November 2020 at 15:16:11 UTC, Dibyendu Majumdar 
wrote:
 Is this intentional?

Yes.

The general rule of thumb is if you can disambiguate the name, D 
allows it. Function params have no disambiguation so you can't 
shadow them. But module-level things can always specify the full 
name so it is fine there.

Dibyendu Majumdar <mobile majumdar.org.uk> writes:

On Saturday, 28 November 2020 at 15:24:03 UTC, Adam D. Ruppe 
wrote:
 But module-level things can always specify the full name so it 
 is fine there.

That doesn't seem to be true.

Example:

at module level:

struct scopes {}
int scopes;

Adam D. Ruppe <destructionator gmail.com> writes:

On Saturday, 28 November 2020 at 15:39:48 UTC, Dibyendu Majumdar 
wrote:
 That doesn't seem to be true.

 Example:

 at module level:

 struct scopes {}
 int scopes;

That's overloading, not shadowing. How would you disambiguate 
that in a case like:

template foo(alias a) {}

foo!scopes; // which scopes?

You can have any one but not both like this. With the module name 
though you can specify scopes.scopes or .scopes and such to 
specify.

Dibyendu Majumdar <mobile majumdar.org.uk> writes:

On Saturday, 28 November 2020 at 15:52:00 UTC, Adam D. Ruppe 
wrote:
 On Saturday, 28 November 2020 at 15:39:48 UTC, Dibyendu 
 Majumdar wrote:
 struct scopes {}
 int scopes;

 That's overloading, not shadowing. How would you disambiguate 
 that in a case like:

 template foo(alias a) {}

 foo!scopes; // which scopes?

 You can have any one but not both like this. With the module 
 name though you can specify scopes.scopes or .scopes and such 
 to specify.

Yes I got that. I am trying to understand why it isn't ambiguous. 
I don't see anything in the grammar that clarifies this.

I am guessing an unqualified name, other than if it appears in 
module statement or import statement, can never be a module name. 
Is that correct?

Paul Backus <snarwin gmail.com> writes:

On Saturday, 28 November 2020 at 15:16:11 UTC, Dibyendu Majumdar 
wrote:
 On Saturday, 14 November 2020 at 17:06:49 UTC, Dibyendu 
 Majumdar wrote:

 I couldn't find the rules that D uses to decide whether a name 
 conflicts or not. If I missed something please can someone 
 point me to it?

 module scopes;

 int scopes;

 This is accepted by the compiler which surprised me.
 Is this intentional?

The reason these do not conflict is that they are not in the same 
scope. `int scopes` is inside the module (FQN: scopes.scopes), 
whereas `module scopes` *is* the module (FQN: scopes).

Dibyendu Majumdar <mobile majumdar.org.uk> writes:

On Saturday, 28 November 2020 at 19:36:25 UTC, Paul Backus wrote:
 On Saturday, 28 November 2020 at 15:16:11 UTC, Dibyendu 
 Majumdar wrote:
 module scopes;

 int scopes;

 This is accepted by the compiler which surprised me.
 Is this intentional?

 The reason these do not conflict is that they are not in the 
 same scope. `int scopes` is inside the module (FQN: 
 scopes.scopes), whereas `module scopes` *is* the module (FQN: 
 scopes).

Yes okay, that makes sense.