Re: [RFC] Deprecations for PHP 8.6

> Le 7 juil. 2026 à 13:54, Gina P. Banyard <internals@gpb.moe> a écrit : > > On Monday, 22 June 2026 at 14:13, Gina P. Banyard <internals@gpb.moe > <mailto:internals@gpb.moe>> wrote: > >> Hello internals, >> >> It is this time of year again where we proposed a list of deprecations to add in PHP 8.6: >> >> https://wiki.php.net/rfc/deprecations_php_8_6 >> >> As a reminder, this list has been compiled over the course of the past year by different >> people. >> >> And as usual, each deprecation will be voted in isolation. >> >> We still have a bit of time anyone else to propose additional deprecations, and if you have >> write access feel free to add them directly to the RFC. >> Please note that with the new RFC policy rules the RFC must be finalized and in a >> "frozen" state by the 13th of July at the latest. >> >> Some deprecations should be non-controversial, others a bit more. >> If a deprecation is really controversial, it might warrant its own dedicated RFC or be >> dropped altogether. > > Reminder that there is less than a single week for adding deprecations before the RFC needs to > be in a frozen state. > A few people have added new ones and some were sent directly to me which I just added. > I also reordered some of the deprecations to group them together in somewhat more logical > places. > > https://wiki.php.net/rfc/deprecations_php_8_6 > > If anyone has any issues or additional proposals they can still be added or amended. > If none are added or amended, I will initiate a call to vote next week. > > Best regards, > > Gina P. Banyard Hi, Here are my remarks on some of a deprecation proposals: ## Returning from a finally block. I feel that the text doesn’t tell the real issue with the feature to be deprecated. As everyone knows, an exception is thrown with a throw statement, is caught with a catch block, and is propagated until it is caught or it crashes at the top of the call stack. However, the description above is incorrect, because of the wacky semantics that the designers of the feature gave to return in finally block. *This* is the problem: having a role that it supposed to be reserved to another construct. The role of the finally block is to run code unconditionally, not to stop propagation. ## Passing objects for $data parameter of http_build_query() As I understand, what is proposed to be deprecated, is not only passing an object to http_build_query (such as http_build_query((object)['a' => 'b'])), but also passing an array who has an object as value (possibly at some deep level) (such as http_build_query(['x' => (object) ['y' => 'z']])). The deprecation message isn’t clear about that situation, because in the second case, an array is passed for argument #1 to http_build_query(). ## Deprecate is_a with string when $allow_string is false It is true that passing specifically a string as first argument of is_a() when $allow_string is set to false, does not make sense. However the first parameter of is_a() is of type mixed, and it makes plenty of sense to pass a value of type mixed (i.e. of unknown type) as first argument of is_a() when $allow_string is set to false: it tests whether the value is an object and an instance of a given class. If we want to deprecate passing a string as first parameter (if $allow_string is true) in order to avoid confusion, I think we should deprecate everything that is not an object: because is_a(true, 'bool') does not test whether true is a bool. But I don’t know whether such a deprecation is reasonable. ## Deprecate is_substring_of with string when $allow_string is false Same remark as for is_a. I don’t think it makes sense to cherry-pick string when mixed is allowed. —Claude