[RFC] Deprecations for PHP 8.6

3 months ago by Muhammed Arshid KV — view source — reply

unread

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

3 months ago by Gina P. Banyard — view source — reply

unread

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

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 months ago by ignace nyamagana butera — view source — reply

unread

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

3 months ago by Michael Morris — view source — reply

unread

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.)

1 month ago by Takuya Aramaki — view source — reply

unread

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