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()
