PHP 8.5 のパイプ演算子が構文とパフォーマンスを巡って議論を呼ぶ、 JavaScript の停滞した実装と比較して

PHP 開発者たちは、バージョン8.5で導入される新しいパイプ演算子（>）について活発に議論しているが、コミュニティの反応は興奮と実装への懸念の両方を示している。この機能により、関数呼び出しをより読みやすい方法でチェーンでき、ネストした関数呼び出しを左から右に読める線形パイプラインに変換できる。

PHP 8.5 パイプ演算子構文の例:

// 基本的なパイプの使用法
$result = "Hello World" > strlen(...);

// 連鎖操作
$result = $arr
    > fn($x) => array_column($x, 'tags')
    > fn($x) => array_merge(...$x)
    > array_unique(...)
    > array_values(...);

// 同等のネストした関数呼び出し
array_values(array_unique(array_merge(...array_column($arr, 'tags'))));

JavaScript コミュニティは羨望の眼差し

PHP のパイプ演算子の発表は JavaScript 界隈で波紋を呼んでおり、同様の機能を10年以上待ち続けている開発者たちの神経を逆撫でしている。 JavaScript のパイプ演算子提案は TC39 プロセスのステージ2で停滞したままで、エンジン実装者たちがクロージャ作成に関するパフォーマンスの懸念を提起している。これにより、 PHP が長年要求してきた機能を成功裏に実装するのを見て、 JavaScript 開発者たちの間でフラストレーションが高まっている。

この対比は特に鋭いものがある。なぜなら JavaScript は既に async/await システムを通じて一時的なクロージャに大きく依存しており、パフォーマンスに関する議論が多くの開発者にとって一貫性を欠いているように見えるからだ。一部のコミュニティメンバーは、エンジン実装者がこれほどまでにプログラミングスタイルを決定すべきなのかと疑問視している。

JavaScript vs PHP パイプ演算子の状況:

構文の制限が実用的な懸念を引き起こす

パイプ演算子はよりクリーンなコードを提供する一方で、 PHP 開発者たちは実世界での使用に影響を与える可能性のある重大な制限を発見している。この演算子は、チェーン内のすべての関数が正確に1つのパラメータを受け取ることを要求し、パイプされた値は常に最初のパラメータ位置に渡される。これにより、 array_key_exists() のように配列を2番目のパラメータとして期待する PHP の悪名高く一貫性のない標準ライブラリで問題が生じる。

回避策として問題のある関数をクロージャでラップする必要があるが、一部の開発者はこれがパイプ演算子を持つ目的を台無しにすると主張している。この制限により、開発者は期待していたクリーンで直接的な関数呼び出しの代わりに、冗長なラムダ関数を書くことを強いられる。

PHP のパイプ演算子の主な制限事項：

• すべての関数は必須パラメータを1つだけ受け取る必要がある
• パイプされた値は常に最初のパラメータ位置に渡される
• パイプ内でパラメータの位置を変更することができない
• パラメータを持たない組み込み関数はチェーンで使用できない
• パラメータの順序が一貫していない関数にはクロージャでのラップが必要

パフォーマンスとメモリ効率の疑問

コミュニティでの議論では、パイプ演算子の効率性について代替手段と比較した懸念が明らかになっている。データをストリーミングする Unix シェルパイプとは異なり、 PHP の実装は各ステップで一時変数を作成し、従来のアプローチよりも多くのメモリを使用する可能性がある。一部の開発者は、特に大規模なデータ処理タスクにおいて、可読性の利点がオーバーヘッドを正当化するかどうか疑問視している。

議論は、 PHP がイテレータベースのソリューションや拡張メソッドに焦点を当てるべきだったかどうかにまで及んでおり、これらはより良いパフォーマンス特性で同様の可読性を提供できたかもしれない。

標準ライブラリの一貫性の欠如が問題を拡大

パイプ演算子は PHP の標準ライブラリの長年の問題を浮き彫りにした：一貫性のないパラメータの順序である。 array_filter() や array_map() のような関数は異なる順序でパラメータを取るため、パイプチェーンでの使用が不自然になる。基盤となる C ライブラリから継承されたこの一貫性の欠如は、スムーズな関数パイプラインを作成しようとする際により問題となる。

「標準ライブラリがあまりにも一貫性がないため、これは悪夢となるだろう。 PHP 開発者はまず完全な Unicode サポートに焦点を当て、その後でより良い設計の新しい名前空間付き標準ライブラリに焦点を当てるべきだ。」

多くの開発者は、問題をより顕著に露呈する新しい構文機能を追加する前に、 PHP はこれらの根本的な問題の修正を優先すべきだと主張している。

将来の展望と言語の進化

批判にもかかわらず、多くの PHP 開発者はパイプ演算子をより現代的なプログラミングパターンへの一歩と見なしている。この機能は PHP の既存のファーストクラス callable 構文とうまく連携し、後のバージョンで計画されている部分関数適用や関数合成演算子などの将来の拡張への扉を開く。

この実装は、実行が完璧でないとしても、 PHP が手続き型のルーツから関数型プログラミングパターンをサポートする方向への継続的な進化を表している。設計の一貫性のなさでしばしば批判される言語にとって、パイプ演算子は適合が完璧でない場合でも、より現代的な言語から機能を採用する PHP の意欲を示している。

参考： PHP 8.5 Adds Pipe Operator: What it means