Re: [RFC] Deprecations for PHP 8.6

On Mon, Jun 22, 2026, 2:16 PM Gina P. Banyard <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. > > > Best regards, > > Gina P. Banyard > Hi Gina, Thank you the RFC. Overall, everything looks good, however, i object (although not voting) to deprecating in and out, because their position in generics type parameter does not require them to be reserved keyword, and there's no parser ambiguity. inout on the other hand does make sense to deprecate for potential future inout parameters because there's an ambiguity with untyped parameters ( in inout $x, is it the type or modifier ). Cheers, Seifeddine. >