Function calls

[Bill Baxter]

On Fri, Jan 29, 2010 at 12:02 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> Steven Schveighoffer wrote:
>>
>> On Fri, 29 Jan 2010 13:43:50 -0500, Pelle Månsson
>> <pelle.mansson at gmail.com> wrote:
>>
>>> On 01/29/2010 07:10 PM, Steven Schveighoffer wrote:
>>>>
>>>> Note in the anecdote above, both users would have
>>>> been satisfied if you could *only* call empty without parentheses.
>>>>
>>>
>>> That's a good point. The writeln = 3; is also a good point. :)
>>>
>>> What I'm trying to defend is the ability to call non-property functions
>>> without the parens.
>>>
>>> I find this:
>>>
>>> array.stable_sort;
>>> file.detach;
>>> range.popFront;
>>>
>>> to look less noisy, clearer and just plain sexier than the respective
>>> versions with the parens.
>>
>> You've cited three functions where the function names cannot be
>> misinterpreted as properties.  This is not the case for all function names.
>>  If you wish to have a way to specify a function can be called either way,
>> then I think you also need a way to specify that a function can only be
>> called with parentheses.
>>
>> I don't disagree that the above is unambiguous, but there are examples
>> where it is ambiguous.
>>
>> f.read;
>>
>> does this mean read f, or is it an accidental noop fetching a property
>> indicating f is read?
>
> "Rules are not meant to be followed robotically."
>
> Sorry I couldn't abstain :o).
>
>> Requiring parentheses also allows you to force meanings where they would
>> otherwise be interpreted as properties:
>>
>> f.next();
>>
>> Looks like it advances f, even though next isn't a verb.  Without the
>> parentheses, it looks like a noop access of a property.
>>
>> I'm not too concerned with requiring () on your examples because it's
>> inconsequential to me -- having parentheses isn't *less* clear than not
>> having them.  I don't mind if you wish to allow these calls without parens,
>> but there has to still be a way to force the parens.
>>
>> -Steve
>
> Ok how about this: if just calling the thing changes the parent, it can't be
> a property. Guess I could live with that.

Should be "if calling the thing changes the parent in an outwardly
visible way".  Doing refcounting or caching mutations under the hood
should be ok.

--bb