为什么 php 允许它知道它不允许的无效返回类型声明？

Question

据我所知，php 有能力防止在它知道有问题的地方声明返回类型。

class Foo {
    public function __clone(): Baz {
        return new Baz;
    }
}

class Baz {

}

$foo = new Foo;
$newFoo = clone $foo;

这会产生一个Fatal error: Clone method Foo::__clone() cannot declare a return type，这是非常合理的。

那么为什么php会允许这样的事情：

class Foo {
    public function __toString(): float {
        return "WAT!?!";
    }
}

echo new Foo;

这会导致

致命错误：未捕获的类型错误：Foo::__toString() 的返回值必须是浮点类型，返回字符串

这没有意义，因为你要尝试返回一个浮点数：

致命错误：未捕获错误：方法 Foo::__toString() 必须返回字符串值

对于 php 来说，阻止这些方法的声明返回类型而不是给出那些可疑的错误不是更有意义吗？如果不是，那么内部背后的根本原因是什么？是否有一些机械障碍可以阻止 php 在 clone 之类的情况下执行此操作？

Answer 1

TL;DR：支持魔术方法的类型推断会破坏向后兼容性。

示例：这段代码输出了什么？

$foo = new Foo;
$bar = $foo->__construct();
echo get_class($bar);

如果你说Foo，那你就错了：它是Bar。

---

PHP 的返回类型处理经历了漫长而复杂的演变。

• 在 PHP 7.0 之前，返回类型提示是一个解析错误。
• 在 PHP 7.0 中，我们得到了具有非常简单规则的返回类型声明 (RFC)，在可能是有史以来最具争议的内部辩论之后，我们得到了严格类型 (RFC)。
• 在 PHP 7.4 之前，PHP 伴随着一些奇怪的协方差和反方差，在那里我们对其中的许多进行了排序 (RFC)。

今天的行为反映了这种有机增长，疣和所有。

您指出__clone() 行为是合理的，然后将其与明显不合理的__toString() 行为进行比较。在对类型推断的任何理性预期下，我质疑它们中的任何一个都不是明智的。

这是__clone 引擎代码：

6642     if (ce->clone) {                                                          
6643         if (ce->clone->common.fn_flags & ZEND_ACC_STATIC) {                   
6644             zend_error_noreturn(E_COMPILE_ERROR, "Clone method %s::%s() cannot be static",
6645                 ZSTR_VAL(ce->name), ZSTR_VAL(ce->clone->common.function_name));
6646         } else if (ce->clone->common.fn_flags & ZEND_ACC_HAS_RETURN_TYPE) {   
6647             zend_error_noreturn(E_COMPILE_ERROR,                              
6648                 "Clone method %s::%s() cannot declare a return type",         
6649                 ZSTR_VAL(ce->name), ZSTR_VAL(ce->clone->common.function_name));
6650         }                                                                     
6651     }                                                                         

请注意该措辞（强调我的）：

克隆方法 ... 不能声明返回类型

__clone() 给你一个错误不是因为类型不同，而是因为你完全给出了一个类型！这也是compile error：

class Foo {
    public function __clone(): Foo {
        return new Foo;
    }
}

“为什么？！”，你尖叫。

我认为有两个原因：

1. Internals 需要高标准的向后兼容性维护。
2. 增量改进进展缓慢，每次改进都建立在早期改进的基础上。

让我们谈谈#1。考虑this code，它一直有效到 PHP 4.0：

<?php
class Amount {
    var $amount;
}
class TaxedAmount extends Amount {
    var $rate;
    function __toString() {
        return $this->amount * $this->rate;
    }
}
$item = new TaxedAmount;
$item->amount = 242.0;
$item->rate = 1.13;
echo "You owe me $" . $item->__toString() . " for this answer.";

一些可怜的灵魂以完全合理的方式使用__toString作为他们自己的方法。现在保留其行为是重中之重，因此我们不能对破坏此代码的引擎进行更改。这就是 strict_types 声明的动机：允许对解析器行为进行选择性更改，以便在继续添加新行为的同时保持旧行为。

您可能会问：为什么我们不在declare(strict_types=1) 开启时解决这个问题？好吧，因为this code 在严格类型模式下也完全有效！它甚至使sense：

<?php declare(strict_types=1);

class Amount {
    var $amount;
}
class TaxedAmount extends Amount {
    var $rate;
    function __toString(): float {
        return $this->amount * $this->rate;
    }
}
$item = new TaxedAmount;
$item->amount = 242.0;
$item->rate = 1.13;
echo "You owe me $" . $item->__toString() . " for this answer.";

这段代码没有异味。这是有效的 PHP 代码。如果该方法被称为getTotalAmount 而不是__toString，那么没有人会睁一只眼闭一只眼。唯一奇怪的部分：方法名称是“保留的”。

因此引擎既不能 (a) 强制 __toString 返回字符串类型，也不能 (b) 阻止您设置自己的返回类型。因为这样做会违反向后兼容性。

然而，我们可以做的是实现一个新的肯定选择加入，它表示这些方法不能直接调用。一旦我们这样做了，我们就可以向它们添加类型推断。假设：

<?php declare(strict_magic=1);

class Person {
    function __construct(): Person {
    }
    function __toString(): string {
    }
    // ... other magic
}

(new Person)->__construct(); // Fatal Error: cannot call magic method on strict_magic object

这是第 2 点：一旦我们有了保护向后兼容性的方法，我们就可以添加一种方法来强制魔法方法的类型。

总之，__construct、__destruct、__clone、__toString 等都是 (a) 引擎在某些情况下调用的函数，它可以合理地推断出类型和 (b) 函数 -从历史上看 - 可以以违反（1）中合理类型推断的方式直接调用。

这就是 PR 4117 修复 Bug #69718 被阻止的原因。

打破这种僵局的唯一方法是：开发人员选择承诺不能直接调用这些方法。这样做可以释放引擎来强制执行严格的类型推断规则。