Doc #73717 [Ver->Csd]: return-types with NULL not handeled properly

Edit report at https://bugs.php.net/bug.php?id=73717&edit=1 ID: 73717 Updated by: girgias@php.net Reported by: spam2 at rhsoft dot net Summary: return-types with NULL not handeled properly -Status: Verified +Status: Closed Type: Documentation Problem Package: Scripting Engine problem -PHP Version: 7.0.14 +PHP Version: 7.0 -Assigned To: +Assigned To: girgias Block user comment: N Private report: N New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. Nullable return types have been added as of PHP 7.1 https://secure.php.net/manual/en/functions.returning-values.php#functions.returning-values.type-declaration Previous Comments: ------------------------------------------------------------------------ [2016-12-17 15:06:53] cmb@php.net > PHP 5.6 seems to behave like PHP 7.0 with strict mode enabled > instead of doing any casting, maybe i just was confused with > things like below and gave up > > "must be an instance of integer, integer returned" is serious > bullshit - really! Patches are welcome. :-) ------------------------------------------------------------------------ [2016-12-12 23:26:28] spam2 at rhsoft dot net - with default or declare(strict_types=1); + with default or declare(strict_types=0); ------------------------------------------------------------------------ [2016-12-12 23:22:22] spam2 at rhsoft dot net to make it short and clear: with declare(strict_types=1); throwing fatal errors is fine in case of NULL with default or declare(strict_types=1); it makes a lot of new language features useless at all ------------------------------------------------------------------------ [2016-12-12 23:19:34] spam2 at rhsoft dot net well try the behavior of types in function params with PHP 5.6 and 7.0 - it was enough while starting palying around that i wrote a internal list mail that our software from now on requires PHP 7.0 unconditional PHP 5.6 seems to behave like PHP 7.0 with strict mode enabled instead of doing any casting, maybe i just was confused with things like below and gave up "must be an instance of integer, integer returned" is serious bullshit - really! return/parameter casting with disabled strict mode when NULL ends in a fatal error instead cast to false/0/'' for scalar types at the end makes the features completly unusable and non-helpful because you gain nothing when you have to cast manually *and* add engine overhead instead get rid of userland casting, burden it to the engine and hope that new versions of PHP/ZendEngine/opcache and even JIT may bring a performance benefit by handle it in C code ------------------------------------------------------------------------ [2016-12-12 22:58:54] cmb@php.net > frankly i quoted the RFC you linked to! Ah, I see. Indeed, the *example* with the integer type declaration has been superseded by the "Scalar Type Declarations" RFC[1], which introduced the int type declaration. Note that both RFCs had partially been authored at the same time. > […] and playing around with function typehints shows clearly a incosistence in the > RFC's and the real implementations anyways On an, admittedly, quick glance I haven't been able to find further inconsistencies. Could you please point them out? [1] <https://wiki.php.net/rfc/scalar_type_hints_v5> ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=73717 -- Edit this bug report at https://bugs.php.net/bug.php?id=73717&edit=1