The Daily Commit · Section Edition Front Page PHP AI Dev EN DE FR ES

The Php Times

RFC Watch — Ecosystem

Debate over CSV deprecations in the PHP 8.6 deprecations RFC


The Deprecations for PHP 8.6 RFC has passed its vote, but discussion on internals continues.

PHP INTERNALS ([RFC]/[VOTE]), August 15, 2026 curated by Giselle

Robert Humphries argues that deprecating SplFileObject CSV methods like fputcsv() and setCsvControl() leaves the READ_CSV flag in an inconsistent state without a clear migration path.

The vote on the Deprecations for PHP 8.6 RFC has passed, yet the discussion on the internals list shows the proposal leaves open questions around CSV handling in SPL.

Robert Humphries raises two objections. First, the RFC does not state what existing code should migrate to. Code built around SplFileObject::fputcsv() cannot simply switch to the procedural fputcsv(), because that function expects a stream resource and is therefore not a drop-in replacement.

Second, the SplFileObject::READ_CSV flag is not part of the deprecation. setCsvControl() is the only way to configure delimiter, enclosure and escape character for READ_CSV, since the constructor does not accept them. If setCsvControl() disappears in PHP 9 while READ_CSV survives, the flag is locked to its defaults and tab-separated files can no longer be read through it. The default value of $escape is itself already deprecated and scheduled to change.

Humphries concludes that either READ_CSV should be deprecated alongside the four methods, or setCsvControl() should be kept until a replacement API exists. A follow-up note points out that with the vote passed, deprecating READ_CSV as well appears necessary. Otherwise code using READ_CSV would behave differently across PHP versions once the $escape default changes, with no way to make it consistent manually.

Read the original source ↗

Rate this article: 0

Readers’ Forum

No contributions yet — open the debate.

← Ecosystem — Page B1

"All the Code That's Fit to Ship" · The Daily Commit · Screen edition · Imprint · Privacy Policy