> Le 7 juil. 2026 à 13:54, Gina P. Banyard <[email protected]> a écrit : > > On Monday, 22 June 2026 at 14:13, Gina P. Banyard <[email protected] > <mailto:[email protected]>> 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
