Re: [RFC] CSV Extension (ext/csv)

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 > Hi Damien, thanks for the proposal, indeed with the deprecation of SplFileObject CSV feature an object oriented alternative is welcomed having said that.I have a couple of remarks/suggestions - Following Tim's thought, I wonder if a CSV top namespace is mandatory or if we should not just have a Serialization "namespace" name that can be improved when such classes and functions are defined. - *RFC 4180-compatible parsing and serialization by default. *As much as I am a proponent of backing RFC whenever they exist in this case it should be stressed out that RFC4180 is not an accepted RFC like for instance RFC3986 for URI specification as such it is totally possible to have a valid CSV which does not comply with the refer draft specification. I believe this should be noted and explained in the RFC to avoid pushing forward something which is not a real specification as anyone would expect even though it is widely accepted as the "default" implementation, - Hence why I believe that using terms like *lax* and *strict* is counter productive; probably other names "to be defined" should be used instead. Maybe adding an Enum With RFC4180 and something else (?) would be a better take. Which would reduce the number of function/methods introduced ? - Also while it is common to talk about CSV, this feature would be perhaps better called *Character Separated Value* than Comma Separated Value since the delimiter can be changed. And covers TSV and other exotic formats which separates values per single character. The stream is owned by the object: like the stream of SplFileObject, it > remains visible as a resource but fclose() refuses to close it, and it is > closed when the object is destroyed (for an object alive until the end of > the request, while destructors run, so a user wrapper's stream_close() is > still called). Does it mean that the LazyLaxCollection will expose the stream metadata ? If I receive in my method/function a LazyLaxCollection is it possible for me to get access to the underlying resource metadata ? To know how it is open, its pathname , and so forth ? Can I easily detect if Being able to configure the context or to apply stream filter is also something I find useful with the current set of csv function even with SplFileObject (even though it is tricky with that one) I would expect any API which aim at replacing the current CSV API to offer at most the same extensibility or to allow it in any other shape or form. function collection_to_file(string $file, iterable $collection, string $delimiter = ',', string $enclosure = '"', string $eolSequence = "\r\n"): void {} Why? can't we have access to the written bytes as returned value. Otherwise it means we need to re-access the resource afterward if we want to get access to that value. For example if we want to generate the Content-Length header or something else ? Overall, I like the direction of the RFC but I believe some major discussion points remain unsolved before going to a vote Best regards, Ignace