Uniform Function Call syntax for properties

Robert Jacques sandford at jhu.edu
Wed Oct 13 17:57:54 PDT 2010


On Wed, 13 Oct 2010 14:34:14 -0400, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:
> On Sat, 09 Oct 2010 21:58:00 -0400, Robert Jacques <sandford at jhu.edu>  
> wrote:
>
>> On Sat, 09 Oct 2010 16:28:32 -0400, Denis Koroskin <2korden at gmail.com>  
>> wrote:
>>
>>> On Sun, 10 Oct 2010 00:09:23 +0400, Sean Kelly  
>>> <sean at invisibleduck.org> wrote:
>>>
>>>> Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
>>>>> On 10/8/10 7:55 CDT, Steven Schveighoffer wrote:
>>>>>> Someone was asking about UFC syntax for properties on d.learn, and I
>>>>>> realized, we have a huge ambiguity here.
>>>>>>
>>>>>> Given a function:
>>>>>>
>>>>>> @property int foo(int x)
>>>>>>
>>>>>> Is this a global setter or a getter on an int?
>>>>>
>>>>> Good question.
>>>>
>>>> Setter. Consider "a = b = c".
>>>
>>> I think you missed the point. Which of the two is it:
>>>
>>> int x = 42;
>>> auto y = x.foo(); // transformed into "auto y = foo(x);", getter
>>>
>>> or
>>>
>>> foo = 42; // transformed into "foo(42);", setter
>>>
>>> Both match.
>>
>> I agree that there is ambiguity here, but does it why does foo have to  
>> be only a getter or only a setter? Why can't it behave like either,  
>> depending on its implementation and use?
>
> Because then we are back to writeln = 42;
>
> -Steve

:) I see that despite not valid code for what, over a year now?, writeln =  
42 still persists.
That said, how exactly are we back to the verb = value "problem"? The  
rearrangement ambiguity was never the expressed reason for introducing  
@property. In fact, despite all the passionate posts about how wrong "verb  
= value" looks, it took a very specific syntax ambiguity with  
delegates/opCall to warrant language inclusion. And given the practical  
problems @property has been running into, it kinda makes me wish I had run  
across the uniform access principle  
(http://www.eiffel.com/general/column/2005/Sept_October.html) back during  
the debates.


More information about the Digitalmars-d mailing list