P++: 銀河に平和をもたらすための奇策と決着

PHP 8から、PHPは「PHP」と「P++」という2つの言語を提供するようになる

というキャッチーな紹介をするP++: 静的型付けをめざすPHPという記事がそれなりに話題になり、このニュースは目覚しく革新的な内容で、多くのひとの目を引き付けました。

これは早まった理解であり、ほとんど誤報と言ってもいい内容でした。2019年8月15日には提案者本人も、少くとも「P++」の計画を短期的に実現するととは非現実的であり時期尚早であることを認めています。

この記事では、PHP開発の現状、なぜ野心的なP++計画が提案され、事実上撤回されたかの経緯について紹介します。

[中立性のための表示] この記事の著者@tadsanはPHPの静的解析を強く推進する立場です。

• PHPゆるふわCI入門
• PHP型検査･夢と理想と現実)

三行で要約

• PHPはバージョンを経るごとに「歴史的経緯」による負債が削ぎ落されてきた
• PHPはRFCと呼ばれる提案とPHP開発者たちによる投票を経て意思決定される
• いわゆる「P++(仮称)」について、2019年8月現在で決まった事実は何もない

本題に入る前に本件に関連する重要人物にも軽く触れておきます。

• Zeev Suraski
  • 1997年にAndi GutmansとともにPHP 3を開発した
  • 2000年にPHP 4で仮想機械方式のインタプリタZend Engineを導入する
  • Zend Technologiesの社名や製品名に含まれるZendはZeevとAndiの合成語
  • 今回の**P++**の発案者
• Nikita Popov
  • PHP 5.5(2012年)以降、PHPに非常に数多くの提案と実装を行ってきた
  • PHP 7.0では構文解析処理を書き直しASTを導入するなどの立役者
  • PHPの処理系を改善すると同時に、多くのレガシーな仕様の廃止を提案してきた

今回の登場人物を含め、現在のPHP開発においては、誰もPHPについての意思決定権を持っていないことに注意してください。

Ruby作者のまつもとゆきひろ氏などは優しい終身の独裁者とも呼ばれ、Ruby開発における意思決定役を担っていますが、PHPの意思決定プロセスは多数決による投票制です。それはPHPの最初の開発者であるRasmus Lerdorfも同様で、PHP開発メンバーの一員として1票の投票権しかありません。

PHP 7から現在までのおさらい

これからの話の前にPHP 5系から現在までのPHPの変遷について復習します。PHP 7.0がリリースされたのは2015年12月であり、今からおよそ3年半前のことです。

はじめにPHP7以降の変更点から、主に文法の改善に着目して抜萃します。

• PHP: PHP 7.0 下位互換性のない変更点 - Manual
  • エラーや例外の取り扱いの変更
  • 変数やプロパティ、メソッドへの間接的なアクセスの扱い(結合)の変更
  • list() の取り扱いの変更
  • 参照による代入で自動的に作成した配列要素の並び順の変更
  • 同じ名前の引数をひとつの関数に複数定義できないようになった
  • 変数参照(&)をとる関数の引数を括弧で囲んだときの振る舞いの変更
  • 文字列の取り扱いの変更
    • 16進数値形式の文字列は数値とはみなさない
  • foreach の振る舞いの変更
  • 新しいオブジェクトを参照渡しで代入できないようになった
  • ASP タグと script タグの廃止
    • ASPタグ <% … %> <%= … %>
    • scriptタグ <script language="php">…</script>
    • PHP 5では上記形式でも設定によって <?php … ?> と同様に利用可能
  • switch 文に複数の default ブロックを書けない
• PHP: PHP 7.0.x で推奨されなくなる機能 - Manual
  • PHP 4 形式のコンストラクタ
  • 非 static メソッドに対する static 呼び出し
• PHP: PHP 7.0 その他の変更 - Manual
  • 予約語の制約の緩和 (予約語をメソッド名として利用可能になった)
• PHP: PHP 7.1 下位互換性のない変更点 - Manual
  • 関数に渡す引数が少ない場合の挙動
  • 変数スコープを調べる関数の動的呼び出しの禁止
  • ASCII 制御文字 delete 0x7F は識別子として使えない
• PHP: PHP 7.2 下位互換性のない変更点 - Manual
  • countable ではない型をカウントしたときに警告するように
• PHP: PHP 7.2.x で推奨されなくなる機能 - Manual
  • クオートしない文字列
  • (unset) キャスト
• PHP: PHP 7.3.x で推奨されなくなる機能 - Manual
  • 大文字と小文字を区別しない定数
• PHP: PHP 7.3 下位互換性のない変更点 - Manual
  • switch内のターゲット指定がないcontinueを警告するように

具体的な説明についてはリンクしたPHPマニュアルの記事を参照してください。

これらの項目のうちには、「複数の記法を一種類に統一した」もののほか、「なぜPHP 5ではこんな不可解な仕様があったのか」と首をかしげるものも含まれます。この要因としてはPHP 7.0で構文解析プロセスの改善(パーサの書き直し、抽象構文木の導入)に伴って、PHP 5時代にあった不合理な文法的制約が大きく取り払われたこと、が大きいです。

次に、PHP 7.0以降で追加された言語機能について主に型・クラス関連に絞って抜萃して紹介します。

• PHP: PHP 7.0 新機能 - Manual
  • declare(strict_types=1)で厳格モードの型宣言
    • ファイル単位での設定
  • スカラー型宣言
    • PHP 5では「型ヒント」あるいは「タイプヒンティング」と呼ばれ、array, callableとクラス名・インターフェイス名など一部キーワードのみ記述可能で、string, int, bool, floatなどのスカラー型は書くことができなかった
    • declare(strict_types=1) に設定していないとき独自のルールでキャスト
  • 戻り値の型宣言
  • 無名クラス new class {...} 式
• PHP: PHP 7.1新機能 - Manual
  • nullableな型 ?
  • 戻り値を返さない関数の特殊な型宣言 : void
  • iterable 擬似型
  • 複数の例外クラスの catch
• PHP: PHP 7.2新機能 - Manual
  • object 型宣言
  • パラメータの型の拡大変換
    • インターフェイスの実装やメソッドのオーバーライド時に引数の型指定を省略可能に
• PHP: PHP 7.3新機能 - Manual
  • (型に関連する目立った機能追加はなし)

これらの機能の改廃や追加はRequest for Comments(RFC)という提案と、php.internalsメーリングリストによる議論、PHP開発者らによる投票という手続きを経て導入されています。RFCにはそれぞれの提案の背景や経緯、モチベーション、目的、想定される影響などが明記されています。

まだマニュアルに含まれていませんが、PHP 7.4ではさらに数多くの提案が実装されて居り、実装済みのRFCも列挙します。

• PHP: rfc:covariant-returns-and-contravariant-parameters
  • 共変性と反変性 (計算機科学) - Wikipedia
  • 戻り値の型宣言が共変に、引数の型宣言が反変にできるようになった
• PHP: rfc:null_coalesce_equal_operator
  • ??= null合体代入演算子が追加された
• PHP: rfc:typed_properties_v2
  • プロパティに型宣言が書けるようになった

全体的に見て、PHPは過去の歴史的事情による非合理な仕様が取り除かれ、ほかのプログラミング言語にあるような言語機能が次々と取り入れられつつある過程にあると説明できます。このような機能追加の過程において非常に大きな役割を果たしてきたのがNikitaです。彼は2012年にジェネレータ(コルーチン)の導入をはじめ、現在に至るまでPHPに多くの提案をしてきました。

Nikitaは継続して多くの機能追加を提案してきただけでなく、毎年のバージョンアップの度にレガシーな機能の廃止提案も欠かさず行ってきました。今回の件の発端は現在投票期間中の提案PHP RFC: Deprecate short open tags, againです。

銀河に平和をもたらしたい

2019年8月8日にZeevがBringing Peace to the Galaxyという件名のメールをphp.internalsメーリングリストに投稿しました。

[... and not in the Sith Lord kind of way.]

件名と繋げると、銀河に平和をもたらす。 ……シス卿のような方法ではなく。 から始まる長文のメールです。冒頭部をざっくり訳すと以下のような内容です。

internals@(メーリングリスト)の最近の(それとあまり最近ではない)議論と最近の提案のいくつか、そして言語の方向性についてのいくつかの声明の見てください。明らかに私たちは両極化が高まっています。

Peterが昨日言ったように、一部のひとたちはいくつかのレガシーなものを取り除きたいのです。私が思うに実際にはその範疇を超えてしまっており、internals@の多くは、PHPの各部はひどく修理が必要で(私も一部同意しますが)、ほかの競合する言語にある機能が「彼らの意見では」非常に欠けているとのことです。

両極化した一方の端には、私たちが常に抱いていた、後方互換性についての強い偏見を維持すべきであり、PHPは緊急のオーバーホールを要しているわけではなく、機能に関して「少ないことは豊かなこと(less is more)、私たちはほかの言語から競って機能をコピーすることはせず、むしろPHPをシンプルに保つことを選択する」と考える人々が居ます。

これらの視点はほとんど正反対です。そのため、internals@の議論は片方が勝って相手が負けるゼロサムゲームと化してしまいました。

私は前者よりも後者の陣営での見方がずっと近いと言ってよいでしょう。それと同時に、前者の視点にも優位性があることも理解しています。私の陣営が「勝った」として、どちらかが勝てばどちらかが負ける議論による否定的な雰囲気や、そのほかのグループの(私がとても尊敬している)人々が感じる失望感は間違いなくプロジェクトにとって悪いことなので、私はしばしばピュロスの勝利(犠牲に見合わない勝利)のように感じます。(立場が逆になったときに、同じように感じてくれると願っています)

では、両方の陣営を本当に幸せにする方法があったらどうでしょうか。私はあると思います。

この記事ではこれまで7.0以降のPHPが積極的に後方互換性を切り捨てて新しい機能を取り込んできたことを紹介しました。しかしそれはPHPコミュニティの総意だということはなく、あまり好ましく思わない人々も少なからず居るということです。

話題に挙がった**P++**は、Zeevがそれを解決すべく提案したアイディアです。ここではC言語とC++、(旧来の)JavaScriptとES6のような関係を引き合いに出し、保守的な言語としてのPHPと、革新的な機能を取り込むため言語(仮称:P++)を分けよう、PHPの悪評を覆すために言語名は分けようというのです。

このメールの結びでは、このアイディアはコーナーケースについてまだ熟慮していない、生のアイディアであることを認めていますが、Zeevは技術的にも実現可能性は高いと見ており、ブレインストーミングを促したいというのがこのメールの趣旨です。

この議論の直接の契機となったのは、PHP RFC: Deprecate short open tags, againについての議論でしょう。この提案は<?php … ?>の代りに単に <? … ?> と書ける機能を廃止しようとする提案です。短いタグ(<? … ?>)はphp.iniで無効化することができるため、すくなくとも現代のPHPのライブラリとして一般公開されるようなコードでは <?php または <?= … ?> の二種類のタグのどちらかだけを使うことが暗黙の了解となっています。

しかしながら議論は上記で引用したメールで要約されたように、[RFC] [VOTE] Deprecate PHP's short open tags, again - Externalsのスレッドでは、いささか痛々しい応酬を呈しています。Zeevは廃止提案に対してCounterargument to Deprecate Short Tags RFC V2として反論をまとめています。要は「壊れてないものを直すな」「あってもなくても誰も困らない仕様を消すために時間を浪費するな(させるな)」という主張です。

つまりP++はどういう状況なの？

P++は現在、元スレッドのBringing Peace to the Galaxy - Externalsと次のスレッドP++: FAQ - Externalsで議論されています。

今回の渦中にある文章PHP: P++ idea: FAQは単なるメーリングリストの議論のための「よくある質問」をまとめたメモ書きをwiki.php.netに置いたに過ぎず、「PHP 8の方針について決定事項の告知」という性格のものではありません。 PHP 8.0で導入される実装済みの機能は https://wiki.php.net/rfc#php_80 を参照してください。

FAQの内容については型付きPHP、P++のFAQを参考にしてください。

さて、Nikitaはこのアイディアについて基本的に反対ですが、実現可能性に関しては、これまで数々の機能をPHPに取り入れてきたNikitaでさえ、次のような見解を示しています。

I think this part is unrealistic from a simple manpower perspective. We have something like ~2 full time developers working on PHP. Even if you can rally some additional interest around this idea, I don't think we have the resources to create a substantially different language in any reasonable amount of time. Doing feature additions and changes to PHP is Hard. Even simple changes require a fair bit of design and engineering effort to integrate with the large complexity of the existing language. This would not change for a hypothetical P++, because we still need to interoperate with PHP.

Even if I agreed with the idea (which I'm pretty skeptical about in this
particular form), I really don't think we have the resources to do
something like this.

https://externals.io/message/106453#106472

要約すると 単純に人材が居ないから無理。フルタイム開発者が興味を持って取り組んだとしても妥当な時間で実質的に新しい言語を完成させるのは無茶。PHPとP++を分けたところで相互運用しなきゃいけないんだし設計めっちゃ大変。私がこのアイディアに賛成したとしてもリソースがないから懐疑的と言ってますね。

現状まだRFCとして提案されておらず、「P++」の仕様はおろか実現可能性も含めて具体的な検討前の段階です。

「本の虫」の記事について

P++: 静的型付けをめざすPHP

PHPで静的型付けをしやすくする機能強化を推進する潮流があるのは事実で、そのような仕様強化はPHPではなくP++に行おうという提案である。ただし提案者のZeevはPHPの意思決定の代表者ではない。

PHP 8から、PHPは「PHP」と「P++」という2つの言語を提供するようになる。

P++はコミュニティの分断と対立を憂慮したZeevが解決のためにしたアイディア*(もはや奇策)*であり、メーリングリスト上でのブレインストーミングの対象とはなっているが、実装方針・実現可能性・リリース時期について何の意思決定がされたわけでもない。

また、FAQにおいては「PHP 8/9?」程度の言及であり、2020年12月にリリース見込みであるPHP 8.0にP++が導入されることをZeevが主張しているという事実もない。

PHPとP++は同じコードベースであり、ほとんどのコードは共有するので、PHPの開発リソースが2倍必要になることはない。

これは非常に楽観的な見解で、現状P++の仕様、特に型の設計について具体的なものは何も示されていないので、なんとも測りがたい要素です。型についてPHPの標準関数の挙動にまで及ぶ厳密な型システムを導入した場合、PHPとの相互運用のための開発リソースが2倍以上必要になるであろう事態も想像に堅くない。

ありそうな質問

• Q: なんでこのひと銀河の平和の話をしてるの？
• A: さあ…

---

私からは以上です。P++が本当に導入されるかどうかはどうでもいいですが、php.internalsに平和が訪れるといいですね。

追記 (8月15日)

日本時間で8月15日になって、Xdebug開発者でPHP 7.4リリースマネージャでもあるDerick RethansがRFCで「P++の実現可能性についての世論調査」という名目で投票を開始しました。これはPHPの開発方針として具体的な仕様を取り入れること決めるものではなく、それぞれのZeevが提案するP++プロジェクトに投票者(開発者)個人が時間とエネルギーを費す意向があるかということを調査するものです。

• Vote: Straw poll for P++ feasibility - Externals
• PHP: rfc: Poll: Feasibility of P++

こうやって陣営を色分けしようとすることが非難されたような気がしないでもないのですが、議論に時間を使う前にそれぞれの開発者の意向を明確にしたいのは理解できます。

日本時間の4時0分現在では0:22で圧倒的にNoです。これは世論調査なので通常のRFCとはかなり毛色が異なるのですが、普段のRFCで議決権を行使してないメンバーも積極的に「No」をつきつけている状況です。直近の提案だと投票者が多いものでPHP: rfc:typed_properties_v2に70人ほどが票を投じてるのですが、今回の意識調査にはTyped Propertyの議決に参加してないひとが投票しているので、あまり参考にならない感じです。

php.netのVCSのアカウント(＝RFCの議決権)を持っているからといってPHPのアクティブな開発者だというわけではないのですが、すくなくとも人数の面では多くの開発関係者が、P++は非現実的なアイディアだと見ている状況です。

追記2 (8月15日)

PHP: rfc: Poll: Feasibility of P++にZeev本人も「No」を投じ、短期的に「P++」計画が推進されることはなくなったようです。

(時刻表示はUTC: 日本時間 2019年8月15日5時59分)

雑な訳ですが、Vote: Straw poll for P++ feasibilityでのZeevの投稿を引用します。

ユーモラスなトーンによって、やっとinternals@がまとまったことを嬉しく思います。
私はあなたがたがこのアイディアが好きではなさそうだという感触を得ました。

大事なこととして、私はこの投票の正当性についての意見(投票の過程、権限などなど…)は自分の中にしまっておき、2点だけコメントします:

• このP++のアイディアは真空では無意味です。このアイデアに関する歓迎は、「1つの幸せな大家族」と「分裂」の間にある決定を暗示しました。現段階ではそれらが選択肢として理解されているので、私も反対票を投じたいです(いま投票しました、もちろん)。でも、それは間違った選択だと思います。
• 「1つの幸せな大家族」だけが選択肢ではないと明らかになったとき、それを議論するのは確実に意味があることです。家族をソフトに分割する方法を選びましょう: 「細分化 (2ⁿ方言)」「多くのエディション (n方言)」または「明確な権限の別の方言 (2方言)」。それは私たちの多く(私も多分に含まれる)にとっては不可解だと感じ、このアイディアは全員が団結して反対する「邪悪な分断者」だと受け止められたのだと思います。おそらく私は違っていて、PHPに導入しようとしている変更や機能はどのような分割も必要としないのでしょう。それが事実なら、本当におそろしいことです。私たちはこの道を進むと、それを見ることになるでしょう。現段階でそのレベルのエネルギーをつぎこむことは明らかに早いです。
• ですが、私たちが直面しようとしている現実が明らかになったとき、それを探求することには間違いなく意味があります。

このスレッドではこれ以上は返信しません。ただし個人的なメッセージには喜んで応えます。

Zeev本人がこう言ってるので、すくなくともPHP 8.0(2020年12月)に向けたP++が導入されることはないでしょう。コミュニティとしては対立構造が浮き彫りになったことを認めながら、言語分割ではないベターな妥協点を見付けていくことになるでしょう。