@property Incorrectly Implemented?

John via Digitalmars-d digitalmars-d at puremagic.com
Sun Sep 11 00:19:54 PDT 2016


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.



More information about the Digitalmars-d mailing list