La synthèse de la semaine dans PHP Internals regroupait dix sujets. Elle portait notamment sur le RFC IntlRelativeDateTimeFormatter, array_str_contains, la gestion des erreurs des expressions régulières, l’avenir de PEAR et les prochaines versions de PHP.

Weilin Du a ouvert mardi le vote sur IntlRelativeDateTimeFormatter. Le RFC concerne le formatage relatif des dates et heures par l’extension intl, selon les possibilités d’ICU, avec des sorties comme « 3 days ago » et « next Sunday ». Environ dix minutes plus tard, Tim Düsterhus a voté contre. Le scrutin affichait quatre votes favorables et un vote défavorable lorsque Du l’a fermé après moins d’une heure.

Düsterhus a expliqué que le RFC avait changé après sa relecture. Aucun message ne lui avait confirmé que les modifications étaient effectives, et son intention de vote avait expiré. Il contestait aussi l’emploi de constantes entières non typées dans les cas où des enums pourraient préciser les valeurs. Du a qualifié l’épisode de malentendu, l’a considéré comme une modification majeure et a retiré le scrutin. Mercredi, Düsterhus a proposé trois enums pour le style, la casse et l’unité, sans namespace. Son exemple remplace `IntlRelativeDateTimeFormatter::UNIT_DAY` par `IntlRelativeDateTimeFormatterUnit::Day`. Cette approche fournirait la complétion des IDE, des cas documentables et des contrôles d’entrée assurés par le moteur. `RoundingMode` servait de précédent.

Le benchmark fourni avec la proposition array_str_contains a affaibli son argumentaire. Yuya Hamada a exécuté le test inclus dans la pull request. Avec une correspondance au début du tableau, la fonction native en C prenait 578 millisecondes, contre 14 millisecondes pour une boucle foreach. Elle était aussi plus lente avec une correspondance au milieu ou à la fin. Elle rejoignait la boucle uniquement quand aucun élément ne correspondait. Sepehr Mahmoudi a contesté le résultat, car les fichiers ne se compilaient pas dans son environnement. Il a retiré les tests de benchmark de la proposition dimanche.

Kamil Tekiela a rappelé le critère appliqué aux nouvelles fonctions de la bibliothèque standard. Leur comportement doit être impossible ou très difficile à reproduire en userland, ou assez courant pour justifier une API dédiée. mickmackusa a estimé qu’une implémentation C plus rapide ne suffisait pas à justifier une fonction de la famille array. Larry Garfield a constaté que personne ne révisait les benchmarks, faute de soutien actif à la proposition. Il a rappelé que des contributeurs expérimentés voient aussi leurs idées refusées. Mercredi soir, le RFC figurait toujours dans le wiki et aucun vote n’était programmé.

Le RFC PREG_THROW_ON_ERROR conserve une question de conception ouverte. Une exception lancée par un callback de `preg_replace_callback` pourrait être encapsulée dans `PregException` ou remonter directement. Tim Düsterhus, auteur de la politique sur les throwables, soutient l’encapsulation. Trois autres intervenants se sont prononcés cette semaine pour la propagation directe. Casper Langemeijer a déclaré ne connaître aucun callback PHP encapsulé par le langage, y compris lors de l’autoloading. Sascha Ploss a cité JavaScript, Python, Java, C#, Rust et Ruby, où l’exception du callback remonte.

Osama Aldemeery, auteur du RFC, a précisé le comportement du code C. Une exception du callback définit actuellement `preg_last_error` sur `PREG_INTERNAL_ERROR`, car le chemin d’abandon transmet le nombre de correspondances à une fonction d’erreur sans cas correspondant. Le moteur des expressions régulières peut avoir effectué la correspondance correctement, tandis que le chemin d’abandon laisse une erreur générique. La garantie d’égalité entre le message de l’exception et `preg_last_error_msg` ne vaut que pour un seul appel avec le flag activé. Düsterhus a ensuite proposé que ce flag ne modifie jamais `preg_last_error`, selon le modèle de `JSON_THROW_ON_ERROR`. Une seule `PregException`, ou une paire `PregError` et `PregException`, suffirait alors. Aldemeery a laissé la décision de politique à Düsterhus, qui ne l’avait pas encore prise jeudi.

La récupération des données de bugs de PEAR a modifié le RFC sur la fin de son soutien. Nick S. a remplacé la section consacrée à la portée future par une description de la situation actuelle et un calendrier précis, après coordination avec Derick Rethans. Il a également supprimé l’affirmation selon laquelle les tentatives de contact avec les mainteneurs de PEAR étaient restées sans réponse. Ces changements étant importants, la discussion reste ouverte au moins jusqu’au 27 septembre.

Chuck a restauré les pages de bugs manquantes. L’archive pourra ainsi être complète. Juliette Reinders Folmer a remercié les deux contributeurs. Jakub Zelenka a demandé si php-src devait désolidariser PEAR avant le passage du site en mode statique. Il pense que le build Windows utilise encore l’installateur et prévoit de reprendre cette pull request en octobre ou novembre. Après vérification avec Derick Rethans, Nick S. a indiqué que la bascule du site pouvait avoir lieu en premier, à condition que `go-pear.phar` et les autres URL restent servis par le même domaine. Le vote ne peut pas se terminer avant la mi-octobre. Nick ne prévoit aucune intégration avant novembre. Une autre pull request de Daniel Scherzer place le phar de l’installateur PEAR dans le dépôt lors de la préparation d’une release et cible 8.2.

La coupe de la branche PHP 8.6 est prévue le 22 septembre, avec la création des paquets de 8.6.0 RC1. Elle marquera le gel fonctionnel définitif. Ensuite, master deviendra 8.7. Beta 3 est sorti le 10 septembre, et RC1 était attendu le 24 septembre. Des release candidates étaient disponibles pour 8.5.11 et 8.4.26.

Matthieu Napoli a obtenu le RFC karma pour `--enable-cli-fpm`. Cette option de compilation lie FPM au binaire PHP. La commande `php --fpm` lance alors FPM. Avec Bref sur Lambda, un second binaire de 24 mégaoctets augmente actuellement le temps de démarrage à froid. Marc Henderkes souhaite que l’option devienne le comportement par défaut.

Une proposition publiée en août autoriserait les commentaires et les virgules finales dans JSON. Tim a suggéré un flag unique, `JSON_ALLOW_JSONC`, basé sur le standard JSONC existant. Vilius Buividavičius a proposé `MyClass::properties::name` pour référencer les noms de propriétés comme des constantes. Doctrine pourrait ainsi éviter les chaînes écrites en dur. Nick S. a renvoyé à une discussion plus ancienne sur la même idée.

Alwyn Bester a publié `php-grammar`, une grammaire EBNF de PHP 8.5 fondée sur les sources et vérifiée avec le parseur. Il a demandé une relecture sur la liste et relancé une discussion vieille de 15 ans sur une EBNF officielle pour PHP. David Maye Kitenge a posé des questions sur la propriété de `zend_string` en migrant une extension de code produit par Zephir vers du C écrit à la main. Alexandru Pătrănescu a précisé que `static` décrit la variable C et ne change pas le refcount de la chaîne. Les chaînes internées appartiennent à Zend et à OPcache. Une extension ne doit donc jamais les libérer directement. Les chaînes permanentes doivent être internées dans MINIT. Une chaîne internée pendant une requête ne doit pas être considérée comme valide au-delà de cette requête.

Mercredi soir, le wiki ne comptait aucun RFC en cours de vote pour la cinquième semaine consécutive.