Clarification about deprecate proprietary CSV escaping mechanism

From: Date: Thu, 19 Sep 2024 10:17:38 +0000
Subject: Clarification about deprecate proprietary CSV escaping mechanism
Groups: php.internals 
Request: Send a blank email to internals+get-125628@lists.php.net to get a copy of this message
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

« previous php.internals (#125628) next »