Hi Larry, That’s a fair point, and I agree that a lazy array slice would be a
more powerful and general solution in the long run. However, I’d like to point out that such a feature is a very large undertaking. It would require: - A new ArraySlice type in the Zend Engine - Changes to memory management and reference counting - Updating potentially hundreds of array functions to accept it - A major RFC with significant design discussion This is not a small patch — it’s a project that could take months or even years, and it may never land at all. array_search_range(), on the other hand, is small, focused, and ready today. It solves a real, concrete problem without waiting for a much larger design that doesn’t exist yet. My question is: should we block a small, useful improvement on the hope of a much larger feature that may never come? Or would it make more sense to accept the small step now, and let the lazy slice idea evolve separately? I’d genuinely appreciate your thoughts on this. Regards, Sepehr On سهشنبه ۱۸ اوت ۲۰۲۶، ۰۱:۲۹ Larry Garfield <[email protected]> wrote: > On Mon, Aug 17, 2026, at 3:39 PM, سپهر محمودی wrote: > > Hi Larry, > > > > Apologies — my previous message was addressed to Rowan by mistake, > > > > but it was meant as a reply to the thread, and I was also responding > > > > to your point. Both of your feedback is very helpful. > > > > Thanks again for taking the time to share your thoughts. > > > > Regards, > > > > Sepehr > > First, please do not top post. > > > On دوشنبه ۱۷ اوت ۲۰۲۶، ۲۳:۵۵ سپهر محمودی <[email protected]> wrote: > > >> I’d be genuinely interested in your opinion on the best path forward: > >> 1. Should we proceed with array_search_range() as a focused addition > >> now, and explore “lazy array slice” as a separate, broader RFC? > >> 2. Or do you think it would be better to fold this idea into the > >> larger concept from the start? > >> > >> Either way, I’m happy to collaborate and learn from the discussion. > >> > >> Regards, > >> > >> Sepehr > > I would favor shelving this idea for now, and instead putting effort into > the more robust solution that would benefit everything at once. > > If you have a specific use case yourself where this would actually make a > big performance difference (which I do not believe is the typical case), > then a custom extension with a single function seems like it would be > pretty easy, especially if you've already built it as a patch. > > --Larry Garfield >
