Hi Dan (and Larry and Tim who responded to the same topic), Would leaving the current versions in place and working actually cause > any maintenance issues?
Yes, unfortunately they cause some maintenance issues: since they don't have a single signature, gen_stub.php generates the wrong signature for them in the manual. For example https://www.php.net/manual/en/function.stream-context-set-option.php displays two distinct signatures, however gen_stub.php only knows one signature, so obviously generation won't work well: function stream_context_set_option($context, array|string $wrapper_or_options, ?string $option_name = null, mixed $value = UNKNOWN): bool {} I use gen_stub.php for automatically detecting the outdated function/method/class signatures which I can then commit with minimal effort. Actually my doc-en PRs ( https://github.com/php/doc-en/pulls?page=1&q=is%3Apr+is%3Aclosed+author%3Akocsismate ) are either fixing outdated information in the manual, or ensuring that gen_stub.php can generate the same information that we display in the docs. Now, there are only ~50-60 function/method signatures in master which are not in line with the output of gen_stub.php, and most of them are due to overloaded signatures (the rest is due to PHP 8.3 changes which shouldn't be documented yet). For reference, the number of outdated function signatures used to be many hundreds or probably 1000+ when the project started, just before PHP 8.0 came out. If not, then we could just move really slowly on deprecating them. We > could deprecate them at some point in the 9.x release cycle and remove > them in 10.0. Although I would love to get rid of as many overloaded signatures as possible due to the above mentioned fact, I admit that there might be some signatures which other internals would prefer to phase out slower than me. So thanks for the idea! Now, the individual votes in the RFC contain 2 options for removing a signature: a shorter path (deprecation in PHP 8.4, removal in PHP 9.0) and a longer one (deprecation in PHP 9.0 and removal in PHP 10.0). Additionally, I wrote a very explicit and detailed list about the suggested BC compatible alternatives for each deprecation so that now it should be very clear how difficult it is to replace a function/method invocation. The RFC says: Impact analysis: 1 out of the 2000 most popular PHP packages rely on > calling session_set_save_handler() with 6 or more arguments. > I doubt analysing github is going to give a useful measure of the > impact of this RFC. Functions like session_set_save_handler are going > to be used in custom code written for a company than in shared > libraries. Yes, I'm aware of this glitch, but that's the best I could provide for estimating the impact of the deprecations. Cheers, Máté
