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

[Zach the Mystic]

Here are my two cents:

First, about optional parentheses:

Optional parentheses = ambiguity.

int foo() { return 4; }
auto x = foo; // gives 4 or gives function foo?

It seems to me any ambiguity should be an error. However… it only 
matters when the type system can't provide the missing detail, as 
above.

The ambiguity may be resolved either in the function signature or 
at the call site. @property partly helps resolve it at the 
function signature, but it is a different issue from optional 
parentheses.

Ambiguity can also be resolved at the call site instead of the 
function signature. It needs to be as clear and concise as 
possible in addition to being unambiguous. D's method of 
disambiguating cases often uses the keyword "cast". Applying it 
in this case would lead to "cast(function)" or "cast(delegate)" 
to indicate the function and not the return value, where the 
default is to indicate the return value.

int foo() { return 4; }
int function() goo() { return foo; }

auto doh = foo(); // gives 4
auto go = foo; // Error: can't deduce type of expression foo
auto fun = cast(function) foo; // gives foo

auto ae = goo; // Error: can't deduce type (either goo or 
function int() foo )
auto fe = goo(); // Error: can't deduce type (either foo or 4)
auto ga = goo()(); // gives 4
auto gu = cast(function) (goo()); // gives foo
auto gi = cast(function) goo; // gives goo

This solution is unambiguous and clear, but unfortunately not 
very concise. In fact, "cast(function) foo" is rather a long way 
of saying "&foo", but much clearer and possibly safer. The type 
system can probably resolve most of these ambiguities anyway, 
which would mean the cast wouldn't appear very often, but I'm not 
sure.

I have no real opinion about @property. Ideally the compiler 
could deduce what is and isn't a property without the ugly 
@property attached to all the signatures, but it might invite so 
many abuses of this process that it's not worth it.