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

[Jonathan M Davis]

On Thursday, January 24, 2013 00:34:42 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.

Another issue to consider is enhancements such as

http://d.puremagic.com/issues/show_bug.cgi?id=8006

As a property function is supposed to be an abstraction for a variable, and 
you really should be able to swap out property functions and public variables 
without breaking code, things like

foo.prop += 5;

and

++foo.prop;

should work. Unfortunately, D's current property implementation is poor enough 
that that code doesn't currently, but that can be fixed in a backwards-
compatible-manner.

But implementing something like that becomes more problematic without explicit 
properties (potentially even dangerous, depending on what ends up happening 
with those sorts of expressions with non- at property functions which are called 
without parens). Maybe it could be done, but it seems to me that it's the sort 
of thing that should be controlled. We don't want lots of voodoo happening 
with functions called without parens, as we risk getting some nasty bugs when 
using functions that weren't really meant to be properties. But we _do_ want 
some of that voodoo with functions that are designed to be properties.

So, I really think that we need to have explicit properties, even if we allow 
paran-less function calls in some other cases.

But honestly, I wish that we'd just gone with something closer to what C# did 
with properties from the get-go.

- Jonathan M Davis