On Mon, Jun 22, 2026, 2:16 PM Gina P. Banyard <[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. > > > 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. >
