Re: [RFC] Deprecations for PHP 8.6
| From: | Seifeddine Gmati | 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.