@property - take it behind the woodshed and shoot it?

[Chad J]

On 01/24/2013 03:34 AM, Walter Bright wrote:
> This has turned into a monster. We've taken 2 or 3 wrong turns somewhere.
>
> Perhaps we should revert to a simple set of rules.
>
> 1. Empty parens are optional. If there is an ambiguity with the return
> value taking (), the () go on the return value.
>
> 2. the:
> f = g
> rewrite to:
> f(g)
> only happens if f is a function that only has overloads for () and (one
> argument). No variadics.
>
> 3. Parens are required for calling delegates or function pointers.
>
> 4. No more @property.

I somehow feel like someone read my article from a couple years ago 
(http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Property) and you 
implemented the less important part and consciously ignored the more 
important part.

The section titled "semantic rewriting of properties" is the important 
one.  Do that.  It removes a source of bugs and gives intuitive behavior 
to our property-functions (ex: prop++; works in general).

@property is considerably less meaningful: take it or leave it, I 
certainly won't care.  It's a bikeshed full of personal opinions.

If we had godly hindsight, then we would have made fields 
non-addressable by default so that people get safe design behavior by 
default: non-addressable fields can be turned into properties (assuming 
property rewriting exists) without breaking API, which creates closure 
for the whole concept.  There would, of course, have to be a way to make 
it possible to explicitly mark variables as addressable in cases where 
you need to make pointers to them.  That non-addressability semantic 
might have helped reference-counting too.  The mistake's made though; 
we'll probably just have to take that one in the gut.