Clarification about deprecate proprietary CSV escaping mechanism
| From: | Christoph M. Becker | 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