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
