https://issues.dlang.org/show_bug.cgi?id=24273

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl
           Hardware|x86                         |All
                 OS|Windows                     |All

--- Comment #1 from Dennis <dkorpel@live.nl> ---
Reduced example:

```D
int XVar;

struct Mst
{
    typeof(XVar) XVar;
}
```

The issue seems that `typeof(XVar)` is resolved after adding `XVar` to the symbol table of `Mst`. I wonder if that's done deliberately to make something else work.

--

https://issues.dlang.org/show_bug.cgi?id=24273

--- Comment #2 from anonymous4 <dfj1esp02@sneakemail.com> ---
The problem usually happens as:

alias int XVar;
struct Mst
{
    XVar XVar;
}

As you can see there's an ambiguity who is who.
Usually it's possible to disambiguate with FQN:

struct Mst
{
    .XVar XVar;
}

Stack variables have no FQN, so give them a different name

alias XVar XVar2;
struct Mst
{
    typeof(XVar2) XVar;
}

--

https://issues.dlang.org/show_bug.cgi?id=24273

--- Comment #3 from bmqawsed4@gmail.com ---
(In reply to anonymous4 from comment #2)
> The problem usually happens as:
> 
> alias int XVar;
> struct Mst
> {
>     XVar XVar;
> }
> 
> As you can see there's an ambiguity who is who.
> Usually it's possible to disambiguate with FQN:
> 
> struct Mst
> {
>     .XVar XVar;
> }
> 
> Stack variables have no FQN, so give them a different name
> 
> alias XVar XVar2;
> struct Mst
> {
>     typeof(XVar2) XVar;
> }

Unfortunately I do not see any ambiguity in my original code.
It _is_ confusing (the situation of the same name being used both in the main
function and the sub-function was an accident, not intentional).
But I cannot see what rule of D has been broken.
To me, if nothing else, D's scope rules should have stopped any problems.

--