This week’s PHP internals roundup covered 10 topics, including the IntlRelativeDateTimeFormatter RFC, array_str_contains, regular-expression error handling, PEAR’s future, and the next PHP release milestones.

Weilin Du opened voting on IntlRelativeDateTimeFormatter on Tuesday. The RFC concerns ICU-style relative date and time output for the intl extension, such as “3 days ago” and “next Sunday”. Tim Düsterhus voted no after about 10 minutes. The ballot showed four yes votes and one no vote before Du closed it in under an hour.

Düsterhus said the RFC had changed after his review, but no message confirmed that the changes had been applied. His intent to vote had also expired. He questioned the use of untyped integer constants where enums could provide stricter definitions. Du described the situation as a misunderstanding, treated it as a major change, and withdrew the ballot. On Wednesday, Düsterhus proposed three enums for style, capitalization, and unit, without a namespace. His example changes `IntlRelativeDateTimeFormatter::UNIT_DAY` to `IntlRelativeDateTimeFormatterUnit::Day`. The design would support IDE completion, documented cases, and engine-level input checks. `RoundingMode` was cited as a precedent.

A benchmark included with the array_str_contains proposal weakened its case. Yuya Hamada ran the supplied test and measured 578 milliseconds for the native C function when the match was at the beginning of the array, compared with 14 milliseconds for a foreach loop. The native call also lost for matches in the middle and at the end. It reached parity only when no element matched. Sepehr Mahmoudi challenged the result because the files failed to build in his environment, then removed the benchmark tests from the proposal on Sunday.

Kamil Tekiela said a new standard-library function should offer behavior that is impossible or very difficult to reproduce in userland, or behavior common enough to justify a dedicated API. mickmackusa said a faster C implementation alone does not meet that bar for the array family. Larry Garfield observed that the proposal had no active supporters reviewing the benchmarks and noted that experienced contributors can have proposals rejected. The RFC remained on the wiki on Wednesday night, with no vote scheduled.

The PREG_THROW_ON_ERROR RFC still has an open design question. A callback exception from `preg_replace_callback` could be wrapped in `PregException`, or it could propagate directly. Tim Düsterhus, who wrote the throwable policy, supports wrapping. Three other participants this week favored propagation. Casper Langemeijer said he knew of no PHP callback that the language wraps, including autoloading. Sascha Ploss cited JavaScript, Python, Java, C#, Rust, and Ruby, where callback exceptions propagate.

Osama Aldemeery, the RFC author, clarified the C behavior during the discussion. A callback exception currently sets `preg_last_error` to `PREG_INTERNAL_ERROR` because the bailout path passes the match count to an error handler without a matching case. The regular-expression engine can complete its match successfully, while the bailout leaves behind a fallback error. The guarantee that the exception message equals `preg_last_error_msg` applies only to one flagged call. Düsterhus later argued that the flag should leave `preg_last_error` untouched, following the behavior of `JSON_THROW_ON_ERROR`. He said one `PregException`, or a `PregError` together with `PregException`, would then be sufficient. Aldemeery left the policy decision to Düsterhus, who had not made it by Thursday.

Recovered PEAR bug data changed the end-of-endorsement RFC. Nick S. replaced its future-scope section with a description of the current situation and an explicit timeline, after coordinating with Derick Rethans. He also removed a statement that attempts to contact PEAR maintainers had failed. Because the edits were substantial, discussion remains open until at least September 27.

Chuck recovered the missing bug pages, allowing the archive to be completed. Juliette Reinders Folmer thanked both contributors. Jakub Zelenka asked whether php-src should unbundle PEAR before the PEAR site becomes static. He believes the Windows build still uses the installer and plans to resume that pull request in October or November. Nick S., after checking with Derick Rethans, said the site switch can happen first if `go-pear.phar` and the remaining URLs continue to use the same domain. The vote cannot finish before mid-October, and Nick expects no result to land before November. A separate pull request by Daniel Scherzer stores the PEAR installer phar in the repository during release packaging and targets 8.2.

The PHP 8.6 branch cut is scheduled for September 22, together with packaging for 8.6.0 RC1. This is the hard feature freeze, after which master becomes 8.7. Beta 3 shipped on September 10, RC1 was expected on September 24, and release candidates were available for 8.5.11 and 8.4.26.

Matthieu Napoli received RFC karma for `--enable-cli-fpm`, a build option that links FPM into the PHP binary. The resulting `php --fpm` command runs FPM. Bref on Lambda currently pays for a second 24-megabyte binary, which adds to cold-start time. Marc Henderkes argued that the option should become the default.

A proposal from August would allow comments and trailing commas in JSON. Tim suggested one `JSON_ALLOW_JSONC` flag covering the existing JSONC standard. Vilius Buividavičius proposed `MyClass::properties::name` as a constant-style way to refer to property names, helping Doctrine avoid hardcoded strings. Nick S. linked the proposal to an earlier discussion of the same idea.

Alwyn Bester published `php-grammar`, a source-backed EBNF grammar for PHP 8.5 that has been checked against the parser. He asked the mailing list for review and revived a discussion from 15 years ago about an official PHP EBNF. David Maye Kitenge asked about `zend_string` ownership while moving an extension from Zephir-generated output to handwritten C. Alexandru Pătrănescu explained that `static` describes the C variable and does not alter the string’s refcount. Zend and OPcache own interned strings, so extensions must not free them directly. Permanent strings should be interned in MINIT, and a string interned during a request must not be assumed to survive that request.

By Wednesday night, the wiki listed no RFCs in voting for the fifth consecutive week.