Re: Possible @property compromise

[Zach the Mystic]

On Saturday, 2 February 2013 at 06:04:01 UTC, TommiT wrote:
On Saturday, 2 February 2013 at 03:50:49 UTC, Zach the Mystic 
wrote:
assert(A.B.C.myMemberFunction(a, a.b, a.b.c) == 3);

That wouldn't compile, so you must mean:

assert(a.b.c.myMemberFunction(a, a.b, a.b.c) == 3);

You're right. I don't know how the compiler stores the name of 
the function I meant underneath the hood. But it must such a 
mechanism for naming A.B.C.myMemberFunction, which is nothing  
more than a function which takes a pointer, or in this case a few 
pointers, to instances of the appropriate classes. Non-static 
member functions generally must take pointers to instances of 
their types. The only difference between this:

struct A
{
  int _a;
  int getA() { return _a; }
}

And this:

struct A
{
  int _a;
}
int getA(ref A a) { return a._a; }

Is that the compiler does the work of including the hidden 
pointer automatically in the first case, and also encloses getA 
into a, I hesitate to say it too loud now... namespace, so that 
it can't just be reached from anywhere.


What do you suppose would happen if I wrote the following?

struct A
{
  int _a = 1;
  B b;
  struct B
  {
    int _b = 1;
    C c;
    struct C
    {
      int _c = 1;
      int myMemberFunction() { return _a + _b + _c; }
    }
    static int otherFunction()
    {
      C cc;
      return cc.myMemberFunction();
    }
  }
}

void main()
{
  int i = A.B.otherFunction();
}

I was simply using A.B.C.myMemberFunction as a shorthand for 
whatever name the compiler uses underneath the hood to represent 
the non-static version of the function.