Muhammed Arshid KV a proposé de déprécier les méthodes CSV de SplFileObject — fputcsv(), fgetcsv(), setCsvControl() et getCsvControl() — dans le cadre de la RFC des dépréciations pour PHP 8.6. Sa justification : ces API sont complexes et difficiles à maintenir, et les arguments nommés révèlent des incohérences de conception à l'origine de problèmes de longue date. Il suggère de les remplacer par une extension dédiée ext/csv offrant une API CSV plus propre et orientée flux, avec un lien vers la pull request php-src#22160.

Gina P. Banyard, auteure de la RFC groupée, s'est dite prête à intégrer une proposition rédigée (de préférence au format DokuWiki, Markdown accepté), mais ne la rédigerait pas elle-même.

Ignace Nyamagana Butera a objecté que déprécier l'API actuelle sans même un début de remplacement serait prématuré. Selon lui, PHP devrait d'abord proposer une meilleure expérience CSV ; la dépréciation ne devrait être envisagée qu'une fois la communauté d'accord sur une nouvelle API, celle-ci adoptée et un chemin de migration simple disponible.

Takuya Aramaki a appuyé cette objection peu avant la fin du vote avec deux points concrets. Premièrement, la RFC n'indique aucune cible de migration : la fonction procédurale fputcsv() n'est pas concernée, mais elle exige une ressource de flux et ne constitue donc pas un remplacement direct pour le code structuré autour de SplFileObject. Deuxièmement, le drapeau SplFileObject::READ_CSV n'est pas couvert par la proposition. Or setCsvControl() est le seul moyen de configurer le délimiteur, l'enclosure et le caractère d'échappement utilisés par READ_CSV (le constructeur ne les accepte pas). Supprimer setCsvControl() en PHP 9 tout en conservant READ_CSV figerait définitivement le drapeau sur ses valeurs par défaut — sachant que la valeur par défaut de $escape est elle-même déjà dépréciée et appelée à changer. Selon lui, READ_CSV devrait être déprécié avec les quatre méthodes, ou setCsvControl() conservé jusqu'à l'arrivée d'un remplacement.