On Tuesday, September 06, 2016 19:18:11 John via Digitalmars-d 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.
Okay. How would it work to safely get a pointer to anything but the @property function when taking its address? &t.x() is just going to give you the address of the return value - which in most cases, is going to be a temporary, so if that even compiles in most cases, it's a bit scary. Sure, if the @property function returns by ref, then it can work, but an @property function which returns by ref isn't worth much, since you're then giving direct access to the member variable which is what an @property function is usually meant to avoid. If you wanted to do that, you could just use a public member variable. So, given that most @property functions are not going to return by ref, how does it make any sense at all for taking the address of an @property function to do anything different than give you a delegate? Sure, that's not what happens when you take the address of a variable, but you're not dealing with a variable. You're dealing with an @property function which is just trying to emulate a variable. The reality of the matter is that an @property function is _not_ a variable. It's just trying to emulate one, and that abstraction falls apart _really_ fast once you try and do much beyond getting and setting the value - e.g. passing by ref falls flat on its face. We could do better than currently do (e.g. making += lower to code that uses both the getter and the setter when the getter doesn't return by ref), but there are some areas where a property function simply can't act like a variable, because it isn't one. There isn't even a guarantee that an @property function is backed by memory. It could be a completely calculated value, in which case, expecting to get an address of a variable when taking the address of the @property function makes even less sense. - Jonathan M Davis
