Function calls

[Nick Sabalausky]

"Andrei Alexandrescu" <SeeWebsiteForEmail at erdani.org> wrote in message 
news:hjt1ea$306u$1 at digitalmars.com...
>
> Good summary. I now wonder, could one overload based on @property?
>
> auto a = container.empty; // check for emptiness
> container.empty();        // take the trash out
>
> !
>

Why would that ever enter into anyone's mind? You already can't overload on 
a member's type, you already can't overload on function's return type, and 
you certainly can't overload on a mere decorator. There's no issue here.


> Anyway, I have one more comment about the example:
>
> foreach (line; stdio.byLine) { ... }
> vs.
> foreach (line; stdio.byLine()) { ... }
>
> Steve said, byLine fetches a range off stdio. In fact it's not - it's an 
> opApply() based loop. That already muddies the waters. But I have another, 
> bigger concern. When I think of a property, I think I fetch it and it 
> can't go back and modify its originator. Like if I do:
>
> auto x = y.length;
>
> I don't expect to later mess with x and change y through it.
>
> I'm sure an inventive mind could find an argument against this but if I 
> try to be honest with myself I'd think it's tenuous to have the tail 
> property wag the dog object.
>

If you see a problem with being able to do this:

auto dog = new Dog();
auto tail = dog.tail;
tail.wag();

Then you obviously haven't done much game programming. (Now obviously 
something like "tail.bark()" would be ridiculous, but hardly a real risk.)

Additionally, even if that could be considered a problem, I don't see how 
having ommittable parens on no-param function calls would in any way 
alleviate the problem.