array_search_range meets the freeze: PHP internals wants a lazy slice, not another array function

The whole justification for the function is a copy that should not have to happen. `array_slice()` materialises a second array so that `array_search()` has something to scan, and `array_search_range()` was offered as the way around it ^[1]. But Rowan Tommins' review of the submitted implementation found it still walking the entire array ^[14], and the polyfill added to the wiki calls `array_slice()`, which performs the copy the function exists to avoid ^[13]. As it stands, the artefact does not exhibit the property it is arguing for.

That is fixable. The cost estimate is the harder disagreement. Sepehr Mahmoudi's position is that the general mechanism does not exist, and that building it would mean a new type in the engine plus updates to potentially hundreds of array functions ^[8]. Rowan's counter-plan does not touch hundreds of array functions: an optimised `ArraySliceIterator` first, then `iter_search` and `iter_any` that work with any iterator, then possibly syntax later ^[11]. He wrote the first two in under 20 lines each ^[12], so under 40 lines of prototype for the pieces that make the narrow function unnecessary ^[1]. Both figures are honest, because they price different jobs. Retrofitting the existing array surface to accept a slice type is expensive. Adding two functions that consume iterators is not, because the iterator contract is already in the language.

Rowan stated the trade in one line: "if we add an ArraySlice type then array_search_range would immediately become redundant" ^[7]. His preference was for "a way to create a 'lazy array slice', and then accept that in functions which can use it safely", with Swift's non-copying array references as the reference point ^[5][6]. Larry Garfield agreed and suggested shelving the RFC ^[9]. mickmackusa went further, saying he had never had a professional project that needed the function and asking whether an array wanting a pagination-style search is the wrong data structure to begin with ^[10].

The scheduling matters as much as the design. Weilin Du replied on the evening the idea was posted to say the soft feature freeze had already closed 8.6 to it ^[4], and the RFC is nonetheless still a draft still targeting 8.6 ^[14]. Anything argued from here is being argued into 8.7, which is exactly the window in which a reviewer can say the general primitive should come first and lose nothing by waiting.

The same reflex appeared elsewhere in the week at higher speed. Henrik Skov floated a `params` keyword to name a block of arguments once and spread it into a call, collapsing a six-argument cookie call to one line ^[19]; AllenJB answered 22 minutes later that named arguments already do this ^[20]. Two proposals, both met with a version of the same reply: the general mechanism is either present or cheap, and the specific convenience has to justify permanent surface area against it. Anyone drafting for 8.7 should read the 20-line prototype as the bar, not the freeze date.