Function calls

[Pelle Månsson]

On 01/29/2010 02:01 PM, Steven Schveighoffer wrote:
> That's a deficiency in the design of byLine. It's a range that "primes"
> itself with a line of text. The fact that you can enter the line above
> and just throw away the data seems error prone to me. When would you
> ever use that "feature"? In practice, it doesn't matter, because the
> only purpose to fetch the byLine struct is to iterate data from stdin.
>
> The design could be fixed with a boolean isPrimed that is unset on the
> first call to front. But like I said, it doesn't matter in the long run,
> since nobody ever fetches byLine without using it.
>
> I find that the shoehorning of an input range onto a stream is always
> going to have this problem, so there's not much we can do about it. It
> doesn't change the concept that byLine is a property. I find streams
> much better suited to opApply, but I've already had that unsuccessful
> battle, and I don't want to have it again.

So byLine should be a property when implemented as a range, and a 
function when implemented as an opApply based loop?

I feel that is a problem.

> You be the judge: http://www.dsource.org/projects/tango/ticket/1184
>
> I find the resulting workaround very unsavory.
>
> -Steve

That's the assignment syntax, which I do agree is weird. Sorry if I was 
unclear. This is what I thought @property was for.

It has, however, nothing to do with the omitting of the ().