PHP 8.2 の新機能 — 新機能、非推奨、変更など

公開: 2022-08-09

PHP 8.2 は、PHP 8.0 および PHP 8.1 によって定められた更新されたベースの上に構築されています。 2022 年 11 月 24 日にリリースされる予定です。

この記事では、PHP 8.2 の新機能について詳しく説明します。新しい機能や改善点から、非推奨やマイナーな変更まで、すべてを取り上げます。

PHP 8.2 は 2022 年 7 月 19 日に機能凍結に入ったため、このリストへの重要な追加は期待できません。

興奮した? 私たちもです。

さぁ、始めよう!

PHP 8.2 の新機能と改善点

最新の PHP 8.2 機能をすべて調べることから始めましょう。 それは非常に広範なリストです:

新しいreadonlyクラス

PHP 8.1 では、クラス プロパティのreadonly機能が導入されました。 現在、PHP 8.2 では、クラス全体をreadonlyとして宣言するサポートが追加されています。

クラスをreadonlyとして宣言すると、そのすべてのプロパティが自動的にreadonly機能を継承します。 したがって、クラスをreadonlyと宣言することは、すべてのクラス プロパティをreadonlyとして宣言することと同じです。

たとえば、PHP 8.1 では、すべてのクラス プロパティをreadonlyとして宣言するために、次の面倒なコードを記述する必要がありました。

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

より多くのプロパティで同じことを想像してみてください。 PHP 8.2 では、次のように記述できます。

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

また、抽象クラスまたは最終クラスをreadonlyとして宣言することもできます。 ここでは、キーワードの順序は重要ではありません。

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

プロパティを持たないreadonlyクラスを宣言することもできます。 事実上、これにより、子クラスがreadonlyプロパティを明示的に宣言できるようにしながら、動的プロパティを防ぐことができます。

次に、 readonlyクラスには、型指定されたプロパティのみを含めることができます。これは、個々の読み取り専用プロパティを宣言する場合と同じ規則です。

厳密に型指定されたプロパティを宣言できない場合は、 mixed型プロパティを使用できます。

型指定されたプロパティなしでreadonlyクラスを宣言しようとすると、致命的なエラーが発生します。

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

さらに、特定の PHP 機能に対してreadonlyを宣言することはできません。

  • 列挙型(プロパティを含むことができないため)
  • 特徴
  • インターフェース

これらの機能をreadonlyとして宣言しようとすると、解析エラーが発生します。

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

すべての PHP キーワードと同様に、 readonlyキーワードは大文字と小文字を区別しません。

PHP 8.2 では、動的プロパティも廃止されます (詳細は後述)。 ただし、動的プロパティがクラスに追加されるのを防ぐことはできません。 ただし、 readonlyクラスに対してこれを行うと、致命的なエラーが発生するだけです。

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

スタンドアロン型としてtruefalse 、およびnullを許可する

PHP には、すでにintstringboolなどのスカラー型が含まれています。 これは PHP 8.0 で拡張され、union 型が追加され、異なる型の値を使用できるようになりました。 同じ RFC では、共用体型の一部としてfalsenullを使用することも許可されていましたが、スタンドアロン型としては許可されていませんでした。

falsenullを宣言したり、スタンドアロン型として宣言しようとした場合 (ユニオン型の一部ではない場合)、致命的なエラーが発生しました。

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

このシナリオを回避するために、PHP 8.2 ではfalsenullをスタンドアロン型として使用するためのサポートが追加されています。 この追加により、PHP の型システムはより表現力豊かで完全なものになります。 戻り値、パラメーター、およびプロパティの型を正確に宣言できるようになりました。

また、PHP にはまだtrue型が含まれていません。これは、 false型の自然な対応のようです。 PHP 8.2 ではこれが修正され、 true型のサポートも追加されています。 false型の動作とまったく同じように、強制は許可されません。

true型とfalse型はどちらも、基本的に PHP のbool型の共用体型です。 重複を避けるために、これら 3 つの型を共用体型で一緒に宣言することはできません。 これを行うと、コンパイル時に致命的なエラーが発生します。

論理和正規形 (DNF) 型

Disjunctive Normal Form (DNF) は、ブール式を編成する標準化された方法です。 これは論理積の論理和で構成されます — ブール用語では、これは AND の OR です

型宣言に DNF を適用すると、パーサーが処理できる結合された Union 型と Intersection 型を記述する標準的な方法が可能になります。 PHP 8.2 の新しい DNF 型機能は、適切に使用すればシンプルですが強力です。

RFC は次の例を示しています。 次のインターフェイスとクラスの定義が既に存在することを前提としています。

 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 {}

DNF 型を使用すると、プロパティ、パラメーター、および戻り値の型宣言を次のように実行できます。

 // 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

場合によっては、プロパティが DNF 形式でないことがあります。 それらをそのように宣言すると、解析エラーが発生します。 ただし、いつでも次のように書き換えることができます。

 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

DNF タイプの各セグメントは一意でなければならないことに注意してください。 たとえば、 (A&B)|(B&A)宣言は、2 つのORセグメントが論理的に同じであるため無効です。

これに加えて、他のセグメントの厳密なサブセットであるセグメントも許可されていません。 これは、スーパーセットが既にサブセットのすべてのインスタンスを持っているため、DNF の使用が冗長になるためです。

バック トレースの機密パラメータを編集する

ほぼすべてのプログラミング言語と同様に、PHP ではコード実行の任意の時点でコール スタックをトレースできます。 スタック トレースにより、エラーやパフォーマンスのボトルネックを修正するためのコードのデバッグが容易になります。 これは、WordPress サイト用にカスタム設計されたパフォーマンス監視ツールである Kinsta APM などのツールのバックボーンを形成します。

Kinsta APM ツールを使用して遅い WooCommerce トランザクションを追跡します。
Kinsta APM を使用して遅い WooCommerce トランザクションを追跡します。

スタック トレースを実行しても、プログラムの実行は停止しません。 通常、ほとんどのスタック トレースはバックグラウンドで実行され、必要に応じて後で検査できるようにログに記録されます。

ただし、これらの詳細な PHP スタック トレースの一部は、通常はエラー ログ分析、エラー追跡などのためにサードパーティ サービスと共有すると、問題になる可能性があります。これらのスタック トレースには、ユーザー名、パスワード、環境変数などの機密情報が含まれる場合があります。 .

この RFC 提案は、そのような例の 1 つを示しています。

よくある「攻撃者」の 1 つは PDO です。PDO は、純粋なコンストラクターと別の ->connect()メソッドを使用する代わりに、データベース パスワードをコンストラクター パラメーターとして受け取り、コンストラクター内でデータベースへの接続をすぐに試みます。 したがって、データベース接続が失敗すると、スタック トレースにはデータベース パスワードが含まれます。

 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}

PHP 8.2 では、このような機密パラメータを新しい\SensitiveParameter属性でマークできます。 機密としてマークされたパラメーターは、バックトレースにリストされません。 したがって、サードパーティのサービスと心配することなく共有できます。

以下は、1 つのセンシティブなパラメーターを使用した簡単な例です。

 <?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 */

バックトレースを生成すると、 \SensitiveParameter属性を持つすべてのパラメーターが\SensitiveParameterValueオブジェクトに置き換えられ、その実際の値がトレースに格納されることはありません。 SensitiveParameterValueオブジェクトは、何らかの理由で必要な場合に、実際のパラメーター値をカプセル化します。

新しいmysqli_execute_query関数とmysqli::execute_queryメソッド

パラメータ化された MySQLi クエリを実行するためだけに、危険なほどユーザー値をエスケープするmysqli_query()関数を使用したことがありますか?

PHP 8.2 では、新しいmysqli_execute_query($sql, $params)関数とmysqli::execute_queryメソッドにより、パラメーター化された MySQLi クエリの実行が容易になります。

基本的に、この新しい関数はmysqli_prepare()mysqli_execute() 、およびmysqli_stmt_get_result()関数の組み合わせです。 これにより、MySQLi クエリが準備され、バインドされ (パラメーターを渡す場合)、関数自体の中で実行されます。 クエリが正常に実行されると、 mysqli_resultオブジェクトが返されます。 失敗した場合はfalseを返します。

RFC の提案は、単純だが強力な例を示しています。

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

const式でenumプロパティをフェッチする

この RFC は、 ->/?->演算子がconst式でenum型プロパティを取得できるようにすることを提案しています。

この新機能の主な理由は、配列キーなどの一部の場所でenumオブジェクトを使用できないことです。 そのような場合、それを使用するためだけにenumケースの値を繰り返す必要があります。

enum型オブジェクトが許可されていない場所でenum型プロパティのフェッチを許可すると、この手順を簡素化できます。

これは、次のコードが有効になったことを意味します。

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

安全のために、この RFC には nullsafe 演算子?->のサポートも含まれています。

特性で定数を許可する

PHP には、Traits と呼ばれるコードを再利用する方法が含まれています。 クラス間でのコードの再利用に最適です。

現在、Traits はメソッドとプロパティの定義のみを許可しており、定数は許可していません。 つまり、特性自体の中で特性によって期待される不変条件を定義することはできません。 この制限を回避するには、構成クラスまたは構成クラスによって実装されるインターフェイスで定数を定義する必要があります。

この RFC は、Traits で定数を定義できるようにすることを提案しています。 これらの定数は、クラス定数を定義するのと同じように定義できます。 RFC から直接引用したこの例は、その使用法に関する空気をきれいにします。

 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'; } } }

特性定数も、特性のプロパティおよびメソッド定義と同じように、構成クラスの定義にマージされます。 また、Traits のプロパティと同様の制限があります。 RFC に記載されているように、この提案は (良いスタートではありますが) 機能を具体化するためにさらに作業が必要です。

PHP 8.2 での非推奨

これで、PHP 8.2 で廃止されたすべての機能を調べることができます。 このリストは、新機能ほど大きくはありません。

動的プロパティの廃止 (および新しい#[AllowDynamicProperties]属性)

PHP 8.1 までは、PHP で宣言されていないクラス プロパティを動的に設定および取得できました。 例えば:

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

ここで、 Postクラスはnameプロパティを宣言していません。 ただし、PHP では動的プロパティが許可されているため、クラス宣言の外で設定できます。 それが最大の、そしておそらく唯一の利点です。

動的プロパティを使用すると、予期しないバグや動作がコードに発生する可能性があります。 たとえば、クラスの外部でクラス プロパティを宣言する際に間違いを犯した場合、特にそのクラス内のエラーをデバッグする場合は、簡単に追跡できなくなります。

PHP 8.2 以降、動的プロパティは非推奨になりました。 宣言されていないクラス プロパティに値を設定すると、プロパティが最初に設定されたときに廃止通知が発行されます。

 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;

ただし、PHP 9.0 以降では、同じ設定を行うとErrorExceptionエラーがスローされます。

コードが動的プロパティでいっぱいであり、動的プロパティがたくさんある場合、および PHP 8.2 へのアップグレード後にこれらの廃止通知を停止したい場合は、PHP 8.2 の新しい#[AllowDynamicProperties]属性を使用して動的プロパティを許可できます。クラスのプロパティ。

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

RFC に従って、 #[AllowDynamicProperties]としてマークされたクラスとその子クラスは、非推奨または削除なしで動的プロパティを引き続き使用できます。

また、PHP 8.2 では、 #[AllowDynamicProperties]としてマークされた唯一のバンドル クラスはstdClassであることに注意してください。 さらに、 __get()または__set() PHP マジック メソッドを介してアクセスされるプロパティは、動的プロパティとは見なされないため、廃止通知はスローされません。

部分的にサポートされている Callable の廃止

PHP 8.2 のもう 1 つの変更点は、影響はほとんどありませんが、部分的にサポートされている callable を非推奨にすることです。

これらの callable は、 $callable()を介して直接対話できないため、部分的にサポートされていると呼ばれます。 call_user_func($callable)関数でのみアクセスできます。 そのような callable のリストは長くありません:

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

PHP 8.2 以降、 call_user_func()array_map()関数などを介してそのような callable を呼び出そうとすると、非推奨の警告がスローされます。

元の RFC は、この非推奨の背後にある確固たる理由を示しています。

最後の 2 つのケースを除いて、これらの callable はすべてコンテキスト依存です。 "self::method"が参照するメソッドは、呼び出しまたは呼び出し可能性チェックが実行されるクラスによって異なります。 実際には、 [new Foo, "parent::method"]の形式で使用される場合、これは通常、最後の 2 つのケースにも当てはまります。

callable のコンテキスト依存性を減らすことは、この RFC の二次的な目標です。 この RFC の後、残っている唯一のスコープ依存性はメソッドの可視性です。 "Foo::bar"は、あるスコープでは可視であるかもしれませんが、別のスコープでは可視ではないかもしれません。 将来、callable がパブリック メソッドに制限される場合 (プライベート メソッドは、スコープに依存しないようにするために、ファースト クラスの callable またはClosure::fromCallable()を使用する必要があります)、callable 型は明確に定義され、プロパティ タイプとして使用されます。 ただし、可視性処理の変更は、この RFC の一部として提案されていません

元の RFC に従って、 is_callable()関数とcallable型は引き続きこれらの callable を例外として受け入れます。 ただし、これらのサポートが PHP 9.0 以降で完全に削除されるまでは。

混乱を避けるために、この非推奨通知の範囲は新しい RFC で拡張されました。現在、これらの例外が含まれています。

PHP が明確に定義されたcallable型を持つ方向に進んでいるのを見るのは良いことです。

#utf8_encode()およびutf8_decode()関数の廃止

PHP の組み込み関数utf8_encode()およびutf8_decode()は、ISO-8859-1 (「Latin 1」) でエンコードされた文字列を UTF-8 との間で変換します。

ただし、それらの名前は、実装が許可するよりも一般的な用途を示唆しています。 「Latin 1」エンコーディングは、「Windows Code Page 1252」などの他のエンコーディングとよく混同されます。

さらに、これらの関数が文字列を適切に変換できない場合、通常は Mojibake が表示されます。 エラー メッセージが表示されないということは、エラー メッセージを見つけるのが難しいということでもあります。特に、他の方法では判読可能なテキストが大量にある場合はなおさらです。

PHP 8.2 では、 #utf8_encode()およびutf8_decode()関数の両方が非推奨になりました。 それらを呼び出すと、次の廃止通知が表示されます。

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

RFC では、代わりにmbstringiconvintlなど、PHP でサポートされている拡張機能を使用することを提案しています。

${}文字列補間の廃止

PHP では、いくつかの方法で、二重引用符 ( " ) とヒアドキュメント ( <<< ) を使用して文字列に変数を埋め込むことができます。

  1. 変数を直接埋め込む — “$foo”
  2. 変数の外側に中かっこがある — “{$foo}”
  3. ドル記号の後に中かっこを付けて — “${foo}”
  4. 可変変数 — “${expr}”(string) ${expr}を使用するのと同等

最初の 2 つの方法には長所と短所がありますが、後者の 2 つの方法には複雑で競合する構文があります。 PHP 8.2 は、文字列補間の最後の 2 つの方法を廃止します。

今後は、この方法で文字列を補間しないようにする必要があります。

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

PHP 9.0 以降、これらの非推奨は例外エラーをスローするようにアップグレードされます。

Base64/QPrint/Uuencode/HTML エンティティの mbstring 関数の廃止

PHP の mbstring (マルチバイト文字列) 関数は、Unicode、HTML エンティティ、およびその他の従来のテキスト エンコーディングを処理するのに役立ちます。

ただし、Base64、Uuencode、および QPrint はテキスト エンコーディングではなく、依然としてこれらの関数の一部です。これは主に従来の理由によるものです。 PHP には、これらのエンコーディングの個別の実装も含まれています。

HTML エンティティに関しては、PHP には組み込み関数htmlspecialchars()およびhtmlentities() ) があり、これらをより適切に処理できます。 たとえば、mbstring とは異なり、これらの関数は<も変換します。 > 、および&文字を HTML エンティティに。

さらに、PHP は組み込み関数を常に改善しています — PHP 8.1 が HTML エンコーディングおよびデコーディング関数を備えているように。

したがって、これらすべてを念頭に置いて、PHP 8.2 はこれらのエンコーディングでの mbstring の使用を非推奨にしています (ラベルは大文字と小文字を区別しません)。

  • BASE64
  • UUENCODE
  • HTMLエンティティ
  • html (HTML-ENTITIES のエイリアス)
  • 引用された-印刷可能
  • qprint (Quoted-Printable の別名)

PHP 8.2 以降、mbstring を使用して上記のいずれかをエンコード/デコードすると、廃止通知が発行されます。 PHP 9.0 では、これらのエンコーディングの mbstring サポートが完全に削除されます。

PHP 8.2 でのその他のマイナーな変更

最後に、削除された機能を含む PHP 8.2 の小さな変更点について説明します。

mysqli から libmysql のサポートを削除

現在、PHP では、 mysqliおよびPDO_mysqlドライバーの両方がmysqlndおよびlibmysqlライブラリに対してビルドできます。 ただし、PHP 5.4 以降のデフォルトで推奨されるドライバーはmysqlndです。

これらのドライバーには両方とも、多くの長所と短所があります。 ただし、そのうちの 1 つのサポートを削除すると (理想的には、デフォルトではないlibmysqlを削除します)、PHP のコードと単体テストが簡素化されます。

この支持を主張するために、RFC はmysqlndの多くの利点を挙げています。

  • PHPにバンドルされています
  • PHP メモリ管理を使用してメモリ使用量を監視し、
    性能を上げる
  • 生活の質を向上させる機能を提供します (例: get_result() )
  • PHP ネイティブ型を使用して数値を返します
  • その機能は外部ライブラリに依存しません
  • オプションのプラグイン機能
  • 非同期クエリをサポート

RFC には、次のようなlibmysqlのいくつかの利点もリストされています。

  • 自動再接続が可能です (簡単に悪用される可能性があるため、 mysqlndは意図的にこの機能をサポートしていません)。
  • LDAP および SASL 認証モード ( mysqlndもこの機能をすぐに追加する可能性があります)

さらに、RFC にはlibmysqlの多くの欠点が挙げられています — PHP メモリ モデルとの非互換性、多くの失敗したテスト、メモリ リーク、バージョン間の機能の違いなど。

これらすべてを念頭に置いて、PHP 8.2 ではmysqliに対してlibmysqlをビルドするためのサポートが削除されました。

libmysqlでのみ利用可能な機能を追加したい場合は、機能要求として明示的にmysqlndに追加する必要があります。 また、自動再接続を追加することはできません。

ロケールに依存しない大文字と小文字の変換

PHP 8.0 より前では、PHP のロケールはシ​​ステム環境から継承されていました。 しかし、これはいくつかのエッジケースで問題を引き起こす可能性があります.

Linux のインストール中に言語を設定すると、組み込みコマンドに適切なユーザー インターフェイス言語が設定されます。 ただし、C ライブラリの文字列処理機能の動作も予期せず変更されます。

たとえば、Linux のインストール時に「トルコ語」または「カザフ語」言語を選択した場合、 toupper('i')を呼び出して対応する大文字を取得すると、点付き大文字の I (U+0130, I ) が取得されることがわかります。

PHP 8.0 では、ユーザーがsetlocale()を介して明示的に変更しない限り、デフォルトのロケールを「C」に設定することで、この異常を停止しました。

PHP 8.2 では、大文字と小文字の変換からロケールの区別が取り除かれ、さらに進化しています。 この RFC は、主にstrtolower()strtoupper() 、および関連する関数を変更します。 影響を受けるすべての機能のリストについては、RFC を参照してください。

別の方法として、ローカライズされた大文字と小文字の変換を使用する場合は、 mb_strtolower()を使用できます。

ランダム拡張の改善

PHP はランダム機能のオーバーホールを計画しています。

現在、PHP のランダム機能は Mersenne Twister 状態に大きく依存しています。 ただし、この状態は PHP のグローバル領域に暗黙的に格納されており、ユーザーがアクセスすることはできません。 初期シード段階と意図した使用法の間にランダム化関数を追加すると、コードが壊れます。

コードで外部パッケージを使用する場合、このようなコードの保守はさらに複雑になる可能性があります。

したがって、PHP の現在のランダム機能はランダム値を一貫して再現できません。 TestU01 の Crush や BigCrush のような一様乱数ジェネレーターの経験的な統計テストにも失敗します。 Mersenne Twister の 32 ビット制限は、それをさらに悪化させます。

したがって、暗号的に安全な乱数が必要な場合、PHP の組み込み関数 — shuffle()str_shuffle()array_rand() — を使用することはお勧めしません。 そのような場合、 random_int()または同様の関数を使用して新しい関数を実装する必要があります。

ただし、投票が開始された後、この RFC に関するいくつかの問題が提起されました。 この後退により、PHP チームはすべての問題を個別の RFC に記録し、問題ごとに投票オプションを作成することを余儀なくされました。 彼らは、コンセンサスに達した後にのみ、先に進むことを決定します。

PHP 8.2 の追加の RFC

PHP 8.2 には、多くの新機能とマイナーな変更も含まれています。 それらについては、追加のリソースへのリンクとともに以下で説明します。

  1. 新しいcurl_upkeep関数: PHP 8.2 では、この新しい関数が Curl 拡張機能に追加されています。 これは、PHP Curl 拡張機能が使用する基礎となる C ライブラリである libcurl のcurl_easy_upkeep()関数を呼び出します。
  2. 新しいini_parse_quantity関数: PHP INI ディレクティブは、乗数サフィックス付きのデータ サイズを受け入れます。 たとえば、25 メガバイトを25Mとして、または 42 ギガバイトを単に42Gとして書き込むことができます。 これらのサフィックスは、PHP INI ファイルでは一般的ですが、他の場所では一般的ではありません。 この新しい関数は、PHP INI 値を解析し、データ サイズをバイト単位で返します。
  3. 新しいmemory_reset_peak_usage関数: この関数は、 memory_get_peak_usage関数によって返されるピーク メモリ使用量をリセットします。 同じアクションを複数回実行していて、各実行のピーク時のメモリ使用量を記録したい場合に便利です。
  4. preg_*関数での非キャプチャ修飾子 ( /n ) のサポート: 正規表現では、 ()メタ文字はキャプチャ グループを示します。 つまり、括弧内の式のすべての一致が返されます。 PHP 8.2 では、この動作を停止するために no-capture 修飾子 ( /n ) が追加されています。
  5. iterator_*()ファミリがすべての iterable を受け入れるようにする: 現在のところ、PHP のiterator_*()ファミリは\Traversablesのみを受け入れます (つまり、単純な配列は許可されません)。 これは不必要な制限であり、この RFC はそれを修正します。

概要

PHP 8.2 は、PHP 8.0 と PHP 8.1 の大幅な改善に基づいて構築されていますが、これは簡単なことではありません。 PHP 8.2 の最もエキサイティングな機能は、新しいスタンドアロン型、読み取り専用プロパティ、および多数のパフォーマンスの改善です。

PHP 8.2 をさまざまな PHP フレームワークと CMS でベンチマークするのが待ちきれません。

今後の参考のために、このブログ投稿をブックマークしておいてください。

どの PHP 8.2 機能がお気に入りですか? 最も嫌いな廃止予定はどれですか? コメントで私たちのコミュニティとあなたの考えを共有してください!