Function calls

[Andrei Alexandrescu]

Don wrote:
> 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.

Good summary. I now wonder, could one overload based on @property?

auto a = container.empty; // check for emptiness
container.empty();        // take the trash out

!

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.

Unfortunately that's exactly what happens with stdin.byLine: even if it 
were a range, it would alter stdin through its usage. It's not a 
property in the same way stdin.eof or stdin.isOpen are.


Andrei