Le vote sur le RFC Deprecations for PHP 8.6 est passé, mais la discussion sur la liste internals montre que la proposition laisse des questions ouvertes concernant la gestion CSV dans SPL.

Robert Humphries soulève deux objections. Premièrement, le RFC n'indique pas vers quoi le code existant doit migrer. Le code construit autour de SplFileObject::fputcsv() ne peut pas simplement passer à la fonction procédurale fputcsv(), car celle-ci attend une ressource de flux et ne constitue donc pas un remplacement direct.

Deuxièmement, le flag SplFileObject::READ_CSV ne fait pas partie de la dépréciation. setCsvControl() est le seul moyen de configurer le délimiteur, l'enclosure et le caractère d'échappement pour READ_CSV, le constructeur ne les accepte pas. Si setCsvControl() disparaît en PHP 9 alors que READ_CSV subsiste, le flag reste figé sur ses valeurs par défaut et les fichiers séparés par des tabulations ne pourront plus être lus ainsi. La valeur par défaut de $escape est elle-même déjà dépréciée et doit changer.

Humphries conclut que soit READ_CSV devrait être déprécié avec les quatre méthodes, soit setCsvControl() devrait être conservé jusqu'à l'existence d'une API de remplacement. Une note ultérieure ajoute que, le vote étant passé, déprécier READ_CSV semble nécessaire. Sinon, le code utilisant READ_CSV se comporterait différemment selon les versions de PHP après le changement du défaut de $escape, sans possibilité de le rendre cohérent manuellement.