alias can't find symbol or can't use symbol

[Jonathan M Davis via Digitalmars-d-learn]

On Sunday, 30 April 2017 at 00:17:37 UTC, Carl Sturtivant wrote:
> Consider the following.
>
> struct member
> {
>     int n;
> }
>
> struct outer
> {
>     member x;
>     alias x this;
>     alias n2 = n;
> }
>
> This does not compile: alias n2 = n;
> Error: undefined identifier 'n'

That makes perfect sense, as n is not in the scope of outer.

> On the other hand if change that into
>     alias n2 = x.n;
> then it does compile.
>
> void main()
> {
>     outer o;
>     o.n2 = 5;
> }
>
> Now this code doesn't compile: o.n2 = 5;
> Error: need 'this' for 'n' of type 'int'
>
> Given that one struct inside another is a static situation, 
> this seems unnecessarily strict. It's getting in the way of 
> some name management with `alias this`. What's the rationale 
> here?

I believe that the core problem is that an alias declaration just 
aliases a symbol - i.e. it just creates a new name for the 
symbol. And as far as I can tell,

alias n2 = x2.n;

is actually equivalent to

alias n2 = member.n;

You get exactly the same error message if that change is made. 
It's a bit like how you can call a static function with an object 
rather than the struct/class(e.g. s.foo() instead of S.foo()). 
Similarly, if you turn n into a member function, then you get an 
error like

q.d(20): Error: this for n needs to be type member not type outer

It's just aliasing the function, not creating a delegate or doing 
a syntactic conversion. If it _were_ doing a syntactic conversion 
and just making it so that everywhere you see n2, it got changed 
to x.n, then I could see code like

outer o;
o.n2 = 5;

working. But that's not how alias declarations work. They just 
create a new name for the symbol in the scope that they're 
declared. So, the symbol isn't tied to a particular instance, and 
you get the problem that you're having.

alias this is a bit different, because it isn't really aliasing 
the symbol - rather it's telling the compiler about an implicit 
conversion. So, that arguably confuses things a  bit, but for 
your example to work, normal alias declarations would need to do 
more than create a new name for a symbol, and as I understand it, 
they don't.

Now, I totally agree that it would be nice if your example would 
work, and I think that I've run into this problem before in my 
own code, but aliases would have to work a bit differently than 
they curently do for it to work. It seems like a reasonable 
enhancement request to me, but I'm not sure what Walter's take on 
it would be. He has a tendancy to see things how the compiler 
would in cases like this and not necessarily how a typical 
programmer would, so it wouldn't surprise me if he's reaction 
were that of course it wouldn't work, but I don't know. It's 
often the case that what the programmer thinks is intuitive 
doesn't really jive with how the language actually works.