Re: [RFC] Kill proprietary CSV escaping mechanism

On 30.09.2018 at 22:17, Stanislav Malyshev wrote: >> If we cannot eventually get rid of the escaping for CSV reading (note >> that I proposed to keep the possibility to use it until PHP *9*), I >> don't think that we should remove it for CSV writing either, since that >> would make SplFileObject::setCsvControl() and ::getCsvControl() pretty >> much confusing. Consequently, it wouldn't make sense to deprecate using > > SplFileObject is a bit of a problem since it has single setting for both > reading and writing. I'd say it's fine to deprecate using escape there, > with the idea that if somebody needs it for reading, they'd ignore the > deprecation message, or use fgetcsv. I guess using single set of setting > for both read and write is not that great an idea, in retrospect, but we > probably can't do too much about it. > > I think allowing not having an escape and making it the default is a > good idea, though mismatch between read and write may be problematic. At > least the first part - allowing not having escape - I think should be > done and does not need RFC even, but the default change probably does > and I think this should be in a major version, since it's a BC break, > albeit not a major one. So, I'd do this: > > 1. Enable no escape char at all ASAP > 2. Switch to no escape by default for read & write for PHP 8 > 3. Deprecate non-empty escape for SplFileObject and fputcsv for PHP 8, > leave fgetcsv alone. I don't think we're doing anyone a favor by introducing even more inconsistencies between reading and writing CSV. Also, if we stick with the legacy CSV reading, we can't simplify the overly complex implementation. Therefore, I suggest to only add support for an empty $escape parameter (PR #3515), and withdraw the RFC to deprecate and eventually remove the proprietary escaping mechanism. -- Christoph M. Becker