Hi! > Nikita and I would like to open the discussion for the RFC: > "Deprecations for 7.4", this RFC targets a larger set of various > features targeting for deprecation in 7.4 with the intention of > removal in PHP 8.0.
My first question for many of those is - why? I.e. it deprecates a bunch of niche functions. Most people do not use these functions, so they probably don't care. Those they do use them would find their code broken or produce new warnings and needs to be changed. I have hard time identifying whose life would be made better by these changes. Now, if some of these functions are hopelessly broken or have no valid use cases - like magic quotes - then phasing them out makes sense, and the audience whose life can be made better are people who use those unaware of them being broken, or plan to use them and would thus have broken code unless we warn them (or remove the functions, eventually). But for functions that work just fine, I see absolutely no reason to introduce friction without any apparent upside. For the specifics, I think things like removing allow_url_include requires separate RFC. It's a serious functionality change, and bundling it with 20 or so other changes would not allow to properly consider it. In general mass-change RFCs usually are not very conductive to properly discussing each specific change, but mixing changes of different types makes it even worse. Same probably holds for "Unbinding $this from non-static closures" but for different reasons - this looks like a consistency change which is necessary to bring Closure in compliance with the rest of the engine. If non-$this call is not supported in PHP 8, then bindTo(null) should produce an error, not sure it even needs an RFC for that. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
