Properties

[Yigal Chripun]

Chad J wrote:
> Miles wrote:
>> Both the getter and the setter should return an rvalue. Properties exist
>> so that they are interchangeable with real member variables. Something
>> that is possible with member variables MUST also be possible with
>> properties, in a transparent way for any code outside the class.
>>
>
> I agree, though let's not fool ourselves, there is at least one corner case:
>
> property int foo
> {
>      get{ ... }
>      set{ ... }
> }
>
> auto bar =&foo;
> what happens when someone writes this?
>
> I've tried this in C# and it is simply forbidden.  I am OK with this,
> though I'd love it if there was a better way.

that's solvable. as I noted in a previous post, a property seems to me 
to be mainly syntax sugar for a struct like in the following snippet:

class A {
	struct Prop {
		int internal;
		int opCall() { return internal; }
		void opAssign(int value) { internal = value; }
	}
	public Prop prop;
	...
}

void main() {
	auto a = new A;
	int num = a.prop;
	a.prop = 9;
	auto foo = &a.prop; // what happens here?
	...
}

foo can be the address of "prop" (struct instance) in the above code.
this means that:
*foo = ...; is translated to *foo.opAssign(...);
and similarly: auto bar = *foo; will be auto bar = *foo.opCall();

the only issue here is what will be the type of foo if D provides the 
syntax sugar for all this. maybe define such types as special property 
types - for a given property "foo" in class "Bar" the type of the 
property will be "Bar.__fooPropertyType".