Fwd: [PHP-DEV] [RFC] Deprecations for PHP 8.6

Tue, 23 Jun 2026 12:36 ignace nyamagana butera <nyamsprod@gmail.com>: > On Tue, Jun 23, 2026 at 9:56 AM Muhammed Arshid KV <arshidkv12@gmail.com> > wrote: > >> Hi, >> >> I propose deprecating SplFileObject CSV methods like fputcsv, fgetcsv, >> setCsvControl, and getCsvControl. >> >> These APIs are complex and hard to maintain, and named arguments expose >> design inconsistencies, causing long-standing issues. >> >> We should consider replacing them with a dedicated ext/csv that provides >> a cleaner, stream-friendly CSV API. >> >> https://github.com/php/php-src/pull/22160 >> >> >> Regards. >> >> Arshid >> >> >> >> Hi Arshid, > > While I agree that CSV handling can and should be improved in core PHP, > deprecating the current API without providing at least the start of a > replacement API seems premature to me. > We should first focus on providing a better/improved CSV experience in > PHP. Then, if: > > - we all agree on a new API > - everyone starts using it and it becomes popular > - and the path to migrate to the new API is made as straightforward as > possible > > then we can start discussing the process of deprecating the current > feature. Anything else would be counterproductive at the moment. > > Best regards, > Ignace > Hi, Apologies for bringing this up so close to the end of the vote. I'd like to second this as a user, with two specific points about the "Deprecate SplFileObject CSV methods" section. First, the RFC does not say what existing code should migrate to. I often use SplFileObject::fputcsv() for generating CSV files. The procedural fputcsv() is not affected by this proposal, but it takes a stream resource, so it is not a drop-in replacement for code that is structured around SplFileObject. Is there an intended migration path that I have missed? If so, I think it would help to have it stated in the RFC, as the other sections in this RFC do. Second, SplFileObject::READ_CSV is not part of the proposal, which I think leaves the outcome in an inconsistent state. setCsvControl() is the only way to configure the delimiter, enclosure and escape character used by READ_CSV; the constructor does not accept them. If setCsvControl() is removed in PHP 9 while READ_CSV remains, READ_CSV is permanently locked to its defaults and tab-separated files can no longer be read through it. The default value of $escape is also already deprecated and scheduled to change, so what would survive is a flag that cannot be configured and whose defaults are still unsettled. Either READ_CSV should be deprecated alongside the four methods, or setCsvControl() should be retained until a replacement API is available. I would appreciate clarification on both points. Regards, Takuya