Property discussion wrap-up

[Zach the Mystic]

On Wednesday, 30 January 2013 at 21:41:58 UTC, Zach the Mystic 
wrote:
> On Wednesday, 30 January 2013 at 18:36:17 UTC, Dmitry Olshansky 
> wrote:
>> I have one key problem - the hidden pointer detail.
>> In other words how should it find the instance of the outer 
>> struct to to access it?
>>
>> struct A{
>> 	int a;
>> 	struct B{
>> 		void foo(){ a = 42; }
>> 	}	
>> 	B b;
>> }
>>
>> A a;
>> a.b.foo(); //how that b is supposed to know it's outer struct 
>> without the hidden pointer?
>>
>> auto x = a.b;
>> x.foo();// and now what?
>
> It seems struct B does need a pointer... and yet it only needs 
> it in compile time. "auto x = a.b" is no different from "alias 
> a.b x", because when you have no data, you have no data to 
> worry about! a.b is nothing but a namespace with full struct 
> semantics.
>
> I can only say that my intuition tells me that this is easily 
> managed. I cannot tell you what adjustments need to be made to 
> the compiler to get this to come out right.
>
> But what if B actually had some data? The only solution is to 
> have one pointer for every struct it's nested inside of. I can 
> imagine it getting tricky in this case. If it were so tricky as 
> to be prohibitive to implement, then all is not lost. You can 
> still implement zero-data structs as properties. In that case, 
> I suggest weaving the implementation in directly with the 
> Highlanders, because Highlanders will be much less appealing 
> for any other use.

What I meant with regards to weaving the implementation with the 
Highlanders is that if empty structs have access to the outer 
nest then they are fundamentally different, and being so, will 
require a syntax to distinguish them. I don't readily have 
another easy syntax, so they would be forced to monopolize the 
Highlander syntax as punishment for being so inflexible.