Clarification about deprecate proprietary CSV escaping mechanism

php.internals

Christoph Becker

1 year ago
Hi all, there is some debate regarding the implementation of the "Deprecate proprietary CSV escaping mechanism" RFC section[1], which needs clarification from the list, in my opinion. That RFC section perhaps used some unclear wording: | Which is to deprecate passing a non-empty string to the $escape | parameter to all the CSV related functions, […] The original implementation[2] raised deprecation warnings only when a non-empty string has been passed *explicitly*. That still left a loophole when *implicitly* passing a non-empty string (i.e. using the parameter default). This loophole has been closed via a follow-up PR[3], where the debate came up. Now, the argument has been brought up that this effectively makes the parameter mandatory, and that change would not have been according to the RFC section, possibly invalidating the vote. How should we proceed? Note that we're only 5 days away from feature-freeze/branch cut. [1] <https://wiki.php.net/rfc/deprecations_php_8_4#deprecate_proprietary_csv_escaping_mechanism> [2] <https://github.com/php/php-src/pull/15362> [3] <https://github.com/php/php-src/pull/15569> Christoph

Kamil Tekiela

1 year ago
I've voted to deprecate based on my understanding that either passing a non-empty string or relying on the default value would trigger a deprecation. It wouldn't make sense for me to only deprecate passing an explicit argument. I agree that the path forward has not been made clear in the RFC. Will the escape parameter be dropped in PHP 9? Will only the default value change? So if there's a debate about what the RFC actually meant, I wouldn't mind postponing this change.