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

  105213
April 10, 2019 16:15 benjamin.morel@gmail.com (Benjamin Morel)
> > I believe returning null in those situations makes the most intuative > sense, yes.
No offense, but how can casting semantics different from those already used in implicit casting be intuitive? function a(int $x) { var_export($x); } function b(?int $x) { var_export($x); } a("123"); // 123 a(null); // TypeError a("abc"); // TypeError b("123"); // 123 b(null); // NULL b("abc"); // TypeError IMO, the only reasonable choice is therefore: (int) "123"; // 123 (int) null; // TypeError (int) "abc"; // TypeError (?int) "123"; // 123 (?int) null; // NULL (?int) "abc"; // TypeError At least, if we want to fix the current behaviour, and not introduce another inconsistency. In other words, *strictly apply to explicit casting the rules of implicit casting when strict_types is disabled*. -- Ben
  105214
April 10, 2019 16:55 markyr@gmail.com (Mark Randall)
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