Possible @property compromise

Zach the Mystic reachBUTMINUSTHISzach at gOOGLYmail.com
Sat Feb 2 09:49:43 PST 2013


On Saturday, 2 February 2013 at 07:10:00 UTC, TommiT wrote:
> On Saturday, 2 February 2013 at 03:50:49 UTC, Zach the Mystic 
> wrote:
>> [..]
>
> Then, if we used your proposed nested structs to implement 
> properties, pretty weird things like this would become possible:
>
> struct A
> {
>   int _value;
>
>   struct B
>   {
>     int get() { return _value; }
>     alias this = get;
>
>     void opAssign(int v) { _value = v; }
>   }
>
>   B length;
> }
>
> void func(T)(ref A a, T oldLength)
> {
>   a.length = 100;
>   // Trying to restore 'a' back to the old length:
>   a.length = oldLength;
> }
>
> void main()
> {
>   A a;
>   a.length = 5;
>   func(a, a.length);
>   assert(a.length == 100);
> }

This code is both wrong and has nothing whatever to do with the 
current topic. Boiling down the template to its resulting 
function, and imagining _value as the intended entity:

void func(ref A a, int oldLength)
{
   a._value = 100;
   a._value = oldLength;
}
A a;
a._value = 5;
func(a, a._value);
assert(a._value == 5); // 5, not 100

func takes an int. It's not a reference, it's a copy.

Let's assume you meant void func(ref A a, ref int oldLength) {} 
instead. Well, if you pass a reference, set it, and then refer 
it, you're going to get the set value back. I'm sorry, you can't 
adjust a reference and then expect to get a phantom original copy 
back. While I may have made a mistake, I simply see no connection 
between this and the idea of properties as structs.


More information about the Digitalmars-d mailing list