Taking address of properties

[Robert]

It depends on how we are going to define properties and with all the
arguments in the discussions it seems to me that the only sane way to
design properties is as simple front ends for private fields (which is
my understanding of properties anyway). 

But with optional parantheses the @property would also not be necessary
for this case. So such use cases would need to be handled by normal
functions. It would simply not be a property by definition. 

Redirecting access would not be the purpose of properties but for
functions returning refs. And you are free to take the address then with
&arr.front().


> @property ref T front(T[] arr) { return arr[0];}

Do you have any other UFCS examples, where @property would seem to be
appropriate?

> 
> This all comes down to an incorrect belief that properties are simply  
> front ends for private variables.  They are not, even when many languages  
> make such things necessary or easy to implement (objective C comes to  
> mind).
> 
> There are plenty of different uses of properties, and redirecting access  
> to another variable (as does the above function) is certainly a valid  
> use.  I don't think we should make rules that are focused on specific use  
> cases while discarding or diminishing others.

It all depends on definitions. If you define an integer as an integral
type, you would not expect it to do floating point arithmetic. Although
there are use cases for floating point operations, but an integer is
just the wrong tool for it.