Muhammed Arshid KV opened the discussion by proposing, within the PHP 8.6 deprecations RFC, to retire SplFileObject's CSV methods — fputcsv(), fgetcsv(), setCsvControl() and getCsvControl(). He argued that these methods are difficult to maintain and that their behavior with named arguments reveals inconsistent design choices behind long-running problems. As an alternative, he floated a dedicated ext/csv extension built around streams, pointing to pull request php-src#22160 for reference.

Gina P. Banyard, who maintains the bulk RFC, said she was open to adding a written proposal for this change — DokuWiki format preferred, though Markdown would also work — but made clear she would not draft it herself.

Ignace Nyamagana Butera objected that deprecating the existing API before a replacement exists is premature. In his view, PHP should first ship a better CSV experience; deprecation should only follow once the community agrees on a new API, it gains real adoption, and a smooth migration path exists.

Takuya Aramaki seconded the objection near the end of the vote with two concrete points. First, the RFC never states what code relying on SplFileObject::fputcsv() should switch to; the procedural fputcsv() function survives the proposal, but since it operates on a stream resource rather than an object, it cannot simply substitute for SplFileObject-based code. Second, the proposal leaves the SplFileObject::READ_CSV flag untouched, which he sees as an oversight: setCsvControl() is currently the only method for setting the delimiter, enclosure and escape characters that READ_CSV relies on, since the constructor offers no such parameters. Removing setCsvControl() in PHP 9 while keeping READ_CSV would therefore freeze the flag at whatever defaults it has — defaults that are themselves unstable, since the $escape default is already marked for a future change. He suggested that either READ_CSV be deprecated together with the four methods, or that setCsvControl() remain available until a proper alternative exists.