> Function arguments specify what goes *in* to a function, whereas casts
> and return types specify what comes *out* of the function.
So why would you have different semantics for implicit `(?int)` cast vs `:
?int` function return type cast, if they're both *out*?
Return type cast has the same semantics as parameter type cast.
> 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
This looks weird to me. I would expect this last line to throw anyway.
Having "foo" passed somehow where your code expects an int(ish) or null,
should not be silenced and converted to NULL IMO.
To me, this last line just says "ignore any error here" - a bit like
prefixing it with @.
> 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.
I can't find a use case on top of my head, where I usually want to silence
a failed conversion, other than user input validation; and I don't think
type casts are specifically designed for this purpose.
Of course there could be helper functions with different semantics, that
would perform a cast-or-null-on-failure, such as `to_int("abc") === null`,
but having (?int) do this job is IMHO a bad idea which does not help moving
the language towards better consistency.
- Ben
On Wed, 10 Apr 2019 at 18:55, Mark Randall <mar...@gmail.com> wrote:
> 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
>
>
