Using ()s in @property functions

[Jonathan M Davis]

On Tuesday 29 June 2010 20:41:48 Andrei Alexandrescu wrote:
> 
> I don't think you should be able to even take the address of a non-ref
> property.
> 
> Andrei

In order to have a properly reference a non-ref property, you would have to have 
an abstraction which wrapped the object along with its getter and/or setter and 
treated it exactly like a reference to a public member variable (including 
dealing with the fact that it could be read-only or write-only). On top of that, 
that same abstraction would have to be used for references to actual member 
variables. That way, they could be treated identically be user code, and that 
code would not have to care whether it was dealing with property functions or a 
naked member variable. And while I'm sure that such an abstraction is 
technically feasible, it would likely be an expensive one (particularly for a 
systems language), and by the time you're talking addresses of things, you're 
way too low-level to even consider it.

Properties are definitely a useful abstraction, but they are by their nature a 
bit broken - particularly when you get to the low-level stuff - because while 
they may act like member variables, they _aren't_ member variables.

A ref property is giving you essentially what a naked member variable would give 
you, so it makes some sense to allow you to take its address. However, if it's a 
non-ref property, I don't think that it really makes sense anymore. What would 
you take the address of? You'd need one (possibly two) functions and the object 
that has the property. With a ref, you have the variable itself. It's nowhere 
near that simple with a non-ref property functions - there may not even _be_ a 
variable to reference. So, I'd have to agree that it doesn't make sense to take 
the address of a non-ref property.

I don't remember the details, but IIRC, C# has similar restrictions on its 
properties where you can't really treat them quite the same as public member 
variables, so it's not like it's without precedent. If we really wanted to fix 
it, we'd need a higher-level reference abstraction than we currently have, it 
there's a good chance that the abstraction would cost far too much to make sense 
- particularly for a systems lanuage.

- Jonathan M Davis