Re: [RFC] CSV Extension (ext/csv)
| From: | Lynn | Date: | Fri, 09 Oct 2026 07:03:03 +0000 |
| Subject: | Re: [RFC] CSV Extension (ext/csv) | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132845@lists.php.net to get a copy of this message | ||
On Fri, Oct 9, 2026 at 8:22 AM Damian Jóźwiak <damian.jozwiak.lodz@gmail.com>
wrote:
>
> Hi internals,
>
> I'd like to open the discussion on an RFC proposing a dedicated CSV
> extension (ext/csv) for PHP core.
>
> RFC: https://wiki.php.net/rfc/csv_extension
>
> Implementation: https://github.com/php/php-src/pull/24199
>
> The proposal builds upon Gina Peter Banyard's girgias/csv extension
> (BSD-3-Clause), with additional functionality for file and stream handling.
>
> The motivation includes the deprecation of the SplFileObject CSV methods
> in PHP 8.6, which leaves certain use cases without a direct replacement.
>
> The proposed extension provides:
>
> -
>
> Six functions and one class in the Csv\ namespace.
> -
>
> RFC 4180-compatible parsing and serialization by default.
> -
>
> Locale-independent processing without the proprietary escape mechanism..
> -
>
> Multibyte delimiters, enclosures, and EOL sequences.
> -
>
> Strict and lax collection parsing.
> -
>
> Lazy iteration over CSV files and streaming output.
>
> The implementation includes PHPT tests covering parsing, serialization,
> stream handling, resource lifetime, and various edge cases.
>
> The pull request's CI checks are currently passing across the tested
> platforms, including debug, ZTS, and AddressSanitizer configurations.
>
> The initial API is deliberately kept small. A more comprehensive
> object-oriented Reader/Writer API, including capability-oriented
> interfaces, is left for potential future discussion.
>
> I'd particularly appreciate feedback on the public API design, the naming
> of LazyLaxCollection, and whether the extension should be always enabled
> or optional at build time.
>
> For transparency, Gina has not reviewed or endorsed this RFC. Parts of the
> implementation were developed with LLM assistance; I have reviewed the code
> and take full responsibility for the contribution.
>
> This is an invitation for discussion, not a call for votes.
>
> Thanks in advance for your feedback.
>
> Best regards,
> Damian Jóźwiak
>
I see that there's no support for open streams/resources, would that be
something worth adding? I don't want to have to write things to a file
before I can start processing them if I already have an open stream. Same
goes for reading, I don't want to have to read everything before passing it
somewhere, often having it as a resource is more useful to me.
About LazyLaxCollection, what does Lax mean here?