On Sunday, 3 February 2013 at 08:16:08 UTC, 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
IMO the concept of emulating a field with a function is proving
to be an idea that should be simplified. Just look at the huge
amount of wasted effort on these discussions, We have at least 5
threads open, two open DIPS and two superseded DIPS.
As it stands, I don't even know why there's such a strong desire
to have properties that emulate variables. I read the arguments
in favor, and they are all very weak IMO, and probably will
result in maintenance issues. We all seem to be getting along
just fine without full variable emulation, and what we have now
for property seems good enough (although I agree it could be done
better with a few simple adjustments).
If we must keep @property, then my advice is to keep the
emulation simple and restricted to the cases where it can work
without acrobatics (eg no address taking, no pass by ref or
return by ref). What I see being proposed is going too far for
very little gain.
BTW, I am wondering if the idea of "memberspaces" was considered,
and if it was considered, then why was it dropped? I won't argue
for them in here, just would like to know what the thinking is
because I don't recall any feedback from Walter or Andrei.
--rt
