一、总结
该rfc建议添加4种新的标量类型声明：int，float，string和bool，这些类型声明将会和php原来的机制保持一致的用法。rfc更推荐给每一个php文件，添加一句新的可选指令（declare(strict_type=1);），让同一个php文件内的全部函数调用和语句返回，都有一个“严格约束”的标量类型声明检查。此外，在开启严格类型约束后，调用拓展或者php内置函数在参数解析失败，将产生一个e_recoverable_error级错误。通过这两个特性，rfc希望编写php能够变得更准确和文档化。
推荐教程：《PHP教程》
二、细节
标量类型声明：
没有添加新的保留字。int、float、string和bool会被识别为类型声明，同时禁止用作class/interface/trait等的命名。新的用户标量类型声明，通过内部的Fast Parameter Parsing API实现。
strict_types/declare()指令
立即学习“PHP免费学习笔记（深入）”；
默认情况下，所有的PHP文件都处于弱类型校验模式。新的declare指令，通过指定strict_types的值（1或者0），1表示严格类型校验模式，作用于函数调用和返回语句；0表示弱类型校验模式。
declare(strict_types=1)必须是文件的第一个语句。如果这个语句出现在文件的其他地方，将会产生一个编译错误，块模式是被明确禁止的。
类似于encoding指令，但不同于ticks指令，strict_types指令只影响指定使用的文件，不会影响被它包含（通过include等方式）进来的其他文件。该指令在运行时编译，不能修改。它的运作方式，是在opcode中设置一个标志位，让函数调用和返回类型检查符合类型约束。
参数类型声明
该指令影响全部的函数调用，例如（严格校验模式）：
对比（弱校验模式）
返回类型声明：
指令会影响同一个文件下的所有函数的返回类型. 例如（严格校验模式）:
弱类型校验行为：
一个弱类型校验的函数调用，和PHP7之前的PHP版本是一致的（包括拓展和PHP内置函数）。通常，弱类型校验规则对于新的标量类型声明的处理是相同的，但是，唯一的例外是对NULL的处理。为了和我们现有类、调用、数组的类型声明保持一致，NULL不是默认的，除非它作为一个参数并且被显式赋值为NULL。
为了给不熟悉PHP现有的弱标量参数类型规则的读者，提供简短的总结。表格展示不同类型能够接受和转换的标量类型声明，NULL、arrays和resource不能接受标量类型声明，因此不在表格内。
*只有范围在PHP_INT_MIN和PHP_INT_MAX内的non-NaN float类型可以接受。（PHP7新增，可查看ZPP Failure on Overflow RFC）
?Non-numeric型字符串不被接受，Numeric型字符串跟随字符串的，也可以被接受，但是会产生一个notice。?仅当它有__toString方法时可以。
严格类型校验行为：
严格的类型校验调用拓展或者PHP内置函数，会改变zend_parse_parameters的行为。特别注意，失败的时候，它会产生E_RECOVERABLE_ERROR而不是E_WARNING。它遵循严格类型校验规则，而不是传统的弱类型校验规则。严格类型校验规则是非常直接的：只有当类型和指定类型声明匹配，它才会接受，否则拒绝。
有一个例外的是，宽泛类型转换是允许int变为float的，也就是说参数如果被声明为float类型，但是它仍然可以接受int参数。
在这种场景下，我们传递一个int参数给到定义接受float的函数，这个参数将会被转换为float。除此之外的转换，都是不被允许的。
三、例子：
让我们创建一个函数，让2个数相加。
add.php
如果在分开的文件，我们可以调用add函数通过弱类型的方式
默认情况下，弱类型声明允许使用转换，传递进去的值会被转换。
但是，通过可选择指令declare开启严格类型校验后，在这个场景下，相同的调用将会失败。
指令影响同一个文件下的所有函数调用，不管这个被调函数是否在这个文件内定义的，都会采用严格类型校验模式。
标量类型声明也可以用于返回值的严格类型校验：
在弱类型模式下，float被转为integer。
四、背景和理论基础
历史
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）它允许严格类型和弱类型代码，在一个单一的代码库中无缝集成。
