property syntax strawman

[Steven Schveighoffer]

On Mon, 03 Aug 2009 10:14:14 -0400, John C <johnch_atms at hotmail.com> wrote:

> Steven Schveighoffer wrote:
>> On Sun, 02 Aug 2009 15:23:44 -0400, John C <johnch_atms at hotmail.com>  
>> wrote:
>>
>>> Andrei Alexandrescu wrote:
>>>> Michiel Helvensteijn wrote:
>>>>> Andrei Alexandrescu wrote:
>>>>>
>>>>>> Then in a later message you mention:
>>>>>>
>>>>>> bool empty.get() { ... }
>>>>>> void empty.set(bool b) { ... }
>>>>>>
>>>>>> which I like and which does not seem to have difficulties; the names
>>>>>> "get" and "set" will be never used as such.
>>>>>
>>>>> Yes, those are two notations for the same thing, and they have the  
>>>>> same
>>>>> problem. Let me demonstrate:
>>>>>
>>>>> --------------------------------------------------
>>>>> struct S {
>>>>>     int get() { return 42; }
>>>>> };
>>>>>
>>>>> struct T {
>>>>>     S _s;
>>>>>     S property.get() { return _s; }
>>>>>     void property.set(S s) { _s = s; }
>>>>> }
>>>>>
>>>>> T t;
>>>>>
>>>>> auto X = t.property.get();
>>>>> --------------------------------------------------
>>>>>
>>>>> What is the type of X? It can be either S or int, depending on how D  
>>>>> handles
>>>>> the situation.
>>>>>
>>>>> The ambiguity is in the possibility to directly reference the getter  
>>>>> and
>>>>> setter methods. In that other subthread (the older one) I listed some
>>>>> possible solutions.
>>>>>
>>>>> The first is to make such a program an error.
>>>>>
>>>>> The second is not to allow a direct reference to a getter/setter (so  
>>>>> X is an
>>>>> int).
>>>>>
>>>>> The third is to let the getter/setter overshadow S members (so X is  
>>>>> an S).
>>>>  I see. My view is that .get and .set are simply symbolic  
>>>> placeholders, but indeed some may get confused.
>>>>  Andrei
>>>
>>> Does the ambiguity go away if we replace the '.' with a space?
>>>
>>> Declaration:
>>>
>>> bool empty get();
>>> void empty set(bool);
>>>
>>> Declaration:
>>>
>>> bool empty get() { return empty_; }
>>> void empty set(bool b) { empty_ = b; }
>>  The ambiguity of declaration, not the ambiguity of usage, unless you  
>> want to use the space to denote the usage also?
>>  -Steve
>
> Not sure where the ambiguity is with usage. To keep things simple, 'get'  
> and 'set' should only be valid at the point of declaration. They're not  
> really part of the function name.

Currently, since properties are simply functions, you can take the  
delegate of a setter.

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:

t.property

or

(t.property).get() // get the property, then call it's get function.

That is the ambiguity.

-Steve