DIP23 draft: Fixing properties redux

[Chad Joan]

On 02/03/2013 11:11 AM, Andrei Alexandrescu wrote:
> On 2/3/13 5:14 AM, Johannes Pfau wrote:
>> ...
>
>> for other corner cases this list is a good start:
>> http://wiki.dlang.org/Property_Discussion_Wrap-up#Implementation_concerns
>>
>> * Can we get a reference to the property? What does
>> &x.property mean?
>
> We need to add this to the proposal. There are two schools of thought here:
>
> 1. Make properties emulate regular variables as much as possible. In
> that case &a.p is the same as &(a.p), i.e. it applies to the returned
> value. (One counter-argument here is that properties should seldom
> return a reference because that breaks encapsulation.)
>
> 2. Allow people to do whatever they need to do without much aggravation.
> In that case &a.p obeys the normal rules of taking a method's address,
> and &(a.p) applies to the returned value.
>
> I favor (2) and put it in http://wiki.dlang.org/DIP23. Will talk to Walter.
>

I disagree with this.  I think that allowing address-of on getters is 
potentially a big source of trouble.  I've felt that getters should be 
forbidden from returning lvalues.  So returning ref from a getter is not 
OK, but const ref should be fine.

Anyone who wants to make the property behave like a reference should 
define an appropriate setter for it.

There are a couple reasons for this:
- It would be nice to allow variables/fields to have @property as an 
annotation.  This would forbid address-of to allow seamless transition 
into fully-implemented property functions later.  To make the roundtrip 
possible, the property functions should also disallow address-of.
- Allowing mutation of a getter's expression can create unwanted 
ambiguities when attempting to apply property rewrites.  Without an 
lvalue getter it becomes unambiguous: any side-effectful operation on a 
property (that isn't direct assignment, or something requiring a read) 
will call both its getter and setter.

>> ...
>
>
> Andrei