Re: [RFC] Deprecations for PHP 8.6

From: Date: Tue, 23 Jun 2026 11:44:46 +0000
Subject: Re: [RFC] Deprecations for PHP 8.6
References: 1 2 3  Groups: php.internals 
Request: Send a blank email to internals+get-131501@lists.php.net to get a copy of this message
On Tue, 23 Jun 2026 at 11:50, Gina P. Banyard <internals@gpb.moe> wrote: > > On Monday, 22 June 2026 at 23:24, Seifeddine Gmati <azjezz@carthage.software> wrote: > > 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 ). > > > If we provide a new set of by-reference parameters I think we would want to have the > possibility to do: > > inout for mutable references > in for immutable references > out for out parameters (such as the $matches parameter of preg_match()) where the input value > is explicitly discarded > > > Thus, I would prefer to reserve them in bulk and if it turns out we don't use them we can > always remove the restriction. > > Best regards, > > Gina P. Banyard > The idea is interesting, i would say it's fine to mark them as reserved then. I assumed the only reason for reserving them was generics. Cheers, Seifeddine.

« previous php.internals (#131501) next »