DIP23 draft: Fixing properties redux

[Rob T]

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