O que há de novo no PHP 8.2 — Novos recursos, descontinuações, alterações e muito mais

O PHP 8.2 se baseia na base renovada estabelecida pelo PHP 8.0 e PHP 8.1. Está planejado para ser lançado em 24 de novembro de 2022.

Este artigo abordará o que há de novo no PHP 8.2 em detalhes — desde seus novos recursos e melhorias até descontinuações e pequenas alterações, passaremos por todos eles.

Como o PHP 8.2 entrou em seu congelamento de recursos em 19 de julho de 2022, você não pode esperar adições significativas a esta lista.

Animado? Nós também.

Vamos começar!

Novos recursos e melhorias no PHP 8.2

Vamos começar explorando todos os recursos mais recentes do PHP 8.2. É uma lista bem extensa:

Novas classes readonly

O PHP 8.1 introduziu o recurso readonly para propriedades de classe. Agora, o PHP 8.2 está adicionando suporte para declarar a classe inteira como readonly .

Se você declarar uma classe como readonly , todas as suas propriedades herdarão automaticamente o recurso readonly . Assim, declarar uma classe readonly é o mesmo que declarar cada propriedade de classe como readonly .

Por exemplo, com o PHP 8.1, você tinha que escrever este código tedioso para declarar todas as propriedades de classe como readonly :

 class MyClass { public readonly string $myValue, public readonly int $myOtherValue public readonly string $myAnotherValue public readonly int $myYetAnotherValue }

Imagine o mesmo com muito mais propriedades. Agora, com o PHP 8.2, você pode simplesmente escrever isso:

 readonly class MyClass { public string $myValue, public int $myOtherValue public string $myAnotherValue public int $myYetAnotherValue }

Você também pode declarar classes abstratas ou finais como readonly . Aqui, a ordem das palavras-chave não importa.

 abstract readonly class Free {} final readonly class Dom {}

Você também pode declarar uma classe readonly sem propriedades. Efetivamente, isso evita propriedades dinâmicas enquanto ainda permite que classes filhas declarem explicitamente suas propriedades readonly .

Em seguida, as classes readonly podem conter apenas propriedades tipadas — a mesma regra para declarar propriedades readonly individuais.

Você pode usar a propriedade de tipo mixed se não puder declarar uma propriedade estritamente tipada.

Tentar declarar uma classe readonly sem uma propriedade tipada resultará em um erro Fatal:

 readonly class Type { public $nope; } Fatal error: Readonly property Type::$nope must have type in ... on line ...

Além disso, você não pode declarar readonly para certos recursos do PHP:

• Enums (já que não podem conter nenhuma propriedade)
• Características
• Interfaces

A tentativa de declarar qualquer um desses recursos como readonly resultará em um erro de análise.

 readonly interface Destiny {} Parse error: syntax error, unexpected token "interface", expecting "abstract" or "final" or "readonly" or "class" in ... on line ...

Como é o caso de todas as palavras-chave do PHP, a palavra-chave readonly não diferencia maiúsculas de minúsculas.

O PHP 8.2 também desaprova as propriedades dinâmicas (mais sobre isso depois). Mas você não pode impedir que propriedades dinâmicas sejam adicionadas a uma classe. No entanto, fazer isso para uma classe readonly resultará apenas em um erro fatal.

 Fatal error: Readonly property Test::$test must have type in ... on line ...

Permitir true , false e null como tipos autônomos

O PHP já inclui tipos escalares como int , string e bool . Isso foi expandido no PHP 8.0 com a adição de tipos de união, permitindo que os valores fossem de tipos diferentes. O mesmo RFC também permitia o uso de false e null como parte de um tipo de união — no entanto, eles não eram permitidos como tipos autônomos.

Se você tentou declarar false ou null ou como tipos autônomos — sem que eles fizessem parte de um tipo de união — isso resultaria em um erro fatal.

 function spam(): null {} function eggs(): false {} Fatal error: Null can not be used as a standalone type in ... on line ... Fatal error: False can not be used as a standalone type in ... on line ...

Para evitar esse cenário, o PHP 8.2 está adicionando suporte para usar false e null como tipos autônomos. Com esta adição, o sistema de tipos do PHP é mais expressivo e completo. Agora você pode declarar os tipos de retorno, parâmetro e propriedade com precisão.

Além disso, o PHP ainda não inclui um tipo true , que parece ser uma contrapartida natural do tipo false . O PHP 8.2 corrige isso e adiciona suporte para o tipo true também. Não permite coerção, exatamente como o tipo false se comporta.

Ambos os tipos true e false são essencialmente um tipo de união do tipo bool do PHP. Para evitar redundância, você não pode declarar esses três tipos juntos em um tipo de união. Isso resultará em um erro fatal em tempo de compilação.

Tipos de Forma Normal Disjuntiva (DNF)

A Forma Normal Disjuntiva (DNF) é uma forma padronizada de organizar expressões booleanas. Consiste em uma disjunção de conjunções — em termos booleanos, é um OR de ANDs .

A aplicação de DNF a declarações de tipo permite uma maneira padrão de escrever tipos combinados de União e Interseção que o analisador pode manipular. O novo recurso de tipos DNF do PHP 8.2 é simples, mas poderoso se usado corretamente.

A RFC dá o exemplo a seguir. Ele assume que as seguintes definições de interface e classe já existem:

 interface A {} interface B {} interface C extends A {} interface D {} class W implements A {} class X implements B {} class Y implements A, B {} class Z extends Y implements C {}

Com os tipos DNF, você pode realizar declarações de tipo para propriedades, parâmetros e valores de retorno da seguinte forma:

 // Accepts an object that implements both A and B, // OR an object that implements D (A&B)|D // Accepts an object that implements C, // OR a child of X that also implements D, // OR null C|(X&D)|null // Accepts an object that implements all three of A, B, and D, // OR an int, // OR null. (A&B&D)|int|null

Em alguns casos, as propriedades podem não estar nas formas DNF. Declará-los como tal resultará em um erro de análise. Mas você sempre pode reescrevê-los como:

 A&(B|D) // Can be rewritten as (A&B)|(A&D) A|(B&(D|W)|null) // Can be rewritten as A|(B&D)|(B&W)|null

Você deve observar que cada segmento de um tipo DNF deve ser exclusivo. Por exemplo, declarar (A&B)|(B&A) é inválido, pois os dois segmentos OR ed são logicamente iguais.

Além disso, segmentos que são subconjuntos estritos do outro segmento também não são permitidos. Isso porque o superconjunto já terá todas as instâncias do subconjunto, tornando redundante o uso de DNF.

Redigir Parâmetros Sensíveis em Traços Anteriores

Como quase qualquer linguagem de programação, o PHP permite rastrear sua pilha de chamadas em qualquer ponto da execução do código. O rastreamento de pilha facilita a depuração do código para corrigir erros e gargalos de desempenho. Ele forma a espinha dorsal de ferramentas como Kinsta APM, nossa ferramenta de monitoramento de desempenho personalizada para sites WordPress.

A execução de um rastreamento de pilha não interrompe a execução do programa. Normalmente, a maioria dos rastreamentos de pilha são executados em segundo plano e registrados silenciosamente — para inspeção posterior, se necessário.

No entanto, alguns desses rastreamentos de pilha PHP detalhados podem ser uma desvantagem se você os compartilhar com serviços de terceiros - geralmente para análise de log de erros, rastreamento de erros, etc. Esses rastreamentos de pilha podem incluir informações confidenciais, como nomes de usuário, senhas e variáveis ​​de ambiente .

Esta proposta RFC dá um exemplo:

Um “infrator” comum é o PDO que usa a senha do banco de dados como um parâmetro do construtor e imediatamente tenta se conectar ao banco de dados dentro do construtor, em vez de ter um construtor puro e um método ->connect() separado . Assim, quando a conexão com o banco de dados falhar, o rastreamento de pilha incluirá a senha do banco de dados:

 PDOException: SQLSTATE[HY000] [2002] No such file or directory in /var/www/html/test.php:3 Stack trace: #0 /var/www/html/test.php(3): PDO->__construct('mysql:host=loca...', 'root', 'password') #1 {main}

O PHP 8.2 permite que você marque tais parâmetros sensíveis com um novo atributo \SensitiveParameter . Qualquer parâmetro marcado como sensível não será listado em seus backtraces. Assim, você pode compartilhá-los sem preocupações com serviços de terceiros.

Aqui está um exemplo direto com um único parâmetro sensível:

 <?php function example( $ham, #[\SensitiveParameter] $eggs, $butter ) { throw new \Exception('Error'); } example('ham', 'eggs', 'butter'); /* Fatal error: Uncaught Exception: Error in test.php:8 Stack trace: #0 test.php(11): test('ham', Object(SensitiveParameterValue), 'butter') #1 {main} thrown in test.php on line 8 */

Ao gerar um backtrace, qualquer parâmetro com o atributo \SensitiveParameter será substituído por um objeto \SensitiveParameterValue e seu valor real nunca será armazenado no rastreamento. O objeto SensitiveParameterValue encapsula o valor real do parâmetro — se você precisar dele por qualquer motivo.

Nova função mysqli_execute_query e método mysqli::execute_query

Você já usou a função mysqli_query() com valores de usuário perigosamente escapando apenas para executar uma consulta MySQLi parametrizada?

O PHP 8.2 facilita a execução de consultas MySQLi parametrizadas com a nova mysqli_execute_query($sql, $params) e o método mysqli::execute_query .

Essencialmente, esta nova função é uma combinação das mysqli_prepare() , mysqli_execute() e mysqli_stmt_get_result() . Com ele, a consulta MySQLi será preparada, vinculada (se passar algum parâmetro) e executada dentro da própria função. Se a consulta for executada com sucesso, ela retornará um objeto mysqli_result . Se não tiver sucesso, ele retornará false .

A proposta RFC dá um exemplo simples, mas poderoso:

 foreach ($db->execute_query('SELECT * FROM user WHERE name LIKE ? AND type_id IN (?, ?)', [$name, $type1, $type2]) as $row) { print_r($row); }

Buscar propriedades enum em expressões const

Este RFC propõe permitir que o operador ->/?-> busque propriedades enum em expressões const .

A principal razão para esse novo recurso é que você não pode usar objetos enum em alguns lugares, como chaves de matriz. Nesse caso, você terá que repetir o valor do caso enum apenas para usá-lo.

Permitir a busca de propriedades enum em locais onde objetos enum não são permitidos pode simplificar este procedimento.

Isso significa que o seguinte código agora é válido:

 const C = [self::B->value => self::B];

E só por segurança, este RFC também inclui suporte para o operador nullsafe ?-> .

Permitir constantes em características

O PHP inclui uma maneira de reutilizar o código chamado Traits. Eles são ótimos para reutilização de código entre classes.

Atualmente, Traits só permite definir métodos e propriedades, mas não constantes. Isso significa que você não pode definir invariantes esperados por um Trait dentro do próprio Trait. Para contornar essa limitação, você precisa definir constantes em sua classe de composição ou uma interface implementada por sua classe de composição.

Esta RFC se propõe a permitir definir constantes em Traits. Essas constantes podem ser definidas da mesma forma que você definiria constantes de classe. Este exemplo tirado diretamente do RFC esclarece o seu uso:

 trait Foo { public const FLAG_1 = 1; protected const FLAG_2 = 2; private const FLAG_3 = 2; public function doFoo(int $flags): void { if ($flags & self::FLAG_1) { echo 'Got flag 1'; } if ($flags & self::FLAG_2) { echo 'Got flag 2'; } if ($flags & self::FLAG_3) { echo 'Got flag 3'; } } }

As constantes de traço também são mescladas na definição da classe de composição, da mesma forma que as definições de propriedade e método de um traço. Eles também têm restrições semelhantes às propriedades de Características. Conforme observado na RFC, esta proposta - embora seja um bom começo - precisa de mais trabalho para aprimorar o recurso.

Depreciações no PHP 8.2

Agora podemos avançar para explorar todas as reprovações no PHP 8.2. Esta lista não é tão grande quanto seus novos recursos:

Descontinuar propriedades dinâmicas (e novo atributo #[AllowDynamicProperties] )

Até o PHP 8.1, você podia definir e recuperar dinamicamente propriedades de classe não declaradas em PHP. Por exemplo:

 class Post { private int $pid; } $post = new Post(); $post->name = 'Kinsta';

Aqui, a classe Post não declara uma propriedade de name . Mas como o PHP permite propriedades dinâmicas, você pode configurá-lo fora da declaração de classe. Essa é sua maior – e possivelmente, a única – vantagem.

Propriedades dinâmicas permitem que bugs e comportamentos inesperados surjam em seu código. Por exemplo, se você cometer algum erro ao declarar uma propriedade de classe fora da classe, é fácil perdê-la — especialmente ao depurar erros dentro dessa classe.

Do PHP 8.2 em diante, as propriedades dinâmicas são obsoletas. Definir um valor para uma propriedade de classe não declarada emitirá um aviso de descontinuação na primeira vez que a propriedade for definida.

 class Foo {} $foo = new Foo; // Deprecated: Creation of dynamic property Foo::$bar is deprecated $foo->bar = 1; // No deprecation warning: Dynamic property already exists. $foo->bar = 2;

No entanto, a partir do PHP 9.0, definir o mesmo lançará um erro ErrorException .

Se o seu código estiver cheio de propriedades dinâmicas — e houver muito código PHP que esteja — e se você quiser interromper esses avisos de descontinuação após atualizar para o PHP 8.2, você pode usar o novo atributo #[AllowDynamicProperties] do PHP 8.2 para permitir propriedades nas aulas.

 #[AllowDynamicProperties] class Pets {} class Cats extends Pets {} // You'll get no deprecation warning $obj = new Pets; $obj->test = 1; // You'll get no deprecation warning for child classes $obj = new Cats; $obj->test = 1;

De acordo com a RFC, as classes marcadas como #[AllowDynamicProperties] , bem como suas classes filhas, podem continuar usando propriedades dinâmicas sem depreciação ou remoção.

Você também deve observar que, no PHP 8.2, a única classe empacotada marcada como #[AllowDynamicProperties] é stdClass . Além disso, quaisquer propriedades acessadas através dos métodos mágicos __get() ou __set() PHP não são consideradas propriedades dinâmicas, então elas não irão lançar um aviso de depreciação.

Descontinuar callables parcialmente suportados

Outra mudança do PHP 8.2, embora com um impacto mais insignificante, é descontinuar callables parcialmente suportados.

Esses callables são denominados parcialmente suportados porque você não pode interagir com eles diretamente via $callable() . Você só pode acessá-los com a função call_user_func($callable) . A lista de tais callables não é longa:

 "self::method" "parent::method" "static::method" ["self", "method"] ["parent", "method"] ["static", "method"] ["Foo", "Bar::method"] [new Foo, "Bar::method"]

Do PHP 8.2 em diante, qualquer tentativa de invocar tais callables — como por meio das funções call_user_func() ou array_map() — lançará um aviso de depreciação.

O RFC original fornece um raciocínio sólido por trás dessa depreciação:

Além dos dois últimos casos, todos esses callables são dependentes do contexto. O método ao qual "self::method" se refere depende de qual classe a chamada ou verificação de chamada é executada. Na prática, isso geralmente também vale para os dois últimos casos, quando usado na forma de [new Foo, "parent::method"] .

Reduzir a dependência de contexto de callables é o objetivo secundário deste RFC. Após esta RFC, a única dependência de escopo que resta é a visibilidade do método: "Foo::bar" pode ser visível em um escopo, mas não em outro. Se callables fossem limitados a métodos públicos no futuro (enquanto métodos privados teriam que usar callables de primeira classe ou Closure::fromCallable() para serem independentes de escopo), então o tipo callable se tornaria bem definido e poderia ser usado como um tipo de propriedade. No entanto, alterações no tratamento de visibilidade não são propostas como parte desta RFC .

De acordo com o RFC original, a função is_callable() e o tipo callable continuarão a aceitar esses callables como exceções. Mas somente até que o suporte para eles seja totalmente removido do PHP 9.0 em diante.

Para evitar confusão, este escopo de aviso de descontinuação foi expandido com um novo RFC — agora inclui essas exceções.

É bom ver o PHP caminhando para ter um tipo de callable bem definido.

Descontinuar as #utf8_encode() e utf8_decode()

As funções incorporadas do PHP utf8_encode() e utf8_decode() convertem strings codificadas em ISO-8859-1 (“Latin 1”) para e de UTF-8.

No entanto, seus nomes sugerem um uso mais geral do que sua implementação permite. A codificação “Latin 1” é comumente confundida com outras codificações como a “Windows Code Page 1252”.

Além disso, você geralmente verá o Mojibake quando essas funções não puderem converter nenhuma string corretamente. A falta de mensagens de erro também significa que é difícil identificá-las, especialmente em um mar de texto legível.

O PHP 8.2 descontinua as funções #utf8_encode() e utf8_decode() . Se você invocá-los, verá estes avisos de suspensão de uso:

 Deprecated: Function utf8_encode() is deprecated Deprecated: Function utf8_decode() is deprecated

A RFC sugere o uso de extensões suportadas pelo PHP, como mbstring , iconv e intl .

Descontinuar ${} String Interpolation

O PHP permite incorporar variáveis ​​em strings com aspas duplas ( " ) e heredoc ( <<< ) de várias maneiras:

1. Incorporando diretamente variáveis ​​— “$foo”
2. Com chaves fora da variável — “{$foo}”
3. Com chaves após o cifrão — “${foo}”
4. Variáveis ​​variáveis ​​— “${expr}” — equivalente a usar (string) ${expr}

As duas primeiras maneiras têm seus prós e contras, enquanto as duas últimas têm sintaxe complexa e conflitante. O PHP 8.2 desaprova as duas últimas formas de interpolação de strings.

Você deve evitar a interpolação de strings desta maneira daqui para frente:

 "Hello, ${world}!"; Deprecated: Using ${} in strings is deprecated "Hello, ${(world)}!"; Deprecated: Using ${} (variable variables) in strings is deprecated

A partir do PHP 9.0, essas reprovações serão atualizadas para gerar um erro de exceção.

Descontinuar funções mbstring para entidades Base64/QPrint/Uuencode/HTML

As funções mbstring (string de vários bytes) do PHP nos ajudam a trabalhar com Unicode, entidades HTML e outras codificações de texto legadas.

No entanto, Base64, Uuencode e QPrint não são codificações de texto e ainda fazem parte dessas funções - principalmente devido a motivos herdados. O PHP também inclui implementações separadas dessas codificações.

Quanto às entidades HTML, o PHP tem funções embutidas — htmlspecialchars() e htmlentities() — para lidar melhor com elas. Por exemplo, ao contrário de mbstring, essas funções também converterão < . > e & caracteres para entidades HTML.

Além disso, o PHP está sempre aprimorando suas funções internas — assim como o PHP 8.1 com funções de codificação e decodificação HTML.

Então, mantendo tudo isso em mente, o PHP 8.2 está descontinuando o uso de mbstring para essas codificações (os rótulos não diferenciam maiúsculas de minúsculas):

• BASE64
• UUENCODE
• HTML-ENTIDADES
• html (alias de HTML-ENTITIES)
• Citado-Imprimível
• qprint (alias de Quoted-Printable)

A partir do PHP 8.2, usar mbstring para codificar/decodificar qualquer um dos itens acima emitirá um aviso de descontinuação. O PHP 9.0 removerá completamente o suporte mbstring para essas codificações.

Outras pequenas mudanças no PHP 8.2

Finalmente, podemos discutir as pequenas mudanças do PHP 8.2, incluindo seus recursos e funcionalidades removidos.

Remova o suporte para libmysql do mysqli

A partir de agora, o PHP permite que os drivers mysqli e PDO_mysql sejam compilados nas bibliotecas mysqlnd e libmysql . No entanto, o driver padrão e recomendado desde o PHP 5.4 tem sido mysqlnd .

Ambos os drivers têm muitas vantagens e desvantagens. No entanto, remover o suporte para um deles - idealmente, remover libmysql , pois não é o padrão - simplificará o código do PHP e os testes de unidade.

Para argumentar a favor desse favor, a RFC lista muitas vantagens do mysqlnd :

• É empacotado com PHP
• Ele usa gerenciamento de memória PHP para monitorar o uso de memória e
  melhorar o desempenho
• Fornece funções de qualidade de vida (por exemplo get_result() )
• Retorna valores numéricos usando tipos nativos do PHP
• Sua funcionalidade não depende da biblioteca externa
• Funcionalidade de plug-in opcional
• Suporta consultas assíncronas

A RFC também lista algumas vantagens do libmysql , incluindo:

• A reconexão automática é possível (o mysqlnd não suporta essa funcionalidade intencionalmente porque pode ser facilmente explorada)
• Modos de autenticação LDAP e SASL ( mysqlnd pode adicionar esse recurso em breve também)

Além disso, a RFC lista muitas desvantagens do libmysql — incompatibilidade com o modelo de memória PHP, muitos testes com falha, vazamentos de memória, funcionalidades diferentes entre versões, etc.

Mantendo tudo isso em mente, o PHP 8.2 removeu o suporte para construir mysqli contra libmysql .

Se você quiser adicionar qualquer funcionalidade que esteja disponível apenas com libmysql , você terá que adicioná-la explicitamente ao mysqlnd como uma solicitação de recurso. Além disso, você não pode adicionar reconexão automática.

Conversão de caso independente de localidade

Antes do PHP 8.0, a localidade do PHP era herdada do ambiente do sistema. Mas isso pode causar um problema em alguns casos extremos.

Definir seu idioma durante a instalação do Linux definirá o idioma apropriado da interface do usuário para seus comandos integrados. No entanto, também altera inesperadamente como funciona a funcionalidade de manipulação de strings da biblioteca C.

Por exemplo, se você selecionou o idioma “turco” ou “cazaque” ao instalar o Linux, você descobrirá que chamar toupper('i') para obter seu equivalente em maiúsculas obteria o maiúsculo pontilhado I (U+0130, I ).

O PHP 8.0 parou essa anomalia definindo o locale padrão como “C”, a menos que o usuário o altere explicitamente via setlocale() .

O PHP 8.2 vai ainda mais longe ao remover a sensibilidade de localidade das conversões de maiúsculas e minúsculas. Este RFC altera principalmente strtolower() , strtoupper() e funções relacionadas. Leia o RFC para obter uma lista de todas as funções afetadas.

Como alternativa, se você quiser usar a conversão de maiúsculas e minúsculas localizadas, poderá usar mb_strtolower() .

Melhoria de extensão aleatória

O PHP está planejando revisar sua funcionalidade aleatória.

A partir de agora, a funcionalidade aleatória do PHP depende muito do estado Mersenne Twister. No entanto, esse estado é armazenado implicitamente na área global do PHP — não há como um usuário acessá-lo. Adicionar funções de randomização entre o estágio inicial de propagação e o uso pretendido quebraria o código.

Manter esse código pode ser ainda mais complicado quando seu código usa pacotes externos.

Assim, a funcionalidade aleatória atual do PHP não pode reproduzir valores aleatórios de forma consistente. Ele ainda falha em testes estatísticos empíricos de geradores de números aleatórios uniformes, como Crush e BigCrush do TestU01. A limitação de 32 bits do Mersenne Twister agrava ainda mais isso.

Assim, usar as funções internas do PHP — shuffle() , str_shuffle() , array_rand() — não é recomendado se você precisar de números aleatórios criptograficamente seguros. Nesses casos, você precisará implementar uma nova função usando random_int() ou funções semelhantes.

No entanto, várias questões com este RFC foram levantadas após o início da votação. Esse revés forçou a equipe do PHP a anotar todos os problemas em um RFC separado, com uma opção de votação criada para cada problema. Eles decidirão avançar somente depois de chegarem a um consenso.

RFCs adicionais no PHP 8.2

O PHP 8.2 também inclui muitas novas funções e pequenas alterações. Vamos mencioná-los abaixo com links para recursos adicionais:

1. Nova função curl_upkeep : PHP 8.2 adiciona esta nova função à sua extensão Curl. Ele chama a função curl_easy_upkeep() em libcurl, a biblioteca C subjacente que a extensão PHP Curl usa.
2. Nova função ini_parse_quantity : as diretivas PHP INI aceitam tamanhos de dados com um sufixo multiplicador. Por exemplo, você pode escrever 25 Megabytes como 25M , ou 42 Gigabytes como apenas 42G . Esses sufixos são comuns em arquivos PHP INI, mas são incomuns em outros lugares. Esta nova função analisa os valores PHP INI e retorna o tamanho dos dados em bytes.
3. Nova função memory_reset_peak_usage : Esta função redefine o pico de uso de memória retornado pela função memory_get_peak_usage . Pode ser útil quando você está executando a mesma ação várias vezes e deseja registrar o uso máximo de memória de cada execução.
4. Suporte para modificador sem captura ( /n ) em funções preg_* : Em regex, os metacaracteres () indicam um grupo de captura. Isso significa que todas as correspondências para a expressão dentro do colchete são retornadas. O PHP 8.2 adiciona um modificador sem captura ( /n ) para interromper esse comportamento.
5. Faça a família iterator_*() aceitar todos os iteráveis: A partir de agora, a família iterator_*() do PHP só aceita \Traversables (ou seja, não são permitidos arrays simples). É desnecessariamente limitante, e este RFC corrige isso.

Resumo

O PHP 8.2 se baseia nas melhorias maciças do PHP 8.0 e PHP 8.1, o que não é tarefa fácil. Achamos que os recursos mais interessantes do PHP 8.2 são seus novos tipos autônomos, propriedades readonly e inúmeras melhorias de desempenho.

Mal podemos esperar para testar o PHP 8.2 com vários frameworks PHP e CMSs.

Certifique-se de marcar esta postagem no blog para sua referência futura.

Quais recursos do PHP 8.2 são seus favoritos? Quais depreciações são suas menos favoritas? Por favor, compartilhe seus pensamentos com a nossa comunidade nos comentários!