Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88818
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <7C.D4.23021.A07CF165@pb1.pair.com>
To: internals@lists.php.net
References: <0A.C2.33697.6AECE165@pb1.pair.com> <561ED07E.4060809@gmail.com>
 <CAFMT4NpETZp5p+yVmUNZHjKamkA1niapAs10fCzd-6O0jHk4nA@mail.gmail.com>
 <C6.F6.33697.39EDE165@pb1.pair.com> <561EE2F1.7050305@garfieldtech.com>
 <26.08.33697.F95EE165@pb1.pair.com> <561EFE73.3060602@garfieldtech.com>
Date: Thu, 15 Oct 2015 16:32:24 +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: <561EFE73.3060602@garfieldtech.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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:
> On 10/14/2015 06:30 PM, Andrea Faulds wrote:
>> 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.
>
> Well, that depends on the intent here.  In practice, is the intent to
> add a "no return at all" type of function (ie, $a = foo() is a syntax
> error now where it was not before), or to make it explicit that the only
> legal return is null (even if implicitly that means having a non-early
> return statement is pointless)?  Those are the two options.  That may or
> may not dictate the keyword that gets used.

It would seem ideal to have "true" void functions which can't be used as 
expressions, i.e. producing an error if you try to use them like in your 
example. But they'd cause a backwards-compatibility headache, and I'm 
not sure they're a good idea anyway. Every function call being an 
expression is pretty handy. You can safely capture the return value of a 
callback and pass it along, for instance.

In a sense, what this RFC offers might be called a compromise. It 
enforces the rules of `void` within the function, but at the end of the 
day the caller still gets a null out of it since that's what PHP's 
always done.

> It definitely sounds like you're favoring the second (as that's what the
> RFC says).  Which may or make not make "void" an odd keyword to choose
> when what's actually happening is NULL getting returned.  Is NULL a
> void?  (There's a deep philosophical question...)

It's an interesting question. There's some precedent for using `void` in 
this way even though the functions aren't "truly" void. I mostly like 
`void` because it's the customary keyword to use, though. Everyone knows 
what a 'void function' is.

> As I said, I don't have a strong opinion on the subject yet.  I'm just
> trying to distil the discussion down to as small a question as possible.
> :-)

I appreciate your efforts. I have a tendency to be a bit verbose in my 
writing, so providing clarity is helpful. :)

Thanks.
-- 
Andrea Faulds
http://ajf.me/