Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:88799 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 46319 invoked from network); 14 Oct 2015 23:00:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Oct 2015 23:00:37 -0000 X-Host-Fingerprint: 2.123.167.169 unknown Received: from [2.123.167.169] ([2.123.167.169:28308] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/F6-33697-39EDE165 for ; Wed, 14 Oct 2015 19:00:36 -0400 Message-ID: To: internals@lists.php.net References: <0A.C2.33697.6AECE165@pb1.pair.com> <561ED07E.4060809@gmail.com> Date: Thu, 15 Oct 2015 00:00:31 +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: 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 Levi, Levi Morrison wrote: > On Wed, Oct 14, 2015 at 4:00 PM, Stanislav Malyshev wrote: >> Hi! >> >>> I'm reviving my Void Return Type RFC, this time for PHP 7.1: >>> >>> https://wiki.php.net/rfc/void_return_type >>> >>> Please read it and tell me your thoughts! >> >> I still see no point in this, as every PHP function actually returns >> something (at least null). So this type would not actually be right and >> would not reflect what actually is happening. > > I agree that `void` doesn't make sense given that we document that > `return;` will return null[1]. Both you and Stas have said this, but it's only true if we solely consider C-like languages. Other languages do different things. In the PHP manual, Hack, TypeScript, ActionScript, and most likely other languages (these are just off the top of my head), `void` functions do still have an implicit result. All of these languages would have had the choice to do what you're suggesting and use `null`, or its equivalent (`undefined` for TypeScript and ActionScript). They didn't. Why? If I had to guess, there's at least three reasons. For one, void is the word languages usually use for this. For another, `void` and `null` they mean different things. `void` signifies a function isn't returning anything. `null` signifies a function that *returns null*, regardless of where that null came from. `function foo(): null { return some_probably_null_returning_function(); }` should surely be legal with a `null` type hint, yet it's nonsensical code. Finally, making a function truly "return nothing", i.e. disallowing its use as an expression/rvalue, breaks some use cases, like passing along the result of a callback. PHP would neither be the first nor the last to be using `void` in this way. > If the union types RFC[2] passes it > makes sense to allow `Foo | null` which allows something of type `Foo` > or `null`. To me it makes sense that if you then remove `Foo` you are > left with `null`, not `void`. My personal recommendation because of > this would be to use `null` for the return type and instead of `void`. `null` would be a weird type, because it doesn't make sense as a parameter type, and as a return type, you don't really want to enforce returning null, you want to enforce not returning at all (see the example above). It feels like a poor man's substitute to me. Thanks. -- Andrea Faulds http://ajf.me/