A mailing list is a queue of other people's reading time. The sender sets the price. One thread this week shows what that queue is actually for.
Sepehr Mahmoudi opened an RFC on Saturday for `array_match()`, which filters an array down to the values containing a substring, implemented in C so callers do not pay for a closure on every element [10]. Yuya Hamada replied within the hour, asking whether `array_filter()` already covers it, pointing at a GitHub search full of userland functions named `array_match` that do not all behave alike, and noting that the declined `str_icontains` RFC makes an ASCII-only case-insensitive flag a hard sell [11]. Tim Düsterhus noted that in 8.6 the whole thing is one line, because partial function application lets you drop `str_contains` into `array_filter()` with a placeholder [12]. Christian Schneider pointed out that `preg_grep()` has done basically the same job for years [13]. Ayesh Karunaratne went at the premise: "I have worked on Drupal, WordPress, Silex, and bespoke code bases, spending enough time profiling them. An array string search has never been a bottleneck" [14]. Larry Garfield called it an XY problem and said huge in-memory arrays are a smell to begin with [15]. mickmackusa proposed making `str_contains()` polymorphic, the way `str_replace()` already accepts an array [16]. Six named contributors replied and none of them supported it [18]. The author has since dropped the flag, renamed it `array_str_contain()`, and moved the target to 8.7, because 8.6 is frozen [17].
Look at what those replies carried: a language feature arriving in the next minor, an old function that already does it, the voting history of a related RFC, and profiling experience across several large codebases. None of that is in the RFC text. That is the asset a machine-drafted argument spends without replenishing.
The enforcement problem is that the only tell named in the weekly This Week in PHP Internals summary is register, that flat over-professional voice which thanks you warmly and then restates your own point [2] [19]. Register alone doesn't settle the question. A contributor drafting in Farsi or Japanese and running the result through a model to get polite English produces the same flattened text as a contributor who asked the model what to think. The list has already agreed the first case is a legitimate accessibility need [4] and the second is not [5], and it has no reliable way to tell them apart from outside [6]. For a group whose entire artifact is prose, that is an awkward place to keep a blind spot.
So a workable rule probably cannot be about provenance at all. It has to be about obligations only a human on the other end can meet: answer a follow-up in the thread, and respond to the objection actually raised rather than around it. That is my read of what is checkable here, and it is a different rule from "do not use a model" because the archive records whether it was met. A translated mail can pass that test, while a delegated one tends to come apart by the second reply.
For another project to borrow the same line, its review has to happen somewhere follow-ups are expected and visible. The internals list qualifies, and the `array_str_contain()` author is still in the thread revising in response to criticism [17]. A project whose design review is scattered across drive-by pull request comments has nothing to hang the second reply on, and will end up back where PHP is now, guessing from tone.</body_markdown> </invoke>
