Re: [RFC] Allow void return type variance
| From: | Rowan Collins | Date: | Sun, 17 Feb 2019 16:36:48 +0000 |
| Subject: | Re: [RFC] Allow void return type variance | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-104454@lists.php.net to get a copy of this message | ||
On 04/02/2019 03:22, Wes wrote:
Recent events convinced me to write this RFC :P Please have a read here https://wiki.php.net/rfc/allow-void-varianceI was thinking about this this afternoon, and I think the current behaviour is actually correct, and this constraint should stay invariant. My reasoning is that ": void" isn't actually a *type constraint* - there is no "void type" to apply the rules of covariance and contravariance to. It's tempting to place it on a par with ": null", but a void function evaluates to null only for the same reason an unset variable does: because the runtime has to give you *something*. Instead, ": void" in PHP represents a *behavioural constraint* on the function - it declares that within this function, anything of the form "return $value" is to be treated as an error. In other languages, the same constraint might be enforced by declaring the routine as a "procedure" rather than a "function". As such, it is more appropriate to compare "void vs non-void" to "static vs non-static", which is an invariant constraint - you can't over-ride a static method with a non-static one, or vice versa. (Incidentally, the RFC mentions TypeScript as precedent; there, "void" apparently *is* a type, not just a keyword in function signatures: https://www.typescriptlang.org/docs/handbook/basic-types.html) Regards, -- Rowan Collins [IMSoP]