一、總結

該RFC建議添加4種新的標量類型聲明：int，float，string和bool，這些類型聲明將會和PHP原來的機制保持一致的用法。RFC更推薦給每一個PHP文件，添加一句新的可選指令（declare(strict_type=1);），讓同一個PHP文件內的全部函數調用和語句返回，都有一個“嚴格約束”的標量類型聲明檢查。此外，在開啟嚴格類型約束后，調用拓展或者PHP內置函數在參數解析失敗，將產生一個E_RECOVERABLE_ERROR級錯誤。通過這兩個特性，RFC希望編寫PHP能夠變得更準確和文檔化。

二、細節

標量類型聲明：

沒有添加新的保留字。int、float、string和bool會被識別為類型聲明，同時禁止用作html' target='_blank'>class/interface/trait等的命名。新的用戶標量類型聲明，通過內部的Fast Parameter Parsing API實現。

strict_types/declare()指令

默認情況下，所有的PHP文件都處于弱類型校驗模式。新的declare指令，通過指定strict_types的值（1或者0），1表示嚴格類型校驗模式，作用于函數調用和返回語句；0表示弱類型校驗模式。

declare(strict_types=1)必須是文件的第一個語句。如果這個語句出現在文件的其他地方，將會產生一個編譯錯誤，塊模式是被明確禁止的。

類似于encoding指令，但不同于ticks指令，strict_types指令只影響指定使用的文件，不會影響被它包含（通過include等方式）進來的其他文件。該指令在運行時編譯，不能修改。它的運作方式，是在opcode中設置一個標志位，讓函數調用和返回類型檢查符合類型約束。

參數類型聲明

該指令影響全部的函數調用，例如（嚴格校驗模式）：

<?php  declare(strict_types=1);  foo(); // strictly type-checked functioncall function foobar() {      foo(); // strictly type-checked function call}  class baz {         function foobar() {                 foo(); // strictly type-checked function call       }}

對比（弱校驗模式）

<?phpfoo(); // weakly type-checked function callfunction foobar() {   foo(); // weakly type-checked function call}class baz {function foobar() {foo(); // weakly type-checked function call}}?>

返回類型聲明：

指令會影響同一個文件下的所有函數的返回類型. 例如（嚴格校驗模式）:

<?phpdeclare(strict_types=1);function foobar(): int {return 1.0; // strictly type-checked return} class baz {function foobar(): int {return 1.0; // strictly type-checked return}}?>

<?phpfunction foobar(): int {return 1.0; // weakly type-checked return} class baz {function foobar(): int {return 1.0; // weakly type-checked return}}?>

弱類型校驗行為：

一個弱類型校驗的函數調用，和PHP7之前的PHP版本是一致的（包括拓展和PHP內置函數）。通常，弱類型校驗規則對于新的標量類型聲明的處理是相同的，但是，唯一的例外是對NULL的處理。為了和我們現有類、調用、數組的類型聲明保持一致，NULL不是默認的，除非它作為一個參數并且被顯式賦值為NULL。

為了給不熟悉PHP現有的弱標量參數類型規則的讀者，提供簡短的總結。表格展示不同類型能夠接受和轉換的標量類型聲明，NULL、arrays和resource不能接受標量類型聲明，因此不在表格內。

*只有范圍在PHP_INT_MIN和PHP_INT_MAX內的non-NaNfloat類型可以接受。（PHP7新增，可查看ZPP Failure on Overflow RFC）

?Non-numeric型字符串不被接受，Numeric型字符串跟隨字符串的，也可以被接受，但是會產生一個notice。

?僅當它有toString方法時可以。

嚴格類型校驗行為：

嚴格的類型校驗調用拓展或者PHP內置函數，會改變zend_parse_parameters的行為。特別注意，失敗的時候，它會產生E_RECOVERABLE_ERROR而不是E_WARNING。它遵循嚴格類型校驗規則，而不是傳統的弱類型校驗規則。嚴格類型校驗規則是非常直接的：只有當類型和指定類型聲明匹配，它才會接受，否則拒絕。

有一個例外的是，寬泛類型轉換是允許int變為float的，也就是說參數如果被聲明為float類型，但是它仍然可以接受int參數。

<?phpdeclare(strict_types=1);function add(float $a, float $b): float {return $a + $b;} add(1, 2); // float(3)?>

在這種場景下，我們傳遞一個int參數給到定義接受float的函數，這個參數將會被轉換為float。除此之外的轉換，都是不被允許的。

三、例子：

讓我們創建一個函數，讓2個數相加。

add.php<?phpfunction add(int $a, int $b): int {return $a + $b;}?>

如果在分開的文件，我們可以調用add函數通過弱類型的方式

<?phprequire "add.php";var_dump(add(1,2)); // int(3)// floats are truncated by defaultvar_dump(add(1.5,2.5)); // int(3)//strings convert if there's a number partvar_dump(add("1","2")); // int(3)?>

默認情況下，弱類型聲明允許使用轉換，傳遞進去的值會被轉換。

<?phprequire "add.php";var_dump(add("1foo", "2")); // int(3)// Notice: A non well formed numeric value encountered

但是，通過可選擇指令declare開啟嚴格類型校驗后，在這個場景下，相同的調用將會失敗。

<?phpdeclare(strict_types=1);require "add.php";var_dump(add(1,2)); // int(3)var_dump(add(1.5,2.5)); // int(3)// Catchable fatal error: Argument 1 passed to add() must be of the type integer, float given

指令影響同一個文件下的所有函數調用，不管這個被調函數是否在這個文件內定義的，都會采用嚴格類型校驗模式。

<?php declare(strict_types=1); $foo = substr(52,1);// Catchable fatal error: substr() expects parameter 1 to be string, integer given

標量類型聲明也可以用于返回值的嚴格類型校驗：

<?phpfunction foobar(): int {return 1.0;}var_dump(foobar());// int(1)

在弱類型模式下，float被轉為integer。

<?phpdeclare(strict_types=1);function foobar(): int {return 1.0;}var_dump(foobar());//Catchable fatal error: Return value of foobar() must be of the type integer,float returned

四、背景和理論基礎

歷史

PHP從PHP5.0開始已經有對支持class和interface參數類型聲明，PHP5.1支持array以及PHP5.4支持callable。這些類型聲明讓PHP在執行的時候傳入正確的參數，讓函數簽名具有更多的信息。

先前曾經想添加標量類型聲明，例如Scalar Type Hints with Casts RFC，因為各種原因失敗了：

（1）類型轉換和校驗機制，對于拓展和PHP內置函數不匹配。

（2）它遵循一個弱類型方法。

（3）它的“嚴格”弱類型修改嘗試，既沒有滿足嚴格類型的粉絲期望，也沒有滿足弱類型的粉絲。

這個RFC嘗試解決全部問題。

弱類型和強類型

在現代編程語言的實際應用中，有三種主要的方法去檢查參數和返回值的類型：

（1）全嚴格類型檢查（也就是不會有類型轉換發生）。例如F#、GO、Haskell、Rust和Facebook的Hack的用法。

（2）廣泛原始類型檢查（“安全”的類型轉換會發生）。例如Java、D和Pascal。他們允許廣泛原始類型轉換（隱式轉換），也就是說，一個8-bit的integer可以根據函數參數需要，被隱形轉換為一個16-bit的integer，而且int也可以被轉換為float的浮點數。其他類型的隱式轉換則不被允許。

（3）弱類型檢查（允許所有類型轉換，可能會引起警告），它被有限制地使用在C、C#、C++和Visual Basic中。它們嘗試盡可能“不失敗”，完成一次轉換。

PHP在zend_parse_parameters的標量內部處理機制是采用了弱類型模式。PHP的對象處理機制采用了廣泛類型檢查方式，并不追求精確匹配和轉換。

每個方法各有其優缺點。

這個提案中，默認采用弱類型校驗機制，同時追加一個開關，允許轉換為廣泛類型校驗機制（也就是嚴格類型校驗機制）。

為什么兩者都支持？

目前為止，大部分的標量類型聲明的擁護者都要求同時支持嚴格類型校驗和弱類型校驗，并非僅僅支持其中一種。這份RFC，使得弱類型校驗為默認行為，同時，添加一個可選的指令來使用嚴格類型校驗（同一個文件中）。在這個選擇的背后，有很多個原因。

PHP社區很大一部分人看起來很喜歡全靜態類型。但是，添加嚴格類型校驗的標量類型聲明將會引起一些問題：

（1）引起明顯的不一致性：拓展和PHP內置函數對標量類型參數使用弱類型校驗，但是，用戶的PHP函數將會使用嚴格類型校驗。

（2）相當一部分人更喜歡弱類型校驗，并不贊同這個提案，他們可能會阻止它的實施。

（3）已經存在的代碼使用了PHP的弱類型，它會受到影響。如果要求函數添加標量類型聲明到參數上，對于現有的代碼庫，這將大大增加復雜性，特別是對于庫文件。

這里仍然有相當于一部分人是喜歡弱類型校驗的，但是，添加嚴格類型校驗聲明和添加弱類型校驗聲明都會引起一些問題：

（1）大部分傾向于嚴格類型校驗的人將不會喜歡這個提案，然后阻止它的實施。

（2）限制靜態解析的機會。（可能是說，優化的機會）

（3）它會隱藏一些在類型自動轉換中數據丟失的bug。

第三種方案被提出來了，就是添加區分弱類型和嚴格類型聲明的語法。它也會帶來一些問題：

（1）不喜歡弱類型和嚴格類型校驗的人，會被強迫分別處理被定義為嚴格類型或者弱類型校驗的庫。

（2）像添加嚴格聲明一樣，這個也將和原來弱類型實現的拓展和PHP內置函數無法保持一致。

為了解決這三種方案帶來的問題，這個RFC提出了第四種方案：每個文件各自定義嚴格或者弱類型校驗。它帶來了以下好處：

（1）人們可以選擇適合他們的類型校驗，也就是說，這個方案希望同時滿足嚴格和弱類型校驗兩個陣營。

（2）API不會被強制適應某個類型聲明模式。

（3）因為文件默認使用弱類型校驗方案，已經存在的代碼庫，可以在不破壞代碼結構的情況下，添加標量類型聲明。也可以讓代碼庫逐步添加類型聲明，或者僅部分模塊添加。

（4）只需要一個單一語法，就可以定義標量類型聲明。

（5）更喜歡嚴格類型校驗的人，通常，不僅將這個特性使用在用戶定義的函數，同時也使用在拓展和PHP內置函數中。也就是說，PHP使用者會得到一個統一機制，而不會產生嚴格標量聲明的矛盾。

（6）在嚴格類型校驗模式下，拓展和PHP內置函數產生的類型校驗失敗的錯誤級別，和用戶自定函數產生的會保持一致，都是E_RECOVERABLE_ERROR。

（7）它允許嚴格類型和弱類型代碼，在一個單一的代碼庫中無縫集成。

以上就是詳解PHP7標量類型聲明RFC的示例代碼的詳細內容，更多請關注 其它相關文章！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。