Function calls

[Steven Schveighoffer]

On Thu, 28 Jan 2010 20:51:29 -0500, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Nick Sabalausky wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message  
>> news:hjtcbd$r0a$1 at digitalmars.com...
>>> Nick Sabalausky wrote:
>>>> And yes, I already pointed out that would make it a no-argument  
>>>> function. And that's precisely my point. If we accept that it's bad  
>>>> to paint a car via its "@property" wheel, then how can we possibly  
>>>> accept this to not be just as bad?:
>>>>
>>>> auto car = new Car();
>>>> auto wheel = car.getWheel_ThisIsAFunctionNotAProperty();
>>>> wheel.paintTheCar();
>>> Because a function doesn't attempt to emulate a field.
>>>
>>  D's approach to properties *forces* functions to emulate fields.
>
> Unfortunately not. It forces nothing. That's my problem with the feature  
> - it's nothing more than fostering a convention.

It forces a convention.  The convention is important, almost as important  
as the name of the function.  Think of it as an extension of the function  
name, like extra punctuation that changes the human interpretation of the  
function.

It means you must be explicit what you intend, the parentheses become a  
detail that is important to the compiler.  If we adopted a convention  
where you could do:

int x, y;

int z = x y;

implying that x should be added to y, then that would certainly work.  But  
what value does it add (no pun intended)?  Did the user intend to add  
them, or did he just make a typo?  The convention of requiring the  
operator forces you to create unambiguous code, just like requiring the  
parentheses forces you to declare your expectation of the function.

-Steve