O que Há de Novo no PHP 8.2 – Novas Funcionalidades, Depreciações, Mudanças e Muito Mais

O PHP 8.2 se baseia nas novas bases do PHP 8.0 e do PHP 8.1. Agora que o PHP 8.2 foi lançado, vamos nos aprofundar no que há de novo no PHP 8.2. Analisaremos tudo, desde novos recursos e melhorias até depreciações e pequenas alterações.

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.

Entusiasmado? Também estamos.

Vamos começar!

Novas funcionalidades e melhorias no PHP 8.2

Vamos começar explorando todas as últimas funcionalidades do PHP 8.2. É uma lista bastante extensa:

Novas clases 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.

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

Por exemplo, com o PHP 8.1, você teve que escrever este código tedioso para declarar todas as propriedades da 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 isto:

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

Você também pode declarar clases 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, isto evita propriedades dinâmicas, enquanto ainda permite que as classes crianças declarem suas propriedades readonly explicitamente.

A seguir, readonly classes só podem conter propriedades digitadas – a mesma regra para declarar propriedades individuais somente leitura.

Você pode usar a propriedade do tipo mixed se você não puder declarar uma propriedade estritamente digitada.

Tentar declarar uma classe readonly sem uma propriedade digitada 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 certas características do PHP:

• Enums (como eles não podem conter nenhuma propriedade)
• Traits
• Interfaces

Tentar declarar qualquer uma dessas funcionalidades como readonly resultará em um erro Parse.

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

Como no caso de todas as palavras-chave PHP, a palavra-chave readonly é insensível a maiúsculas e minúsculas.

O PHP 8.2 também deprecia 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 só resultará em um Erro Fatal.

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

Permitindo true, false, e null como tipos autônomos

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 diferentes tipos. O mesmo RFC também permitiu usar false e null como parte de um tipo de sindicato – eles não foram permitidos como tipos autônomos, no entanto.

Caso você tentou declarar false ou null ou como tipos autônomos – sem que eles fizessem parte de um tipo de sindicato – isso resultou 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 este 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 de PHP é mais expressivo e completo. Agora você pode declarar os tipos de retorno, parâmetros e propriedades com precisão.

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

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 estes três tipos juntos em um tipo de sindicato. Fazendo isso, resultará em um erro fatal em tempo de compilação.

Tipo Disjunctive Normal Form (DNF)

O Disjunctive Normal Form (DNF) é uma forma padronizada de organizar expressões booleanas. Ela consiste em uma disjunção de conjunções – em termos booleanos, que é um OR de AND.

O aplicativo do DNF às declarações de tipo permite uma maneira padrão de escrever tipos combinados de União e Intersecção que o analisador pode lidar. O novo recurso de tipos de DNF do PHP 8.2 é simples, mas poderoso se usado corretamente.

O RFC dá o seguinte exemplo. Ela 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 tipos DNF, você pode realizar declarações de tipo para propriedades, parâmetros e valores de retornos assim:

// 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á-las como tal resultará em um erro parse. 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 único. Por exemplo, declarar (A&B)|(B&A) é inválido, pois os dois segmentos OR são logicamente os mesmos.

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

Reduzindo parâmetros sensíveis em Back-Trace

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 da pilha facilita a depuração do código para corrigir erros e gargalos de desempenho. Ele forma a espinha dorsal de ferramentas como o Kinsta APM, nossa ferramenta de monitoramento de desempenho customizada para sites WordPress.

A execução de um stack trace não impede a execução do programa. Normalmente, a maioria dos stack traces são executados em segundo plano, sendo registrados silenciosamente – para inspeção posterior, se necessário.

Entretanto, alguns desses stack traces detalhados do PHP podem ser um inconveniente se você os compartilhar com serviços de terceiros – geralmente para análise de registros de erros, rastreamento de erros, etc. Stack traces podem incluir informações sensíveis, como nomes de usuário, senhas e variáveis de ambiente.

Esta proposta da RFC dá um exemplo:

Um “infrator” comum é o PDO que toma a senha do banco de dados como parâmetro do construtor e imediatamente tenta se conectar ao banco de dados dentro do construtor, ao invés de ter um construtor puro e um método separado ->connect(). Assim, quando a conexão com o banco de dados falhar, o rastreamento da 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 esses parâmetros sensíveis com um novo atributo \SensitiveParameter. Qualquer parâmetro marcado como sensível não será listado no seu backtraces. Assim, você pode compartilhá-los sem preocupações com qualquer serviço de terceiros.

Aqui está um exemplo simples 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
*/

Quando você gera um backtrace, qualquer parâmetro com o atributo \SensitiveParameter será substituído por um objeto \SensitiveParameterValue, e seu valor real nunca será armazenado no Trait. O objeto SensitiveParameterValue encapsula o valor real do parâmetro – se você precisar dele por qualquer razão.

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

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

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

Essencialmente, esta nova função é uma combinação de mysqli_prepare(), mysqli_execute(), e mysqli_stmt_get_result() funções. Com ela, a consulta MySQLi será preparada, vinculada (se você passar qualquer parâmetro), e executada na própria função. Caso a consulta for executada com sucesso, ela retornará um objeto mysqli_result. Se não for bem-sucedida, ela retornará false.

A proposta da 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);
}

Recuperando propriedades do enum nas expressões de const

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

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

Permitir a busca de propriedades enum em lugares onde enum objetos 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 Traits

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

Atualmente, Traits só permitem definir métodos e propriedades, mas não constantes. Isso significa que você não pode definir invariantes esperados por um Trait no próprio Trait. Para contornar esta 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 a definição de constantes em Traits. Estas constantes podem ser definidas da mesma forma que você definiria constantes de classe. Este exemplo tirado diretamente da RFC limpa o ar ao redor do 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';
        }
    }
}

Constantes de Traits também são fundidas na definição da classe compositora, o mesmo que as definições de propriedade e método de um Trait. Elas também têm restrições similares como propriedades de Traits. Como observado na RFC, esta proposta – embora seja um bom começo – precisa de mais trabalho para dar corpo à funcionalidade.

Depreciações do PHP 8.2

Podemos agora explorar todas as depreciações no PHP 8.2. Esta lista não é tão grande quanto suas novas funcionalidades:

Depreciação de propriedades dinâmicas (e novos atributos #[AllowDynamicProperties])

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

class Post {
    private int $pid;
}

$post = new Post();
$post->name = 'Kinsta';

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

As propriedades dinâmicas permitem que bugs e comportamentos inesperados apareçam em seu código. Por exemplo, se você cometer algum erro ao declarar uma propriedade de classe fora da classe, é fácil perdê-la de vista – especialmente ao depurar qualquer erro dentro daquela classe.

A partir do PHP 8.2, as propriedades dinâmicas são depreciadas. Definir um valor para uma propriedade de classe não declarada irá emitir um aviso de depreciaçã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;

Entretanto, no PHP 9.0, a configuração do mesmo irá lançar um erro ErrorException.

Caso o seu código está cheio de propriedades dinâmicas – e há muito código PHP que está – e se você quiser parar esses avisos de depreciação após atualizar para o PHP 8.2, você pode usar o novo atributo #[AllowDynamicProperties] do PHP 8.2 para permitir propriedades dinâmicas nas classes.

#[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;

Segundo a RFC, as classes marcadas como #[AllowDynamicProperties], assim como suas classes, podem continuar usando propriedades dinâmicas sem depreciações ou remoções.

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

Depreciação de Callables parcialmente suportados

Outra mudança no PHP 8.2, embora com um impacto mais insignificante, é depreciar os callables parcialmente suportados.

Estes callables são chamados parcialmente suportados porque você não pode interagir com eles diretamente via $callable(). Você só pode chegar até eles 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"]

A partir do PHP 8.2, qualquer tentativa de invocar tais callables – como, por exemplo, através das funções call_user_func() ou array_map() – lançará um aviso de depreciação.

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

Com exceção dos dois últimos casos, todos estes callables são dependentes do contexto. O método a que "self::method" se refere depende de qual classe a chamada ou verificação de callability é realizada. Na prática, isto normalmente também é válido para os dois últimos casos, quando usado na forma de [new Foo, "parent::method"].

Reduzir a dependência do contexto de chamadas é o objetivo secundário desta RFC. Depois desta RFC, a única dependência de escopo ainda resta é a visibilidade do método: "Foo::bar" pode ser visível em um escopo, mas não em outro. Se os 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 feitos independentes do escopo), então o tipo callable tornar-se-ia bem definido e poderia ser usado como um tipo de propriedade.Entretanto, mudanças no tratamento da visibilidade não são propostas como parte desta RFC

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

Para evitar confusão, o escopo deste aviso de depreciação foi expandido com uma nova RFC – agora inclui estas exceções.

É bom ver o PHP se movendo para ter um tipo bem definido callable.

Funções depreciadas #utf8_encode() e utf8_decode()

As funções integradas do PHP utf8_encode() e utf8_decode() convertem strings codificadas em ISO-8859-1 (“Latin 1”) de e para 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ê normalmente verá Mojibake quando estas funções não podem converter nenhuma string corretamente. A falta de mensagens de erro também significa que é difícil identificá-las, especialmente dentro de um mar de textos legíveis.

PHP 8.2 deprecia ambas as funções #utf8_encode() e utf8_decode() . Se você as invocar, você verá estes avisos de depreciação:

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.

Interpolação de Strings depreciadas de ${}

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

1. Incorporação direta de variáveis – “$foo”
2. Com aparelho fora da variável – “{$foo}”
3. Com aparelho após o sinal do dólar – “${foo}”
4. Variáveis – “${expr}” – equivalente ao uso de (string) ${expr}

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

Você deve se afastar de interpolar as strings desta maneira, seguindo em 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, estas depreciações serão atualizadas para lançar um erro de exceção.

Funções depreciadas de mbstring para entidades Base64/QPrint/Uuencode/HTML

As funções mbstring (multi-byte string) do PHP nos ajudam a trabalhar com Unicode, entidades HTML, e outras codificações de texto legado.

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

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

Além disso, o PHP está sempre melhorando suas funções integradas – 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á depreciando o uso de mbstring para essas codificações (os rótulos são insensíveis a maiúsculas e minúsculas):

• BASE64
• UUENCODE
• HTML-ENTITIES
• html (aliás de HTML-ENTITIES)
• Citação-Printable
• qprint (aliás de Quoted-Printable)

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

Outras pequenas mudanças no PHP 8.2

Finalmente, nós podemos discutir as pequenas mudanças do PHP 8.2, incluindo suas características e funcionalidades removidas.

Suporte removido para libmysql do mysqli

A partir de agora, o PHP permite que tanto os drivers mysqli quanto PDO_mysql possam ser construídos contra bibliotecas mysqlnd e libmysql. Entretanto, o driver padrão e recomendado desde o PHP 5.4 tem sido mysqlnd.

Ambos os motoristas 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 unitários.

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

• Está empacotado com PHP
• Ele usa o 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 PHP
• Sua funcionalidade não depende da biblioteca externa
• Funcionalidade de plugin opcional
• Suporta consultas assíncronas

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

• Autorreconexão é possível (⁣mysqlnd não suporta esta funcionalidade intencionalmente porque pode ser facilmente explorada)
• Modos de autenticação LDAP e SASL (mysqlnd pode adicionar este 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 falhos, vazamentos de memória, diferentes funcionalidades entre versões, etc.

Tendo tudo isso em mente, o PHP 8.2 removeu o suporte à construção mysqli contra libmysql.

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

Conversão de caso independente do Locale-Independent

Antes do PHP 8.0, o locale do PHP era herdado do ambiente do sistema. Mas isso poderia causar um problema em alguns casos extremos.

Configurando sua linguagem durante a instalação do Linux, definirá a linguagem apropriada da interface do usuário para seus comandos embutidos. No entanto, isso também muda inesperadamente como a funcionalidade de manipulação de strings da biblioteca C funciona.

Por exemplo, se você selecionou a linguagem “Turco” ou “Cazaque” ao instalar o Linux, você verá que ligando para toupper('i') para obter seu equivalente em maiúsculas obteria o capital I pontilhado (U+0130, İ).

O PHP 8.0 parou esta anomalia ao definir o local padrão como “C”, a menos que o usuário o mude explicitamente via setlocale().

O PHP 8.2 vai ainda mais longe, removendo a sensibilidade local das conversões de caso. Esta RFC muda principalmente strtolower(), strtoupper(), e funções relacionadas. Leia a RFC para obter uma lista de todas as funções afetadas.

Como alternativa, se você quiser usar a conversão de casos localizados, então você pode usar mb_strtolower().

Melhoria da extensão aleatória (Random)

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

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

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

Assim, a funcionalidade aleatória atual do PHP não pode reproduzir valores aleatórios consistentemente. Ela até falha nos testes estatísticos empíricos de geradores de números aleatórios uniformes, como o TestU01’s Crush e BigCrush. A limitação de 32 bits do Mersenne Twister exacerba ainda mais isso.

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

Entretanto, várias questões com esta RFC foram levantadas após o início da votação. Este revés forçou a equipe PHP a anotar todas as questões em uma RFC separada, com uma opção de cédula criada para cada questão. Eles decidirão ir mais longe somente após chegar a um consenso.

RFCs adicionais no PHP 8.2

O PHP 8.2 também inclui novas funções e pequenas mudanças. Iremos mencioná-las abaixo com links para recursos adicionais:

1. Nova função curl_upkeep: O PHP 8.2 adiciona esta nova função à sua extensão Curl. Ela chama a função curl_easy_upkeep() na libcurl, a biblioteca C subjacente que a extensão Curl do PHP usa.
2. Nova função ini_parse_quantity: As diretrizes INI do PHP aceitam tamanhos de dados com um sufixo multiplicador. Por exemplo, você pode escrever 25 Megabytes como 25M, ou 42 Gigabytes como apenas 42G. Estes sufixos são comuns nos arquivos INI do PHP, mas são incomuns em outros lugares. Esta nova função analisa os valores do PHP INI e retorna seu tamanho de 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. Ela pode ser útil quando você estiver executando a mesma ação várias vezes e quiser gravar o uso de memória de pico de cada execução.
4. Suporte para modificador sem captura (/n) em funções preg_*: No regex, os meta caracteres () indicam um grupo de captura. Isso significa que todas as correspondências para a expressão no parêntese são retornadas. O PHP 8.2 adiciona um modificador de não captura (/n) para parar este comportamento.
5. Faça a família iterator_*() aceitar todos os iterables: A partir de agora, a família iterator_*() do PHP só aceita \Traversables (ou seja, não são permitidos arrays simples). É desnecessariamente limitador, e este RFC corrige isso.

Resumo

O PHP 8.2 se baseia nas enormes melhorias do PHP 8.0 e PHP 8.1, o que não é um feito fácil. Pensamos que as características mais excitantes do PHP 8.2 são seus novos tipos autônomos, propriedades somente de leitura e numerosas melhorias de desempenho.

Mal podemos esperar para comparar o PHP 8.2 com vários frameworks PHP e CMS.

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