DIP23 draft: Fixing properties redux

[Chad Joan]

On 02/03/2013 03:16 AM, Andrei Alexandrescu wrote:
> Walter and I have had a discussion on how to finalize properties.
>
> http://wiki.dlang.org/DIP23
>
> We got input from DIP21 (which we didn't want to clobber, hence the new
> DIP) and the recent discussion.
>
> The proposal probably won't be accepted in its current form because it
> breaks some code. We hope to bring it to good shape with everyone's help.
>
> In brief:
>
> * Optional parens stay.
>
> * Just mentioning a function or method without parens does NOT
> automatically take its address. (This is a change from the current
> behavior.)
>
> * Read properties (using @property) work as expected with the mention
> that they may NOT be called with the parens. Any parens would apply to
> the returned value.
>
> * Write properties (using @property) may only be used in the assignment
> form (no function-style call allowed).
>
> It is understood that the current proposal is just a draft and there
> must be quite a few corner cases it doesn't discuss. We also understand
> it's impossible to reconcile all viewpoints and please all tastes. Our
> hope is to get to a point where the rules are self-consistent,
> meaningful, and complete.
>
>
> Destroy.
>
> Andrei

This would be a huge step up from the current properties.  Thank you for 
listening and being rigorous.

------

There are a couple things in the DIP that I might be able to destroy; 
here's the first:
the property rewrite is chosen based on whether it compiles or not.

I don't like the rule and its potential ambiguities.  When I was 
attempting a property rewrite patch for DMD, one of the first things I 
did was match the different contexts a property expression may appear in:
- read-only
- read-write
- write-only

In read-only contexts, stuff like "q = prop;" or "auto foo(T)(T x); ... 
foo(prop);" should only call the getter.

In read-write context, the full rewrite is applied.  "prop++" expands to 
"(auto t = prop, t++, prop = t);".  This could include things like 
appearing as the argument to a function's ref parameter, but I've been 
convinced at one point that it might be wiser to disallow that 
(unfortunately, I forget /why/).

In write-only contexts, only the setter is applied.  This is stuff like 
"prop = q;" or "auto foo(T)(out T x); ... foo(prop);".

------

I would suggest guaranteeing that the property rewrite will evaluate the 
getter/setter no more than once in an expression.

------

As Jonathan M Davis pointed out, it should be possible to mark fields as 
@property and forbid address-of on such members.

------

I also think that allowing address-of on properties is dubious.  I've 
mentioned that in another response.

There is no easy way to make address-of do the same thing for variables 
and for properties, so to make properties work consistently in the 
transition between POD to calculated data, it is easiest to just forbid 
address-of.

I think that allowing getters to return lvalues is dangerous in general. 
  It could create ambiguities in the writer's intentions with 
getter/setter pairs: did they want prop++ to expand to (prop++) or (auto 
t = prop, t++, t = prop)?  I think the latter should always be chosen, 
and the whole example should never compile if they only provide a getter.