Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88821
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <561FCD9F.10104@gmail.com>
References: <0A.C2.33697.6AECE165@pb1.pair.com>
	<561F7D17.5050306@gmail.com>
	<B0.D4.23021.207CF165@pb1.pair.com>
	<561FCD9F.10104@gmail.com>
Date: Thu, 15 Oct 2015 13:14:15 -0300
Message-ID: <CAJGzsHpyEzmmFpzcHBzJdkeEvZKaQiJngeCUOUA3T-cUX_a_Wg@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a11412efc73b815052226f8c2
Subject: =?UTF-8?B?UmU6IFtQSFAtREVWXSBbUkZDXSBWb2lkIFJldHVybiBUeXBlICh2MC4yLCByZcO2cGVuaQ==?=
	=?UTF-8?B?bmcp?=
From: pedronaroga@gmail.com (Pedro Cordeiro)

--001a11412efc73b815052226f8c2
Content-Type: text/plain; charset=UTF-8

I've been thinking about what PHP should do when accessing the return value
of a `void` function, and so far, I think the consistent thing should be to
get NULL, while throwing an E_NOTICE.

$a = $b; //$b wasn't initiated.

This does the same thing. I tried accessing what was supposed to be
'nothing' ($b), and got NULL with an E_NOTICE being thrown.

function myFunc() : void { ... }
$a = myFunc();

I see no reason why this should silently assign NULL to $a, *specially* with
"return null;" being explicitly forbidden.

My point is: we already use an implicit NULL return on functions with
missing return values (or with "return ;"), but now we're explicitly
prohibiting even a NULL return. The behaviour should be consistent (NULL
should be accessed, as for all undefined things), with an E_NOTICE.

function myFunc() { return ; }
$a = myFunc();

Should assign NULL to $a and *not* throw an E_NOTICE (this is the current
status), because a return type was not forbidden with the keyword 'void'.

2015-10-15 13:00 GMT-03:00 Rowan Collins <rowan.collins@gmail.com>:

> Andrea Faulds wrote on 15/10/2015 16:32:
>
>> Hmm, this is an interesting case you've pointed out. Being able to do
>> `return some_other_void_function();` is something I've desired in other
>> languages.
>>
>> But what if that void function you're calling later adds a return value?
>> Now the calling function is returning a value other than null, violating
>> its type hint and producing a runtime error.
>>
>
> Well, fundamentally, this is true of anything short of full type-checking.
> The type safety below is self-evident:
>
> function foo(): int { return 42; }
> function wrapped_foo(): int { return foo(); }
>
> But foo() could later be changed to this:
>
> function foo(): string { return 'The Answer'; }
>
> The wrapped_foo() typehint is now broken. That's not really any different
> from foo() starting off as void/returns-null and adding a return value.
>
> In both cases, a static analyser could detect the discrepancy, but the
> Zend Engine will not, until the function is executed.
>
>
> It's a shame there's no "tail call this other function and discard its
>> result" construct.
>>
>
> Yeah, I guess what you really want is for a void function to be able to
> "goto foo();"
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a11412efc73b815052226f8c2--