Re^10: Getting for() to accept a tied array in one statement

But isn't the fact that FETCHSIZE is called "more than once" (a.k.a. once per iteration) is how we achieve "don't have to calculate the length of the list in advance?". The first call to FETCHSIZE, we fetch from the iterator. If there is no item, we return 0, ending the for(). If there is an item, we return 1 and push() the fetched item in a buffer, and for() continue. In the next iteration, FETCHSIZE is called again. We fetch from the iterator. If there is no item, we still return 1, ending the for(). If there is still an item, we return 1+1=2 and push() the item in a buffer.

FETCH will shift() item from buffer.

Where do we calculate the length of the list in advance?

Range::ArrayIter is a proof of concept of range iterator using tied array. You can use range_iter(1, Inf), for example. Yes, it's slower than object-based and coderef-based iterator.

Comment on Re^10: Getting for() to accept a tied array in one statement

Replies are listed 'Best First'.
Re^11: Getting for() to accept a tied array in one statement by ikegami (Patriarch) on Apr 24, 2019 at 15:13 UTC
No, the approach you describe fails. It gives incorrect result for any of the following: `for ($additional, @tied) { } map f(), @tied say "@tied"; ...` [download] Therefore, the class must provide a FETCHSIZE must return the correct size up front. It doesn't matter that you can rely on a bug to get away with it in `for (@tied)`. Updated for clarity.	[reply] [d/l] [select]
Re^12: Getting for() to accept a tied array in one statement by perlancar (Hermit) on Apr 25, 2019 at 05:37 UTC
Which statement was your "no" responding to? The original statement I believe is: "With for(@tied_array) we also doesn't need to calculate the length of the list in advance" which you said "That's not true." which I then demonstrated with Range::ArrayIter, which then you replied to with "no" followed by cases where tied-array-based iterator would fail. Sure, the tied-based iterator does not work in all cases, but we are talking specifically about a single "for(@tied_array)". What I want to know is why you said (in essence) that "With for(@tied_array) we still need to calculate the length of the list in advance".	[reply]
Re^13: Getting for() to accept a tied array in one statement by ikegami (Patriarch) on Apr 25, 2019 at 17:24 UTC
Edited to clarify.	[reply]
Re^12: Getting for() to accept a tied array in one statement by perlancar (Hermit) on Apr 26, 2019 at 03:00 UTC
Perhaps we need to consult p5p before deeming it as a bug :-)	[reply]
Re^13: Getting for() to accept a tied array in one statement by ikegami (Patriarch) on Apr 28, 2019 at 19:13 UTC
The fact that `for ((), @a)` calls it once means you're relying on internal implementation. Whether you call it bug or undefined behaviour doesn't matter.	[reply] [d/l]