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

Mailing Lists php.internals
1

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

2

On Tuesday, 23 June 2026 at 08:53, 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.

ext/spl: Fix default argument handling for named parameters in SplFileObject::fgetcsv() by arshidkv12 · Pull Request #22160 · php/php-src · GitHub

If you provide me with text proposal (ideally in DokuWiki format, but markdown is fine) I'm happy to include it in the bulk RFC.
I will however not be writing it myself.

Best regards,

Gina P. Banyard

3

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

4

On Tue, Jun 23, 2026 at 8:36 AM ignace nyamagana butera <nyamsprod@gmail.com> wrote:

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

Can we deprecate the error suppression operator?

(Not a serious suggestion - just trying to elicit a laugh - ok, ok, I’ll go back to the dunce corner.)

5

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