On Mon, 31 Mar 2014 13:43:05 -0400, Marc Schütz <schue...@gmx.net> wrote:
I've found the example I was talking about:
http://forum.dlang.org/thread/mailman.323.1393458346.6445.digitalmar...@puremagic.com
I misremembered, filter wasn't even involved. But similar situations may
arise from using filter or another range that eagerly fetches the first
element, even if its source doesn't.
Sure, but fetching lazily adds cost. It's possible to add it as an option
when needed, but it's not easy to reclaim the cost if it's the default
implementation.
That's what I meant by a tight loop. My hypothesis is that in such cases
the optimizers of at least GDC and LDC are good enough to remove the
check for the boolean completely, and that at least LDC can then remove
the boolean itself from the range structure.
I suspect that this is an optimization that will break down when not done
in the "right way." I'd rather be able to choose, do I need lazy
evaluation or not? The cases where lazy evaluation is needed are not
common.
-Steve
