On Sat, 29 Mar 2014 17:02:30 -0400, Marc Schütz <schue...@gmx.net> wrote:
On Saturday, 29 March 2014 at 01:36:46 UTC, Steven Schveighoffer wrote:
On Fri, 28 Mar 2014 07:47:22 -0400, Marc Schütz <schue...@gmx.net>
wrote:
On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:
If you initialized the next element in both constructor and popFront,
then you'd get rid of both these checks.
... but of course lose laziness.
In this case, laziness is not critical. Decoding the element is an O(1)
operation, and when looping through, you will decode it anyway.
When processing a 20 element string, the cost of checking to see if you
have decoded on every empty or front call may override the front-loaded
cost of decoding the first element on construction. It's sure to add to
the cost if you are processing all 20 elements, since you decode them
all anyway.
On other ranges, it's more important when the first element costs a lot
to fetch. HOWEVER, it's not critically important to delay that unless
you are not going to process that element. For example, if you are
foreach'ing over all the elements, the delay doesn't matter.
I'd rather the higher level code decide whether to delay or not,
depending on the situation. Requiring a protocol change for such
detailed knowledge seems unbalanced.
I was more thinking of the fact that you need to read something on
construction, rather than on consumption, and this reading might be
noticeable. There was the example of `stdin.byLine().filter(...)` (or
something similar, don't remember exactly), which reads from stdin on
construction. This changes the behaviour of the program, because the
read operation will (probably) block.
Blocking operations may have a noticeable impact, but they may not. It
depends on what you do between construction and processing.
For example, if you have:
foreach(l; stdin.byLine)
Lazily fetching the first line makes no operational difference whatsoever,
even if it blocks, because you're immediately going to process it.
But if it *is* lazily fetched, you are paying some possibly small, but
nonzero, cost for that laziness that you didn't need to pay.
This is why I said it's not critically important to delay unless you are
not going to process the first element. Because there is no primitive to
"prime" the range, we must do it on a property fetch, or on construction.
But after that, popFront is a perfectly reasonable place to get the next
element.
All this fuss is over the *first* element in the range. I think providing
a mechanism to decide whether you want it now or later is reasonable. For
example a lazy range wrapper.
Note, however, the case Andrei was arguing about was one of the string
decoders. When you are blocking for input, hell, even if you aren't
blocking, but need to call system calls to get it, the performance cost of
checking a boolean every call is negligible. But when you are decoding 1-4
bytes of data in memory, checking a boolean becomes significant.
-Steve
