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.
