alias can't find symbol or can't use symbol
Carl Sturtivant via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Thu May 4 07:00:40 PDT 2017
On Wednesday, 3 May 2017 at 09:04:07 UTC, Jonathan M Davis wrote:
>
> 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.
Thanks, that was enlightening. That said, if alias this really
did bring n into the outer scope in the specific case when it's a
variable in an embedded struct then `alias n2 = n` in the outer
scope would work in the ordinary way. After all,
struct fakeOuter
{
int n;
alias n2 = n;
}
void main()
{
fakeOuter o;
o.n2 = 5;
}
compiles and runs fine. And presumably as it's a struct being
embedded here
struct member
{
int n;
}
struct outer
{
member x;
alias x this;
//alias n2 = n;
}
the binary layouts of fakeOuter and outer are the same, so the
rename is harmless because it has a simple interpretation in
regular D without `alias this`.
More information about the Digitalmars-d-learn
mailing list