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.