Hi internals, One thing that I feel gets lost when discussion is spread over multiple proposals is the following fact:
Purely syntactical deprecations, such as the recently discussed case of backticks, but also the already accepted deprecations of the "alternative array access syntax" and the (real) cast, can be performed automatically and with perfect reliability. Given a high-quality migration tool, the cost is running "php-migrate.phar dir/" and importantly (and this is the point I want to make) this cost is constant regardless of how many different things get deprecated. For this kind of tooling, it makes no difference whether it only has to replace the alternative array access syntax, or whether it also needs to replace backticks, some obscure variable interpolation syntax, or whatever else we want it to. As long as the deprecation is purely syntactical, this kind of migration tooling is reliable -- this certainly does not apply to all deprecations! For example, the also recently discussed case of undefined variables is not something that can be reliably migrated in an automated way (at least not while producing idiomatic code). Rather than starting a holy war over every single RFC that contains the word "deprecation", I think we should take a look at our migration story and possibly invest some effort into creating a "blessed" tool for this purpose: One that only performs migrations that are completely safe and should be runnable without fear of breaking code. I do realize that there is already quite a bit of existing tooling, things like Rector, various CS fixers and compatibility scanners, but I don't think that we have anything that just works out of the box to do what is safe and no more. If we provide this kind of tooling, I think that the cost/benefit calculation on deprecation changes: If we have any syntactic deprecations at all, then it basically doesn't matter how many different (syntactical) things get deprecated in one release, the migration cost is always going to be the same. (This is of course a slightly simplified view, but close enough.) Nikita
