property syntax strawman

[Robert Jacques]

On Sun, 02 Aug 2009 03:43:43 -0400, Walter Bright  
<newshound1 at digitalmars.com> wrote:

> Having optional parentheses does lead to unresolvable ambiguities. How  
> much of a problem that really is is debatable, but let's assume it  
> should be resolved. To resolve it, a property must be distinguishable  
> from a regular function.
>
> One way is to simply add a "property" attribute keyword:
>
>    property bool empty() { ... }
>    property void empty(bool b) { ... }
>
> The problem is that:
>
> 1. there are a lot of keywords already
> 2. keywords are global things
>
> The alternative is to have a unique syntax for properties. Ideally, the  
> syntax should be intuitive and mimic its use. After much fiddling, and  
> based on n.g. suggestions, Andrei and I penciled in:
>
>    bool empty { ... }
>    void empty=(bool b) { ... }
>
> The only problem is when a declaration but not definition is desired:
>
>    bool empty;
>
> but oops! That defines a field. So we came up with essentially a hack:
>
>    bool empty{}
>
> i.e. the {} means the getter is declared, but defined elsewhere.
>
> What do you think?

I find the fact 'bool empty{}' has no return value very confusing. 'void  
empty=(bool b)' is hackish but okay, though 'typeof(this) empty=(bool b)'  
is more consistent with value types.

I have found Omissible Parentheses (see the associated thread) to be a  
good thing when working with std.string and std.algorithm. In my own code,  
I'd end up converting any zero-parameter function to the new syntax, and  
greatly lament my inability to call things with default parameters without  
parentheses. As an alternative, I'd recommend reserving () for delegate  
calls, and disallow calling functions with (). That would also solve the  
problem, (the backwards breakage introduced would be about the same) and  
the only ambiguity I've though of so far is &class.func which could be  
resolved with &(class.func) if you want the return value's address.