Hi Michael,
The case of null is a little special.
As a type hint, we need it for return and union types only.
Considering union types, they were clearly left out of scope for 7.0 and I
personally won't propose pre-defined union types before the general case for
unions is designed. Conversion to union type, in particular, is complex, and
requires more thinking and discussion.
> Hold on, usually, type checking functions don't identify NULL as scalar.
I don't understand your point as parameter parsing currently accepts null as
scalar (converting to 0 or empty string).
If you mean is_xxx() functions, that's irrelevant because these functions,
except a few ones like is_numeric(), are just based on zval type and don't
accept *any* conversion.
I profit of this mail to propose :
- disabling accepting null as number, string, or bool (it is already rejected
for other types).
- also disabling implicit conversions of any type to null (a function declared
to return int couldn't return null without adding 'null' to its return type,
which requires union types).
A consequence is that, until we have union types, a function returning int or
null, for instance, cannot have an explicit type.
It is important because disabling implicit conversion to null allows to trap
functions ending without an explicit 'return' statement, while supposed to
return a value.
Example:
Function foo(int $a): int
{
If ($a > 0) return $a;
} <- Error : received null while expecting int
While this will be OK when union types exist :
Function foo(int $a): int|null
{
If ($a > 0) return $a;
}
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
