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
