Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88802 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 51392 invoked from network); 14 Oct 2015 23:30:40 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Oct 2015 23:30:40 -0000 X-Host-Fingerprint: 2.123.167.169 unknown Received: from [2.123.167.169] ([2.123.167.169:22412] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 26/08-33697-F95EE165 for ; Wed, 14 Oct 2015 19:30:39 -0400 Message-ID: <26.08.33697.F95EE165@pb1.pair.com> To: internals@lists.php.net References: <0A.C2.33697.6AECE165@pb1.pair.com> <561ED07E.4060809@gmail.com> <561EE2F1.7050305@garfieldtech.com> Date: Thu, 15 Oct 2015 00:30:34 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:41.0) Gecko/20100101 Firefox/41.0 SeaMonkey/2.38 MIME-Version: 1.0 In-Reply-To: <561EE2F1.7050305@garfieldtech.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 2.123.167.169 Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Void_Return_Type_=28v0.2=2c_re=c3=b6p?= =?UTF-8?Q?ening=29?= From: ajf@ajf.me (Andrea Faulds) Hi Larry, Larry Garfield wrote: > The tricky part here is that saying a function does not return is not > something PHP currently does: > > https://3v4l.org/HtAuC > > No return implicitly returns NULL, which you can assign to a variable > if, for some strange reason, you were so inclined. So this would be > more than "just" a syntactic documentation feature. Which has been pointed out. > Which I believe gives the following options: > > 1) Change the language behavior such that > > function foo() : void { ...} > $a = foo(); > > Is a syntax error (because there really was nothing returned to assign), > rather than resulting in $a having a value of NULL. As the RFC notes, this breaks things, and is inconsistent with how PHP already does things. > 2) Use null as a "type" (which I agree feels weird just saying it), such > that: > > function foo() : null { ...} > $a = foo(); > > and > > function foo() { ...} > $a = foo(); > > are identical. The former would impact the contents of the function > (eg, a non-empty return would be a parse error), but the external result > is the same ($a == NULL). This would be strange. The manual doesn't say `null`, and I can't think of any language which uses `null` as the return type in this situation, even when they have the same implicit-null-return behaviour that PHP has (see the email you're replying to). Also, wouldn't you expect this to behave like existing type hints, and let you return a null value from any source? But that's not what you would actually want, right? Thanks. -- Andrea Faulds http://ajf.me/