Re: [RFC] Void Return Type (v0.2, reöpeni ng)

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 > >