On Tuesday, 6 September 2016 at 19:37:26 UTC, Jonathan M Davis
wrote:
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
I don't see how that would be a problem, you can't take the
address of an rvalue... The problem you describe would be true
for functions as well. What's not true is that it is compilable
(see: http://ideone.com/MXhkXC ). Any problem you can conjure up
about references, temporary values and pointers, all of that
would be true for a regular function as well.
Obviously it is not a variable, but if you use a function and it
returns a reference and you take the address of it. What you get
is the address of the returned value not of the function. int v =
obj.prop; if you look at that "prop" is a called function
pretending to be a variable. If you take the address of a called
function, you get the address of the returned variable, not the
function. If you take the address of a variable, you get the
address of the variable.
On Wednesday, 7 September 2016 at 07:44:05 UTC, Ethan Watson
wrote:
On Tuesday, 6 September 2016 at 19:18:11 UTC, John wrote:
It would be nice to get this behavior fixed.
Disagree. I've used properties before in C# to transform to and
from data sets required for network multiplayer. It works
functionally the same way in D. Behaviour is as I would expect
for the wider implications of how properties can work.
You can't really take one sentence out of context, I didn't say
it in the sense that it was completely broken to the point of
being useless. The part I'm asking to be changed, you probably
didn't even ever use. C# is a managed language, I don't think you
can even take the pointer of anything unless you enable the
unsafe switch.
On Tuesday, 6 September 2016 at 19:34:59 UTC, ag0aep6g wrote:
On 09/06/2016 09:18 PM, John wrote:
&(t.j = 10) // shouldn't this return "ref int
delegate(int)" ?
`&t.j` should and does. With `= 10`, it's definitely a call,
just like `&t.x()`.
It would be nice to get this behavior fixed, so that it
doesn't become
set in stone.
Unfortunately, it already kinda is. Just flipping the switch
would break circa all D code in existence. That's deemed
unacceptable by the leadership, as far as I know.
Don't really see that to be true. I don't see any use case for
taking the address of the delegate for a property. Wouldn't be
surprised if it only broke 1% of code out there. I mean it's
probably used so little that it isn't even properly implemented.
You can get the getter property delegate, but you can't get the
setter property delegate. Either way it's broken as it is now.
