The "Return Type Declarations" RFC explains the reasoning in the section "Disallowing NULL on Return Types"[1]. Apparantly, this info is missing in the  manual proper.

[1] https://wiki.php.net/rfc/return_types#disallowing_null_on_return_types

well, and both, not allow NULL in return types as well as for params makes the whole typing for int practically unuseable - the same way as float allows int because it's a subset in non-strict-mode NULL should be casted to 0 (int) or false (bool) because otherwise you have to still use (int)$foo and (bool)$foo in your whole code and instead save overhead because the implicit casting you add overhead by the enforced casting of return values in userland code

luckily at least that below is no longer true because in PHP7 *you must* use int and not integer

// Int is not a valid type declaration
function answer(): int {
    return 42;
}
answer();

Catchable fatal error: Return value of answer() must be an instance of int, integer returned in %s on line %d

It doesn't make sense to discuss the behavior *here*, because changing it would require an RFC anyway, see <https://wiki.php.net/rfc/howto>.

> // Int is not a valid type declaration

But it is, see <https://3v4l.org/Qoic7>.

>> // Int is not a valid type declaration
> But it is, see <https://3v4l.org/Qoic7>

what do you see there? what i said "luckily no longer true"
frankly i quoted the RFC you linked to!

change it to integer and you get
Fatal error: Uncaught TypeError: Return value of answer() must be an instance of integer, integer returned

which means you must use "int" and not "integer" and playing around with function typehints shows clearly a incosistence in the RFC's and the real implementations anyways

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

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

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

- with default or declare(strict_types=1);
+ with default or declare(strict_types=0);

> 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. :-)