property syntax strawman

[Steven Schveighoffer]

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 have to confess, I thought I wrote my last reply for property debate...

As for the proposed syntax, the setter syntax looks acceptable, but I  
don't really like the getter syntax.

I can't think of a really good analagous setter symbol to =.  Some of the  
other syntaxes I've seen show promise such as:

bool empty.get { ... }
void empty.set(bool b) {...}

One thing to consider is if it should be possible to take a delegate of a  
property setter or getter, how do you identify the property function  
itself?  This solution provides an easy way:

&empty.get
&empty.set

The only issue with this is if the type returned from the getter actually  
defines a get field or method.  While having a method called get might be  
a likely possibility, having that on a type that is likely to be returned  
as a property is probably unlikely. There is of course a workaround:

empty.get().get();

-or-

auto tmp = empty;
tmp.get();

to call the underlying method.

Another option is to name the getter and setter something less likely to  
be used, such as opGet/opSet or _get/_set.  Finally, you could have a  
renaming rule that would allow access to the function.  For example  
empty.get translates to get_empty(), so if you called get_empty() it would  
call the getter.  C# does something like this.

Yet another option is to involve some sort of punctuation, e.g.:

empty.get(); // call the returned type's get function
&empty at get;  // delegate to the getter.

Note that the only one of these that makes a lot of sense for the property  
keyword solution (or your solution) is the renaming empty to get_empty().

I'm glad to see that this might actually be addressed.

-Steve