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.
