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

[luka8088]

On 24.1.2013 9:34, 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.

Maybe one possible issue to note. I am sorry if someone already noted 
this but I didn't saw it so here it is.

In druntime's object_.d AssociativeArray has:
@property size_t length() { return _aaLen(p); }

By removing @property typeof([].length) is no longer uint or ulong. It 
would change into uint() or ulong(). And not just for length, but any 
other properties type's would change.

I think that this is one big possible code breaker for everyone that 
uses something similar to the following:

typeof([].length) l = [].length;

Maybe I am wrong but my personal opinion is that code like this should 
compile because semantically length is a property and the fact that it 
is a functions is just a implementation detail.