# [RFC] Deprecations for PHP 7.3 - Thread: https://externals.io/message/102394 - Original archive: https://news-web.php.net/php.internals/102394 - Started by Nikita Popov on 2018-06-24T16:47:29+00:00 - Messages: 45 - RFC: Deprecations for PHP 7.3 (Implemented (PHP 7.3)) — https://externals.io/rfc/deprecations_php_7_3.md - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/102394.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #102394 — Nikita Popov — 2018-06-24T16:47:29+00:00 URL: https://externals.io/message/102394#102394 Hi internals, This RFC collects a number of deprecations for PHP 7.3 which I consider to be too minor to warrant a separate proposal. However, each deprecation will still be voted separately. https://wiki.php.net/rfc/deprecations_php_7_3 If you have a minor deprecation in mind, but were too lazy to write an RFC for it, please write me a mail until tomorrow, so that it might be included as part of this proposal. As time is limited I don't want to include anything larger or controversial in this RFC though. Regards, Nikita --- ## #102400 — Christoph M. Becker — 2018-06-24T20:29:09+00:00 URL: https://externals.io/message/102394#102400 · In reply to: #102394 > This RFC collects a number of deprecations for PHP 7.3 which I consider to > be too minor to warrant a separate proposal. However, each deprecation will > still be voted separately. > > https://wiki.php.net/rfc/deprecations_php_7_3 Thanks. FWIW, I'm +1 on all 4 proposals. > If you have a minor deprecation in mind, but were too lazy to write an RFC > for it, please write me a mail until tomorrow, so that it might be included > as part of this proposal. As time is limited I don't want to include > anything larger or controversial in this RFC though. I've recently submitted to deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED. I don't think this needs an RFC, but it might be something which could be added to this RFC? -- Christoph M. Becker --- ## #102410 — Stanislav Malyshev — 2018-06-25T06:12:48+00:00 URL: https://externals.io/message/102394#102410 · In reply to: #102394 Hi! > This RFC collects a number of deprecations for PHP 7.3 which I consider to > be too minor to warrant a separate proposal. However, each deprecation will > still be voted separately. > > https://wiki.php.net/rfc/deprecations_php_7_3 > Undocumented mbstring function aliases Not sure what this would give us. Yes, they are undocumented, but do they hurt anything? > String search functions with integer needle That is definitely weird. However, I am not sure what should happen in non-integer cases - i.e. what happens if I pass a double? Or a boolean? > fgetss() function and string.strip_tags filter I think I disagree with "strip_tags() itself, due to its limitations and known bugs, already has very few legitimate applications" and certainly the manual does not have any notice to that effect. I am not sure what is the reason to remove this functionality, would like to hear more about it - and it doesn't seem so minor as to be 1/4 of the RFC. If I had to vote today, I'd probably vote no just on this point. It may be true that `strip_tags()` alone without streaming part could be implemented easier. However, that is not a reason to drop functionality by itself, unless it's already completely broken. If it is, I'd like to hear more about it. > Defining a free-standing `assert()` function Sounds good. -- Stas Malyshev smalyshev@gmail.com --- ## #102411 — Christoph M. Becker — 2018-06-25T08:10:49+00:00 URL: https://externals.io/message/102394#102411 · In reply to: #102410 > > […] > > I think I disagree with "strip_tags() itself, due to its limitations and > known bugs, already has very few legitimate applications" and certainly > the manual does not have any notice to that effect. I am not sure what > is the reason to remove this functionality, would like to hear more > about it - and it doesn't seem so minor as to be 1/4 of the RFC. If I > had to vote today, I'd probably vote no just on this point. > It may be true that `strip_tags()` alone without streaming part could be > implemented easier. However, that is not a reason to drop functionality > by itself, unless it's already completely broken. If it is, I'd like to > hear more about it. There are multiple bug reports regarding `strip_tags()`'s broken behavior on (slightly) malformed HTML, e.g. , and , which renders the function unusable on arbitrary user supplied input. -- Christoph M. Becker --- ## #102436 — Stanislav Malyshev — 2018-06-25T18:50:39+00:00 URL: https://externals.io/message/102394#102436 · In reply to: #102411 Hi! > There are multiple bug reports regarding `strip_tags()`'s broken behavior > on (slightly) malformed HTML, e.g. , > and , which > renders the function unusable on arbitrary user supplied input. I see a very corner-case issues that don't really make it "unusable" - in fact, in these examples it looks like it chooses the most safe approach. Which means it can't be used to fix broken HTML or parse Javascript scripts, but that's not the point of this function anyway. -- Stas Malyshev smalyshev@gmail.com --- ## #102439 — Sara Golemon — 2018-06-25T19:32:07+00:00 URL: https://externals.io/message/102394#102439 · In reply to: #102394 > https://wiki.php.net/rfc/deprecations_php_7_3 > > Undocumented mbstring function aliases > Yeah, if they're just dumb aliases, then it's a slight gain to narrow the symbol table by removing duplicates. A modest composer package (nay, include file) would be sufficient to provide a bridge for existing projects which use the removed aliases once they're gone. This deprecation isn't *needed*, but it's also fairly low impact. 🤷 > String search functions with integer needle > Agree with stas, the wtf quotient on this one is high. Mitigating this is the availability of strict types, but even still I think deprecating the behavior altogether is a wise move. Callers can easily insert a call to `chr()` (or IntlChar::chr() ) to maintain the old behavior in a version agnostic way. 😕 > fgetss() function and string.strip_tags filter > "...these functions seem to be of very little utility..." [citation needed] Anecdotally I struggle to imagine the use-case, but my imagination isn't what it once was. There's not a trivial workaround for someone who's dealing with a large/streaming data source from which they want to strip tags. Deprecating this should come at a higher standard of: proving that it is used, providing a userspace replacement, or both. 😤 > Defining a free-standing `assert()` function > Eww, yeah. I can see that problem. I'm not a huge fan of banning all namespaced `assert()` function declarations, but it's certainly the most direct "solution" to the problem. A very quick scan of github only shows one effected usage in a repo with no followers/stars apart from the owner. Given the lack of whole-program analysis, it's either ban the declarations, or abandon elision. Frankly, the number of people taking advantage of the free dev-only check is probably way higher than the number trying to define a function called 'assert' so.... 😬 -Sara --- ## #102452 — Marco Pivetta — 2018-06-26T11:27:42+00:00 URL: https://externals.io/message/102394#102452 · In reply to: #102439 > > […] > Eww, yeah. I can see that problem. I'm not a huge fan of banning all > namespaced `assert()` function declarations, but it's certainly the most > direct "solution" to the problem. A very quick scan of github only > shows one effected usage in a repo with no followers/stars apart from > the owner. Given the lack of whole-program analysis, it's either ban > the declarations, or abandon elision. Frankly, the number of people > taking advantage of the free dev-only check is probably way higher > than the number trying to define a function called 'assert' so.... 😬 Or require a FQN for an imported `assert()`? Importing functions is getting traction. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ --- ## #102456 — Nicolas Grekas — 2018-06-26T15:39:24+00:00 URL: https://externals.io/message/102394#102456 · In reply to: #102394 > https://wiki.php.net/rfc/deprecations_php_7_3 > Do you think we could ass Serializable to the list? See your own arguments in https://externals.io/message/98834 :) Nicolas --- ## #102458 — Kalle Sommer Nielsen — 2018-06-26T16:31:50+00:00 URL: https://externals.io/message/102394#102458 · In reply to: #102394 Hi Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov : > If you have a minor deprecation in mind, but were too lazy to write an RFC > for it, please write me a mail until tomorrow, so that it might be included > as part of this proposal. As time is limited I don't want to include > anything larger or controversial in this RFC though. As suggested in the past, I would like to add the following to this list (if its not too late): - The (real) type-cast and its function, is_real(). There doesn't seem to be any support for reals in `settype()` anyway (side note: in the implementation of `settype()` it claims "double" is deprecated) - Function variants that already exists as constants, `php_sapi_name()` > PHP_SAPI, `pi()` > M_PI, `phpversion()` > `PHP_VERSION` etc - enable_dl ini directive, as `dl()` is only operational for CLI and Embed anyway - pdo_odbc.db2_instance_name ini directive, its been marked as deprecated and mentioned in the manual since PHP 5.1.11 that it will *certainly* be removed in the future - The 'b' constant string prefix, its not used and was meant as to make code ready for PHP6, should the time come where we want to add a feature that uses this, we can always re-add it Other things thats been suggested by others in the past: - Second parameter of `spl_autoload()` and its associated function `spl_autoload_extensions()` - hebrevc() -- same as `hebrev()` + `nl2br()`, perhaps even deprecate `hebrev()` too (see next one) - convert_cyr_string() -- Point to `mb_convert_encoding()` / iconv - Remove get_magic_quotes_gpc(), not been working for what, 5+ years now? - allow_url_include ini option, this can lead to all kinds of security complications anyway - The alternative string interpolation syntaxes (${varName}, ${varName['offset']}, ${expr}) and make them more consistent ({$varName}, {$varName['offset']}, {${expr}}) - The historial parameter handling that works both ways for `implode()`, should be unified to match that of `explode()` I could probably think of more, but thats all I got for now. I can and will of course help produce the relevant patches should it be needed for most of these things. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #102459 — Nikita Popov — 2018-06-26T17:15:40+00:00 URL: https://externals.io/message/102394#102459 · In reply to: #102400 On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker wrote: > > > > […] > to > > […] > will > > […] > > Thanks. FWIW, I'm +1 on all 4 proposals. > > > […] > RFC > > […] > included > > […] > > I've recently submitted to > deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED. I > don't think this needs an RFC, but it might be something which could be > added to this RFC? > I've added these deprecations to the RFC. Please feel free to update the description if you'd like to add something. I think it would have been fine to also land these deprecations directly (as you already wrote to internals about it in the past), but as the have the opportunity, we might as well go through the motions. Nikita --- ## #102460 — Nikita Popov — 2018-06-26T18:16:29+00:00 URL: https://externals.io/message/102394#102460 · In reply to: #102458 > Hi > > Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov > […] > RFC > > […] > included > > […] > > As suggested in the past, I would like to add the following to this > list (if its not too late): > > - The (real) type-cast and its function, is_real(). There doesn't > seem to be any support for reals in `settype()` anyway (side note: in > the implementation of `settype()` it claims "double" is deprecated) > - Function variants that already exists as constants, `php_sapi_name()` > > […] > - enable_dl ini directive, as `dl()` is only operational for CLI and Embed > anyway > - pdo_odbc.db2_instance_name ini directive, its been marked as > deprecated and mentioned in the manual since PHP 5.1.11 that it will > *certainly* be removed in the future > Feel free to add this one to the RFC, if you know what the background for the deprecation is. Given that the manual already marks it as deprecated for so long, this seems like a mere technicality. > - The 'b' constant string prefix, its not used and was meant as to > make code ready for PHP6, should the time come where we want to add a > feature that uses this, we can always re-add it > > Other things thats been suggested by others in the past: > > - Second parameter of `spl_autoload()` and its associated function > `spl_autoload_extensions()` > - hebrevc() -- same as `hebrev()` + `nl2br()`, perhaps even deprecate > `hebrev()` too (see next one) > - convert_cyr_string() -- Point to `mb_convert_encoding()` / iconv > - Remove get_magic_quotes_gpc(), not been working for what, 5+ years now? > - allow_url_include ini option, this can lead to all kinds of > security complications anyway > - The alternative string interpolation syntaxes (${varName}, > ${varName['offset']}, ${expr}) and make them more consistent > ({$varName}, {$varName['offset']}, {${expr}}) > - The historial parameter handling that works both ways for > `implode()`, should be unified to match that of `explode()` > > I could probably think of more, but thats all I got for now. I can and > will of course help produce the relevant patches should it be needed > for most of these things. > Given the recent discussions about having a PHP 7.4 release for additional deprecations, I'm going to punt on the rest. While they may be no-brainers to you and I, a lot of those are actually quite controversial (e.g. there was an RFC to deprecate b' in 7.2 and it was declined -- go figure!) I'd suggest that you already open up the next deprecation RFC, to make sure these are not forgotten. Some of them should probably get separate proposals altogether (especially the var interpolation syntax). Nikita --- ## #102462 — Nikita Popov — 2018-06-26T18:54:16+00:00 URL: https://externals.io/message/102394#102462 · In reply to: #102439 > On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov > wrote: > > […] > Yeah, if they're just dumb aliases, then it's a slight gain to narrow > the symbol table by removing duplicates. A modest composer package > (nay, include file) would be sufficient to provide a bridge for > existing projects which use the removed aliases once they're gone. > This deprecation isn't *needed*, but it's also fairly low impact. 🤷 > > > […] > Agree with stas, the wtf quotient on this one is high. Mitigating > this is the availability of strict types, but even still I think > deprecating the behavior altogether is a wise move. Callers can > easily insert a call to `chr()` (or IntlChar::chr() ) to maintain the > old behavior in a version agnostic way. 😕 > > > […] > "...these functions seem to be of very little utility..." [citation needed] > Anecdotally I struggle to imagine the use-case, but my imagination > isn't what it once was. There's not a trivial workaround for someone > who's dealing with a large/streaming data source from which they want > to strip tags. Deprecating this should come at a higher standard of: > proving that it is used, providing a userspace replacement, or both. > 😤 > Some background here. Originally this RFC suggested to deprecate `strip_tags()` entirely, but based on early feedback I decided not to. The original motivation for `strip_tags()` was basically that the function has few legitimate applications, but is easy to use in the wrong way. The two misuses I have seen often enough to motivate a deprecation are: a) Without allowed_tags: People using `strip_tags()` where they really just want `htmlspecialchars()`. It's obvious to you and I that this is a bad idea, but there are really people out there who do this. I've actually had discussions on StackOverflow with people who did not want to believe that, yes, using `htmlspecialchars()` is safe and they do not need to use `strip_tags()` to eliminate XSS threats. Using `strip_tags()` for this purpose is made worse by the fact that it cuts off all text after a standalone <. b) With allowed_tags: People thinking that using this is safe. Because attributes on allowed tags are preserved, `strip_tags()` in this mode provides zero safety guarantees. The correct alternative is to use something like HtmlPurifier. However, there are also not entirely illegitimate applications: a) Without allowed_tags: Convert HTML to plain-text for use in emails. This is not a good solution, but it's a quick&dirty way to make things work. b) With allowed_tags: In combination with WYSIWYG editors that generate certain HTML tags and under the assumption that the input is completely trusted. The use of `strip_tags()` here is more about preventing the users from shooting themselves in the foot than about security. Of course, there are also the implementation issues with strip_tags. I already mentioned that one problem is that all text after < is cut off and cmb pointed to some more bugs. This makes `strip_tags()` over-aggressive in the cases where it's use might generally be legitimate. This RFC goes the conservative route of only deprecating the streaming functionality, which is the main source of complexity in the implementation, while also being the least useful aspect of it. > > […] > Eww, yeah. I can see that problem. I'm not a huge fan of banning all > namespaced `assert()` function declarations, but it's certainly the most > direct "solution" to the problem. A very quick scan of github only > shows one effected usage in a repo with no followers/stars apart from > the owner. Given the lack of whole-program analysis, it's either ban > the declarations, or abandon elision. Frankly, the number of people > taking advantage of the free dev-only check is probably way higher > than the number trying to define a function called 'assert' so.... 😬 > TBH I'd be fine with just ignoring this issue. I only included this because I got some loud complaints from some users who tried to do something like this and ran into the issue. Nikita --- ## #102465 — Kalle Sommer Nielsen — 2018-06-26T19:51:28+00:00 URL: https://externals.io/message/102394#102465 · In reply to: #102460 Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov : > Feel free to add this one to the RFC, if you know what the background for the deprecation is. Given that the manual already marks it as deprecated for so long, this seems like a mere technicality. I added the pdo_odbc.db2_instance_name to the RFC including 2 options which is up to you to decide for with the relevant patches included. > Given the recent discussions about having a PHP 7.4 release for additional deprecations, I'm going to punt on the rest. While they may be no-brainers to you and I, a lot of those are actually quite controversial (e.g. there was an RFC to deprecate b' in 7.2 and it was declined -- go figure!) > > I'd suggest that you already open up the next deprecation RFC, to make sure these are not forgotten. Some of them should probably get separate proposals altogether (especially the var interpolation syntax). > > Nikita I agree that a lot of them are controversial, and perhaps its a good idea to start flesh them out for our users and fellow contributors already now. I began a draft based on your 7.3 RFC for 7.4[1]. Ps I took the liberty of adding your name as the RFC author. [1] https://wiki.php.net/rfc/deprecations_php_7_4 -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #102466 — Nikita Popov — 2018-06-26T20:01:24+00:00 URL: https://externals.io/message/102394#102466 · In reply to: #102465 > Den tir. 26. jun. 2018 kl. 20.16 skrev Nikita Popov > […] > for the deprecation is. Given that the manual already marks it as > deprecated for so long, this seems like a mere technicality. > > I added the pdo_odbc.db2_instance_name to the RFC including 2 options > which is up to you to decide for with the relevant patches included. > Thanks for adding it. Unless there is a particular reason to rush here, I'd suggest to follow the usual process and formally deprecate the option prior to removal. As a clarification, what is the alternative to using this ini setting? I guess you can just explicit set the DB2INSTANCE env var, but that probably has the same issues. Is there a "correct" way to do this? (Sorry if it's obvious, I'm not familiar with ODBC.) > > […] > additional deprecations, I'm going to punt on the rest. While they may be > no-brainers to you and I, a lot of those are actually quite controversial > (e.g. there was an RFC to deprecate b' in 7.2 and it was declined -- go > figure!) > > […] > sure these are not forgotten. Some of them should probably get separate > proposals altogether (especially the var interpolation syntax). > > […] > > I agree that a lot of them are controversial, and perhaps its a good > idea to start flesh them out for our users and fellow contributors > already now. I began a draft based on your 7.3 RFC for 7.4[1]. Ps I > took the liberty of adding your name as the RFC author. > > [1] https://wiki.php.net/rfc/deprecations_php_7_4 > Thanks! Nikita --- ## #102467 — Kalle Sommer Nielsen — 2018-06-26T20:12:02+00:00 URL: https://externals.io/message/102394#102467 · In reply to: #102466 Den tir. 26. jun. 2018 kl. 22.01 skrev Nikita Popov : > Thanks for adding it. Unless there is a particular reason to rush here, I'd suggest to follow the usual process and formally deprecate the option prior to removal. I don't think theres a need for a rush here, tho I wasn't sure how you prefered we handled the ini directive deprecation, I thought adding it to main.c would be too "noisy". > As a clarification, what is the alternative to using this ini setting? I guess you can just explicit set the DB2INSTANCE env var, but that probably has the same issues. Is there a "correct" way to do this? (Sorry if it's obvious, I'm not familiar with ODBC.) I'm not too familiar with it either, I just remember it from way back then when I began the crusade to kill old functionality in the 5.3 development days. I don't think there is any other alternative than setting it manually, which still creates the same issues as what it already does not but forces our users to be explicit about it. I personally don't like such magic behind the scenes. As for any correct way, I don't think there is any other, given how the ibm_db2 pecl package mimics the same behavior as pdo_odbc does, but then again the IBM folks have not been the fastest to update their extensions, so maybe there there is a new way to do it now but I doubt it. I don't really have the interest to dig too much into it either. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #102468 — Kalle Sommer Nielsen — 2018-06-26T20:22:11+00:00 URL: https://externals.io/message/102394#102468 · In reply to: #102394 Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov : > If you have a minor deprecation in mind, but were too lazy to write an RFC > for it, please write me a mail until tomorrow, so that it might be included > as part of this proposal. As time is limited I don't want to include > anything larger or controversial in this RFC though. I took the liberty and added the FILTER_SANITIZE_MAGIC_QUOTES to the RFC so we may once and for all get rid of magic_quotes. -- regards, Kalle Sommer Nielsen kalle@php.net --- ## #102470 — Christoph M. Becker — 2018-06-26T20:43:19+00:00 URL: https://externals.io/message/102394#102470 · In reply to: #102459 > On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker > wrote: > > > […] > > I've added these deprecations to the RFC. Please feel free to update the > description if you'd like to add something. Thanks. It's already very well done. :) -- Christoph M. Becker --- ## #102474 — Stanislav Malyshev — 2018-06-27T00:38:53+00:00 URL: https://externals.io/message/102394#102474 · In reply to: #102458 Hi! > - The (real) type-cast and its function, is_real(). There doesn't > seem to be any support for reals in `settype()` anyway (side note: in > the implementation of `settype()` it claims "double" is deprecated) > - Function variants that already exists as constants, `php_sapi_name()` > > […] Weighting bc preak potential vs. improvement benefit, I am not sure it's worth it for both. Maybe for "real" it's ok as I haven't really seen anybody using it in ages, looks like most Fortran programmers either retired or aren't using PHP :) > - enable_dl ini directive, as `dl()` is only operational for CLI and Embed anyway Makes sense. > - The 'b' constant string prefix, its not used and was meant as to > make code ready for PHP6, should the time come where we want to add a > feature that uses this, we can always re-add it Yeah this one we probably just have to remove, it doesn't do anything now. > Other things thats been suggested by others in the past: > > - Second parameter of `spl_autoload()` and its associated function > `spl_autoload_extensions()` Why? > - hebrevc() -- same as `hebrev()` + `nl2br()`, perhaps even deprecate > `hebrev()` too (see next one) Probably less useful now that browsers finally can render bidi texts properly, but may be still useable for workloads where bidi rendering is not available. And I see no problem with function doing something that is achievable by other functions. > - convert_cyr_string() -- Point to `mb_convert_encoding()` / iconv Maybe just make it a pseudo-alias for iconv? > - The alternative string interpolation syntaxes (${varName}, > ${varName['offset']}, ${expr}) and make them more consistent > ({$varName}, {$varName['offset']}, {${expr}}) I'm not sure how one is "more consistent" than the other. > - The historial parameter handling that works both ways for > `implode()`, should be unified to match that of `explode()` I'd advise against messing with such widely used function as `implode()`... -- Stas Malyshev smalyshev@gmail.com --- ## #102477 — Zeev Suraski — 2018-06-27T05:43:59+00:00 URL: https://externals.io/message/102394#102477 · In reply to: #102474 Sorry for top posting, but should we be discussing these at this point? If these are targeting 7.4, I think we probably want to focus on the ones slated to 7.3 at this point. Perhaps we can add some further blurb (maybe in a box) that despite the RFC acronym, at this point this is just a list of items to discuss at a future time..? Zeev > -----Original Message----- > From: Stanislav Malyshev [mailto:smalyshev@gmail.com] > Sent: Wednesday, June 27, 2018 3:39 AM > To: Kalle Sommer Nielsen ; Nikita Popov > > Cc: Internals > Subject: Re: [PHP-DEV] [RFC] Deprecations for PHP 7.3 > > Hi! > > > […] > > Weighting bc preak potential vs. improvement benefit, I am not sure it's worth it > for both. Maybe for "real" it's ok as I haven't really seen anybody using it in > ages, looks like most Fortran programmers either retired or aren't using PHP :) > > > […] > > Makes sense. > > > […] > > Yeah this one we probably just have to remove, it doesn't do anything now. > > > […] > > Why? > > > […] > > Probably less useful now that browsers finally can render bidi texts properly, but > may be still useable for workloads where bidi rendering is not available. And I > see no problem with function doing something that is achievable by other > functions. > > > […] > > Maybe just make it a pseudo-alias for iconv? > > > […] > > I'm not sure how one is "more consistent" than the other. > > > […] > > I'd advise against messing with such widely used function as `implode()`... > > -- > Stas Malyshev > smalyshev@gmail.com > > -- > To unsubscribe, visit: > http://www.php.net/unsub.php --- ## #102572 — Nikita Popov — 2018-07-04T14:07:18+00:00 URL: https://externals.io/message/102394#102572 · In reply to: #102400 On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker wrote: > > > > […] > to > > […] > will > > […] > > Thanks. FWIW, I'm +1 on all 4 proposals. > > > […] > RFC > > […] > included > > […] > > I've recently submitted to > deprecate FILTER_FLAG_SCHEME_REQUIRED and FILTER_FLAG_HOST_REQUIRED. I > don't think this needs an RFC, but it might be something which could be > added to this RFC? > Procedural question: Would you prefer that the vote for this (and the other two deprecation RFCs) is one week (the minimum voting period), or that the vote is two weeks but the deprecations land for beta 2 rather than beta 1? Nikita --- ## #102577 — Christoph M. Becker — 2018-07-04T15:23:24+00:00 URL: https://externals.io/message/102394#102577 · In reply to: #102572 > On Sun, Jun 24, 2018 at 10:29 PM, Christoph M. Becker > wrote: > > > […] > > Procedural question: Would you prefer that the vote for this (and the other > two deprecation RFCs) is one week (the minimum voting period), or that the > vote is two weeks but the deprecations land for beta 2 rather than beta 1? Hmm, it's probably best to ship the deprecations (if any) with beta1. If the voting could be opened soon, there's still more than 1 week time. -- Christoph M. Becker --- ## #102583 — Stanislav Malyshev — 2018-07-04T17:32:57+00:00 URL: https://externals.io/message/102394#102583 · In reply to: #102577 Hi! > > […] > > Hmm, it's probably best to ship the deprecations (if any) with beta1. > If the voting could be opened soon, there's still more than 1 week time. Right. That said, since deprecations are not exactly new features, I *think* if it's impossible to do it for beta1 it'll still be ok for beta2. But we have almost 2 weeks till beta1, so if we start vote soon, I think beta1 may still be possible... -- Stas Malyshev smalyshev@gmail.com --- ## #102591 — Nikita Popov — 2018-07-04T22:09:47+00:00 URL: https://externals.io/message/102394#102591 · In reply to: #102583 On Wed, Jul 4, 2018 at 7:32 PM, Stanislav Malyshev wrote: > Hi! > > > […] > other > > […] > the > > […] > 1? > > […] > > Right. That said, since deprecations are not exactly new features, I > *think* if it's impossible to do it for beta1 it'll still be ok for > beta2. But we have almost 2 weeks till beta1, so if we start vote soon, > I think beta1 may still be possible... > I'd be fine with opening voting tomorrow. I was mainly concerned about the two week minimum discussion period here, but as the active discussion seems to have died down, I agree that it may be better to have a longer vote rather than a longer discussion window. Nikita --- ## #102612 — Nikita Popov — 2018-07-05T18:13:26+00:00 URL: https://externals.io/message/102394#102612 · In reply to: #102439 > On Sun, Jun 24, 2018 at 11:47 AM, Nikita Popov > wrote: > > […] > Yeah, if they're just dumb aliases, then it's a slight gain to narrow > the symbol table by removing duplicates. A modest composer package > (nay, include file) would be sufficient to provide a bridge for > existing projects which use the removed aliases once they're gone. > This deprecation isn't *needed*, but it's also fairly low impact. 🤷 > > > […] > Agree with stas, the wtf quotient on this one is high. Mitigating > this is the availability of strict types, but even still I think > deprecating the behavior altogether is a wise move. Callers can > easily insert a call to `chr()` (or IntlChar::chr() ) to maintain the > old behavior in a version agnostic way. 😕 > > > […] > "...these functions seem to be of very little utility..." [citation needed] > Anecdotally I struggle to imagine the use-case, but my imagination > isn't what it once was. There's not a trivial workaround for someone > who's dealing with a large/streaming data source from which they want > to strip tags. Deprecating this should come at a higher standard of: > proving that it is used, providing a userspace replacement, or both. > 😤 > As an insight into how much this functionality is used from a somewhat unexpected direction: While implementing the deprecation, I found out that the string.strip_tags filter does not have a single test and has been segfaulting on construction since PHP 7.0 if no allowed tags are specified (and performed OOB reads if they were specified). These issues have been fixed in https://github.com/php/php-src/commit/791f07e4f06a943bd7892bdc539a7313fb3d6d1e . Nikita --- ## #102614 — Nikita Popov — 2018-07-05T20:14:54+00:00 URL: https://externals.io/message/102394#102614 · In reply to: #102468 On Tue, Jun 26, 2018 at 10:22 PM, Kalle Sommer Nielsen wrote: > Den søn. 24. jun. 2018 kl. 18.47 skrev Nikita Popov > […] > RFC > > […] > included > > […] > > I took the liberty and added the FILTER_SANITIZE_MAGIC_QUOTES to the > RFC so we may once and for all get rid of magic_quotes. > After looking into this, I think that FILTER_SANITIZE_MAGIC_QUOTES may be a legitimate filter, which just has a bad name. Next to other filters that perform htmlspecialchars and urlencode, it makes sense that there is also a filter that performs addslashes. Maybe we should just rename this filter to something which is not tainted by the "magic quotes" terminology? Nikita --- Next page: https://externals.io/message/102394.md?page=2