property syntax strawman

[Andrei Alexandrescu]

Steven Schveighoffer wrote:
> On Mon, 03 Aug 2009 10:25:02 -0400, Michiel Helvensteijn 
> <m.helvensteijn.remove at gmail.com> wrote:
> 
>> Steven Schveighoffer wrote:
>>
>>> So the poster who started this trail of the thread is assuming that
>>>
>>> t.property.get()
>>>
>>> identifies the property getter directly.  But what if the return type of
>>> t.property.get() contains a method get()?  Since t.property is an 
>>> alis for
>>> t.property.get(), Should t.property.get() map to:
>>>
>>> ...
>>>
>>> That is the ambiguity.
>>
>> I myself see great value in the ability to access the getter and setter
>> functions directly. But because of the ambiguity you described, this is
>> problematic for D.
>>
>> Andrei sees 'get' and 'set' as nothing more than declaration-side
>> indications of the getter and setter. Not real functions. In that 
>> case, the
>> ambiguity doesn't exist.
>>
>> To alleviate possible confusion, it has been suggested that a space be 
>> used,
>> not a dot, between the name of the property and get/set in the 
>> declaration.
>>
> 
> So your answer is, there is no ambiguity because it's not possible to 
> access the getter/setter directly?  That poses a problem for existing 
> code which uses delegates to such functions.  I'm not sure we want to 
> lose that ability.
> 
> -Steve
> 

Now that I think of it, even if properties don't readily return 
delegates, they are trivially easy to obtain:

class A
{
     ... define property foo with whatever syntax ...
}

unittest
{
     auto a = new A;
     auto getter = () { return a.foo; }
     auto setter = (int x) { a.foo = x; }
     setter(5);
     writeln(getter());
}

I actually compiled and ran that with foo defined as a regular field.


Andrei