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 ().
