property syntax strawman

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> 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

That's one place where rewriting shines :o). There's no need to even 
think of how to do it when properties work as get_empty() and 
set_empty(bool) - the means are already in the language.

Andrei