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

[David Nadlinger]

On Thursday, 24 January 2013 at 08:35:01 UTC, 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.

Under the proposed rules, which of the lines in the output of the 
following program will be the same?

---
import std.stdio;

int globalInt = 42;
auto ref g() {
     return globalInt;
};
auto globalG = &g;

auto ref f() {
     return globalG;
}

void main() {
     writeln("&globalInt: ", &globalInt);
     writeln("globalInt: ", globalInt);
     writeln("&globalG: ", &globalG);
     writeln("globalG: ", globalG);
     writeln("---");
     writeln("&f: ", &f);
     writeln("&f(): ", &f());
     writeln("&g: ", &g);
     writeln("&g(): ", &g());
}
---

Also, don't forget that @property was actually introduced to 
solve specific syntactic issues, not just because somebody didn't 
like the laxness of the previous rules.

Now, yes, the current implementation in DMD doesn't solve the 
issues, while introducing new issues by disallowing parameterless 
function calls altogether. But I think the last larger discussion 
on the topic some two to three months ago produced a set of 
@property rules that would actually work. I think there is a 
summary in DIP21.

Anyway, I think you should turn your proposal into a DIP, and 
better sooner than later so that the details on the edge cases, 
impact in terms of breaking code, … aren't lost in an endless 
forum discussion.

David