Function calls

[Don]

Pelle Månsson wrote:
> On 01/28/2010 09:59 PM, Andrei Alexandrescu wrote:
>> Denis Koroskin wrote:
>>> On Thu, 28 Jan 2010 20:28:17 +0300, Lars T. Kyllingstad
>>> <public at kyllingen.nospamnet> wrote:
>>>
>>>> Steven Schveighoffer wrote:
>>>>> On Thu, 28 Jan 2010 10:22:45 -0500, Adam D. Ruppe
>>>>> <destructionator at gmail.com> wrote:
>>>>>
>>>>>> On Thu, Jan 28, 2010 at 11:47:45AM -0300, Leandro Lucarella wrote:
>>>>>>> Andrei Alexandrescu, el 28 de enero a las 07:57 me escribiste:
>>>>>>> > I need to put it for all front() and empty() declarations. By the
>>>>>>> > way I decided that popFront() is not a property. I don't know why.
>>>>>>>
>>>>>>> Because it denotes an action?
>>>>>>
>>>>>> I don't think it is that simple - I see popFront; as an action all 
>>>>>> the
>>>>>> same as popFront();
>>>>> Whether you use parentheses or not, it's not a property. The
>>>>> statement of Andrei is that he doesn't know why it's not a property.
>>>>> The simple reason is because it's an action.
>>>>> Now, does popFront; look like an action? Yes. But that is not the
>>>>> case being disambiguated. It is collateral damage. Because the
>>>>> compiler doesn't understand English, it can't know whether to
>>>>> disallow popFront; any more than an ambiguous term like read
>>>>
>>>> ...or, as in Andrei's example, 'empty'. In Java you'd write
>>>> isEmpty(), or even worse, getEmpty(). In D we now have the option of
>>>> declaring it a property, with little chance of people thinking it
>>>> actually empties anything.
>>>>
>>>> -Lars
>>>
>>> Great explanation, very convincing!
>>
>> How about this:
>>
>> foreach (line; stdin.byLine()) { ... }
>>
>> vs.
>>
>> foreach (line; stdin.byLine) { ... }
>>
>> How do I choose?
>>
>>
>> Andrei
> 
> I say you don't, it works both ways as it is now. I say, let's not 
> remove this feature :)
> 
> @property should be for when you need to assign to it. Maybe.

I think there are 3 cases:
(1) I want this to _always_ be treated as if it were a field;
(2) I want this to _always_ be treated as a function;
(3) I don't care. (this arises most frequently in generic code: you're 
forced to choose between a field and a function, but you can't have both).

D1 caters for case (3) very well, but does extremely poorly for (1) and (2).
@property is perfect for case (1). It also seems reasonable to disallow 
property assignment syntax for anything which isn't marked as @property.

Disallowing removable parentheses for no-parameter functions is the 
contentious part.