Le sujet dominant sur la liste internals de PHP cette semaine n'était pas le code mais la communication. Les abonnés ont débattu de la conduite à tenir face aux messages visiblement rédigés ou fortement assistés par de grands modèles de langage. Environ 24 messages ont suivi. Personne ne s'est opposé à la traduction automatique, l'anglais étant la deuxième ou troisième langue de nombreux participants. Les objections visaient la délégation de l'argumentation elle-même à une machine et l'impossibilité de détecter de façon fiable un texte LLM de l'extérieur. Aucune règle n'est encore écrite, mais un fil du Discord communautaire phpc.chat travaille sur des lignes directrices.

Sepehr Mahmoudi a ouvert un nouveau RFC samedi, peu après avoir retiré le précédent. La proposition array_match() filtrerait un tableau pour ne garder que les valeurs contenant une sous-chaîne, implémentée en C pour éviter le coût d'une closure. La résistance a été immédiate. Yuya Hamada a invoqué array_filter(), les fonctions utilisateur déjà nommées array_match au comportement disparate et le RFC str_icontains refusé. Tim Düsterhus a noté qu'avec l'application partielle de fonctions en PHP 8.6, le même résultat tient en une ligne, et Christian Schneider a cité preg_grep(). Fort de son expérience de profilage sur Drupal, WordPress et d'autres bases de code, Ayesh Karunaratne a affirmé que la recherche de chaînes dans un tableau n'a jamais été un goulot d'étranglement. Larry Garfield a parlé de problème XY, et mickmackusa a proposé de rendre str_contains() polymorphe comme str_replace(). Mahmoudi a abandonné le drapeau insensible à la casse, renommé la fonction array_str_contain() et visé PHP 8.7, 8.6 étant gelée. Le RFC n'a pour l'instant aucun partisan.

Nick Sdot a proposé de restructurer le livre internals de PHP dans php-src, en convertissant les pages de reStructuredText vers Markdown via un diff mécanique de 1 100 lignes. Ilija Tovilo, qui a mis en place le livre, a objecté que la source est en MyST et non dans l'un ou l'autre format, et que la documentation stagne par manque de temps investi, pas à cause de la syntaxe. Nick a précisé qu'un ancien dossier de documentation qu'il souhaite fusionner est déjà en Markdown, donc une conversion est inévitable dans un sens ou dans l'autre. La pull request reste ouverte.

Robert Chapin a relancé le RFC de janvier Deprecate Fuzzy Type Casts d'Alexandre Daubois et Nicolas Grekas, qui vise toujours 8.6 malgré l'absence de discussion. Il a montré que les exemples de migration ne tiennent pas : is_numeric() renvoie true pour la chaîne "1.5" et déclencherait toujours la dépréciation, is_int() et is_float() renvoient false pour toute chaîne numérique, et filter_var() ne garantit pas un entier. Sa question, à savoir si les développeurs doivent remplacer un simple cast par 8 lignes de code, est restée sans réponse.

Mahmoudi a aussi soulevé une question de processus : le modèle de RFC devrait-il recommander un polyfill utilisateur pour les nouvelles fonctions ? Un polyfill fige le comportement exact, cas limites compris, sans lecture du C, et donne une longueur d'avance à des projets comme les polyfills Symfony. Garfield a jugé raisonnable une recommandation sans obligation et a ajouté qu'un polyfill sert aussi de référence de benchmark pour vérifier qu'une implémentation C est réellement plus rapide.

Gina P. Banyard a corrigé le RFC déjà accepté de Steven Wilton sur les améliorations SNMP : prétendre cibler toutes les versions PHP supportées contredit la politique de patchs, les changements n'arriveront donc que dans 8.6. Elle a aussi demandé que les nouvelles constantes entières deviennent des enums PHP, pour une meilleure sûreté de typage côté utilisateur, en miroir des enums C de SNMP. L'objectif est une fusion à temps pour 8.6.0 beta 2.

Weilin Du, mainteneur de l'extension intl, a listé des travaux à déléguer : convertir les constantes en enums, ajouter des espaces de noms aux classes pour éviter les collisions, combler les écarts entre les API PHP et ICU, et améliorer la gestion des erreurs, qu'il a qualifiée sans détour de mauvaise et source de bugs stupides. Les enums et namespaces pourraient faire l'objet d'un RFC pour 8.7. Yuya Hamada a souligné que les retours des utilisateurs de langues s'écrivant de droite à gauche sont rares dans toute l'industrie, ce qui pèse sur la qualité de l'internationalisation.

En bref : le RFC array_search_range() de la semaine précédente a été officiellement retiré après une critique en 7 points de mickmackusa. La proposition de Weilin Du sur la sensibilité à la casse des noms d'extensions deviendra un RFC en raison de l'objection d'un développeur core, avec un vote après la création de la branche 8.6 le 22 septembre. Et le nouveau venu Zachary DuBois, à qui l'on a dit qu'une simple pull request suffisait, a soumis en première contribution des liaisons sodium pour les algorithmes post-quantiques d'encapsulation de clés X-Wing et ML-KEM-768. Pour la deuxième semaine consécutive, aucun RFC n'était en phase de vote.