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?

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

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?

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
}

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.

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?

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.

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;

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.

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?