Re: [PHP-DEV] [RFC] Nullable Casting

  105217
April 10, 2019 17:34 benjamin.morel@gmail.com (Benjamin Morel)
> 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 <markyr@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 > >
  105218
April 10, 2019 18:01 markyr@gmail.com (Mark Randall)
On 10/04/2019 18:34, Benjamin Morel wrote:
> 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 have to disagree with this as I think of "return" as a language construct function that takes one argument. When a return type is specified, that return function effectively inherits that type for its only argument, and limitations on implicit conversion should apply.
> 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 @.
That's exactly what it is, and thanks to null coalescence, you then have an easy available ability to either check if it succeeded, or default to another value. $items = (?int)$_GET['items']; if ($items === null) { // it didn't just resort to 0, which might be perfectly valid throw new Exception('Unsure how many items'); } $value = (?string)$_GET['name'] ?? ''; if ($value === '') { // also, ?name[]= can sod off throw new Exception('You must provide a name'); } -- Mark Randall