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

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.

Comment on Re^11: Getting for() to accept a tied array in one statement Select or Download Code

Replies are listed 'Best First'.
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]