On 10/04/2019 17:15, Benjamin Morel wrote:
No offense, but how can casting semantics different from those already used
in implicit casting be intuitive?
As is implied from the name, an implicit cast is done because the code
needs it to, not because it has been told to by the caller. It is
natural to be more conservative when doing something that has not been
explicitly specified.
I expect a difference in the behaviour of function arguments vs casts
for the reason that although they share a type syntax, they do have two
very different behaviours.
Function arguments specify what goes *in* to a function, whereas casts
and return types specify what comes *out* of the function.
I would still expect the following:
function x(): ?int { return "foo"; } // TypeError because return is
effectively a function
function x(): ?int { return (int?)"foo"; } // null
I don't think it would go down very well to have non-nullable casts
throwing TypeErrors for common cases, without an elegant
could-not-convert fallback that doesn't require a 5 line try-catch block.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
