On Fri, 28 Mar 2014 07:47:22 -0400, Marc Schütz <[email protected]> wrote:
On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:
I call shenanigans. This is the code:
@property bool empty()
{
if (nLeft)
return false;
if (r.empty)
return true;
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.
-Steve
