>> Another concern I have is in regard to the future. I'm looking
>> forward to the possibility of specifying nullable types in a
>> future version of PHP (see Levi Morrison's "Declaring Nullable
>> Types" RFC: http://wiki.php.net/rfc/nullable_typehints). If the
>> nullable types RFC is accepted, it would be highly disconcerting
>> if scalar type annotations allowed null values regardless of
>> whether a nullable marker is specified.
>
> The current proposed behaviour could be changed. At the moment, if
> a scalar type hint is nullable, then it won’t cast NULL if it’s
> passed that value, but if it’s not nullable, then it will cast it.
>
> Considering how this tends to only allow lossless casts, though, it
> might be worth reconsidering this and just disallowing NULL
> altogether. It’s worth pointing out that NULL is usually an error
> value, and you might get it from using an uninitialised variable or
> calling an internal function with bad parameters.
The same thing applies to boolean values. FALSE is frequently returned
from internal functions when an error occurs, and allowing it to be
passed to a function expecting a different scalar type could mask errors.
After reading Simon's response I do feel it would be a reasonable
compromise to allow strings to be cast to int/float (and vice versa) as
long as no data loss occurs (following the current rules in the RFC).
If the RFC is updated to disallow NULL altogether and also disallow
boolean values for other scalar types I would be 100% supportive.
--
Theodore Brown
A PHP developer interested in the future of the language
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
