投票で可決されました。導入決定を意味します。この提案は既存のタイプヒンティングの適用範囲をスカラー型にまで押し広げ、またスカラー型について弱い型検査と厳密な型検査の2つのモードを導入し、ファイル単位で2つを切り替えて使うことができるようにする、というものです。使うことはできなくなります。この記事ではスカラー型宣言がどのように使うものなのか、そもそもタイプヒンティングって何だっけという話、そしてスカラー型に対するタイプヒンティングがこれまでどのように議論されてきたものなのかや、今回の提案が可決に至るまでの経緯について簡単にまとめます。対象読者は以下のような人です。やはてブのコメントにてお伝えください。利用が任意である点は、従来のタイプヒンティングと変わりありません。いらなければタイプヒンティングを使わなくともよい弱いモードデフォルトで使われるのは弱い型検査です。関数定義での宣言と異なる型の値で呼び出す際、可能な場合は暗黙の型変換が行われ、それ以外は例外を投げます。NG暗黙の型変換は以下のようなルールで行われます。従来他の構文(算術演算子や条件式、組み込み関数の呼び出しなど)で行ってきたのと同等のものです。書くことで、そのファイル内での関数呼び出しの際に厳密モードでの型検査が行われるようになります*1。以下のように使います。ある基本型の拡大変換と同様に、厳密モードであっても暗黙的変換が許容されています。組み込み関数や拡張ライブラリ関数についても、同様に厳密な型検査を行うよう振る舞いが変わるということです。デフォルトではこれらの関数は弱い型検査のみを行います。型検査モードの適用範囲はファイル単位です。使われたファイル内での関数呼び出しにのみ、厳密な型検査が適用されます。呼び出される関数の定義がどちらのモードのファイルに書かれたかではなく、どちらのモードのファイルから呼び出されるかで、使われる型検査が変わることに注意してください。別途導入が決定された返り値の型宣言については少し特殊で、返り値の型にスカラー型を指定した場合の型検査には、その関数定義が書かれたファイルのモードが使われます。どのモードのファイルから呼ばれてもNG}引数に対するタイプヒンティングとのこの違いは、引数へ誤った型の値を渡すのは呼び出し側の問題である一方、誤った型の値を返すのは関数の実装側の問題であるということによります。おいて導入されたタイプヒンティングは、関数が引数としてとるべき値の型を、その関数定義において指定するものです。おいては実行時に指定された以外の型の値が関数へ渡された場合、例外を投げる、という機能です。コンパイル時にほぼ全ての実行パスについてチェックが可能な静的型付けの言語のものほど強力な仕組みではないかもしれませんが、関数へ本来あり得ない型の値が渡されるというような、単純なプログラム上のミスは早期に発見しやすくなります。指定できるようにと進化してきました。いった基本的な型(スカラー型)に対しては指定することができませんでした。「2つのモードを切り替えて使える」という話を聞いた人の反応は、おそらく以下の2つに分かれるのではないかと思います。どのようにして提案され、可決に至ったかの経緯について簡単にまとめます。頃にも様々な方式の提案が出されていました。これらはどれもコミュニティの十分な合意が得られず、実現には至りませんでした。持ち込んだ人)の記事で詳しくまとまっています。2012ここで抑えておくべきなのは、この機能に対する要望自体は以前から根強くあり、幾つかの方法が議論の中で挙げられていて、どれも長所短所があり、結局は何にも決まらなかったのだということ、しかし当時から行われてきたこれらの議論が、現在可決された提案に対してもある程度影響を与えているのだということです。型チェックを望む人は、おそらくその多くが他の静的型付け言語の経験者です。タイプヒンティングの方式についてそういった人々が最初に思い付くのは、他の言語で採用されているような比較的厳密な型検査となるでしょう。関数定義に書かれているのと違う型の値は渡せないようにしてほしいという、つまり、以下のようなコードに文字列や浮動小数点数を渡そうとするのはプログラマの間違いなので、ぜひともエラーを吐いてほしいという考え方です。$bar;}しかし、この考え方は単純で分かりやすそうに見えて、幾つか困った問題があります。型を前面に出さない動的言語です。暗黙的な型変換がことあるごとに行われ、ある値が文字列として扱われるか、それとも数値として扱われるか、ということが、使用される文脈に応じてコロコロ変わります。いう結果を返すのです。組み込み関数や拡張ライブラリの関数もまた、数値や文字列といった型の値について、その内容次第で扱い方を変えます。利用者にとって望ましいものなのでしょうか。厳密なタイプヒンティングは、おそらく既存コードに対して明示的なキャストの利用を助長しがちになります。オブジェクトからスカラー型へのキャストのような一部のケースをのぞいて、ほとんどの場合明示的なキャストに失敗しません。変換という形で成功します。このことがバグの温床となり、結局はタイプヒンティングの恩恵を台無しにしてしまうというのは、いかにも起こりそうな話です。組み込み関数や拡張ライブラリの関数にとっては、厳密な型検査を採用する場合、タイプヒンティングの導入とこれまでの(暗黙的な型変換を前提とした)インターフェースとの後方互換性を両立させることができず、双方を天秤にかけた上でどちらかを選ばねばならなくなります。プログラマは一定数以上存在します。弱い型付けの言語だからこそ、タイプヒンティングでは型の扱いを厳密にすることによってコードへ一定の縛りを与える、そうできるのが利点である、という考え方も、確かに否定しきれるものではありません。不都合な点を挙げた厳密方式のタイプヒンティングですが、例えばコードの静的解析のしやすさといった面では、次に述べる弱いタイプヒンティングよりも、厳密なタイプヒンティングの方に軍配が上がるといった話があります。いう言語の機能として馴染まない部分がある、となれば、次に考えるのはより緩いルールでの型検査です。他の部分、演算子や組み込み関数で行われるのと同じような方法で、関数呼び出し時に暗黙的な型変換がなされ、変換できない場合にのみ例外を投げる、という弱いタイプヒンティングであれば、言語内での一貫性は損なわれません。プログラマは、こちらのタイプヒンティングの導入によって十分に幸せに暮らせるようになりそうです。暗黙的な型変換により、たとえ弱いタイプヒンティングであっても、関数の実装者はその関数へ渡される値がどんな型を持つかについて、最低限の前提をもって開発することができるようになります。する厳密な型検査を求める人々のことはないがしろにすることになります。暗黙的な型変換で渡される値なんて見たくない、変な値が入ってくるのは間違いなくプログラムのミスなのでさっさと死んでほしい、例外投げてほしい、という考え方は、決して不思議なものではありません。2つの内のどちらがより合理的な選択であるかというのは、実際のところ難しい問題なのです。厳密なタイプヒンティングと弱いタイプヒンティング、2つのうちのどちらが良いものなのかはケースバイケースだったり好みの問題であるとして、ならばプログラマが必要に応じてどちらを使うか選べるようにすればよい、という考え方です。よって2014年12月に書かれ、当初は弱いタイプヒンティングのみを持つ提案でした。手を加えた形でのスカラータイプヒンティングの導入を目指していました。コミュニティでの議論と修正を重ねていくうちに、厳密路線と弱い路線のツギハギのような形になり、どちらの派閥にとっても魅力的ではないものとなってしまったことで、結局は棄てられることになりました。開発コミュニティの中で受け入れられた案でした。おいて、やや唐突に、この提案へ厳密なタイプヒンティングを用いるモードが追加されます。https://wiki.php.net/rfc/scalar_type_hints?rev=1421192225主として、「厳密な方を望む人が結構いるっぽいから」というのが追加の理由です。このやり方でモード切り替えによって2つの型検査の方法を同じ構文で持つことには、多くの利点があると主張しています。投げるという、一貫した挙動を後方互換性を崩さずに得られる議論の紛糾この改訂によって議論は紛糾します。ままでよかったじゃん!」というような意見が多数出ました。提案内容に近い発想のものでした。とっては不自然であることを訴え、またちょうどその話の中で、「利用が任意ならこの機能入れてもいいじゃろ?」という発想への反対意見も表明していたりします。投票フェーズへと進むこととなります。投票プロセスについて簡単に触れておきます。言語機能はコミュニティにもとづいて決定され、提案が受理されるか否かは投票によって決まります。記述にもとづいています。おいて告知されることで、正式に提案が発行されたことになります。十分な議論を行うため、告知から投票へ進むまでには最低でも2週間を空けることが要求されています。投票権を持つ者は以下の二通りに分かれます。同等の影響力を持ちます。生まれた背景の1つであるとも言えます。厳密な型検査を求める派閥と弱い型検査を求める派閥があるとすると、どちらに嫌われる提案であっても、決して投票フェーズで生き残ることはできないということです。ない非常に多くの投票が寄せられました。開発コミュニティからの引退を宣言します。投票半ばにして提案者自身が取り下げることとなってしまいました。開発は時間を食い過ぎる」というのが本人の挙げた理由です。頑張りすぎて疲れてしまった感じなのでしょうか。v0.4」というものでした。Declarations』として公開しました。