@property Incorrectly Implemented?

[Lodovico Giaretta via Digitalmars-d]

On Tuesday, 6 September 2016 at 19:18:11 UTC, John wrote:
>
> Currently it seems that @property isn't implemented correctly. 
> For some reason when you try to get the pointer of a property 
> it returns a delegate for some reason. This just seems plain 
> wrong, the whole purpose of a property is for a function to 
> behave as if it weren't a function. There's also some 
> inconsistencies in the behavior, "get" is implemented one way 
> and then "set" is implemented another.
>
> http://ideone.com/ZgGT2G
>
>     &t.x         // returns "ref int delegate()"
>     &t.x()       // ok returns "int*", but defeats purpose of 
> @property
>     &(t.j = 10)  // shouldn't this return "ref int 
> delegate(int)" ?
>
> It would be nice to get this behavior fixed, so that it doesn't 
> become set in stone. I think returning a delegate pointer is 
> not what people would except nor is there really any use case 
> for it.

With properties, the & operator is the only way to have the 
function itself and not it's return value. The reason is that the 
return value of a function is not necessarily an lvalue, so 
taking its address is not always correct. Imagine this:

@property int x() { return 3; }

As 3 is an rvalue, you cannot take its address. That's the 
difference between a true field and a computed one.

The purpose of properties is the following:

struct S
{
     @property int x() { /* whatever */ }
     int y() { /* whatever */ }
}

writeln(typeof(S.x).stringof); // prints int
writeln(typeof(S.y).stringof); // prints int delegate()