Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104454
To: internals@lists.php.net
References: <CAOv67gv0vg=C8hMOiqL_+N=FrD=y1U3XP3v1ocbf+PHO0Ru+Ow@mail.gmail.com>
Message-ID: <5f06eda3-5431-5469-badf-317e4eddd2fa@gmail.com>
Date: Sun, 17 Feb 2019 16:36:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.0
MIME-Version: 1.0
In-Reply-To: <CAOv67gv0vg=C8hMOiqL_+N=FrD=y1U3XP3v1ocbf+PHO0Ru+Ow@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV][RFC] Allow void return type variance
From: rowan.collins@gmail.com (Rowan Collins)

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-variance


I 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]