On Thursday, September 27, 2018 5:29 AM Christoph M. Becker <cmbecke...@gmx.de> wrote:
> I hereby put the “Kill proprietary CSV escaping mechanism” under discussion: > > <https://wiki.php.net/rfc/kill-csv-escaping> > > Any comments are welcome! Huge +1 from me! This would remove the need for a lot of nasty hacks and workarounds when reading/writing CSVs. >From my perspective, the first part of the proposal (allow passing an empty string as the $escape argument) hardly needs an RFC, since it's essentially a bugfix and shouldn't break userland. So it seems like the main question the RFC will decide is a deprecation timeline for the $escape argument. I'm not sure it makes sense to have separate deprecation phases for passing a non-empty $escape string, and passing an explicit escape argument at all. This would require developers to change their code twice: once to pass an empty string, and again to remove the empty string. Would it be acceptable to change the default value of $escape to an empty string and deprecate passing an explicit $escape parameter in PHP 7.4? This would be a minor BC break, but would allow developers to fix their code once, so it will continue working when the escape parameter is removed (possibly in PHP 8). But in the end I don't care so much about the exact timeline, as long as this issue can finally be fixed! Thanks again for your work on this, Theodore Brown -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
