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

  105231
April 11, 2019 07:52 guilliam.xavier@gmail.com (Guilliam Xavier)
OK, I'll try to sum up a bit the recent messages (since Nikita's one):

Mark Randall wrote:
> 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.
That makes sense!
> 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 agree (and even for nullable casts). I'm also fine with the current `(int)null === 0`, `(string)null === ""`, `(array)null === []` etc. (Now maybe things like `(int)"abc" === 0` *could* emit some Notice like already the case for `(string)[] === "Array"`, but that's another discussion...) Benjamin Morel wrote:
> 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`
There was a "Safe Casting Functions" RFC, which was rejected (but that was in 2014, before PHP 7 and scalar type declarations, so who knows how it would go if re-proposed today...) Mark Randall wrote:
> $nullable_number = $maybe_null ^?? (int)$maybe_null;
That's an... "interesting" idea ^^ (though I would not propose it).
> $nullable_number = (null|int)$input;
This is explicit, but I worry that `null|int` and `int|null` will be different (since you propose *ordered*) whereas they're the same in phpDoc as well as in the (rejected) "Union Types" RFC. (I also fear things like `(null|float|int|string)$x`...) *** The initial motivation behind the RFC was mainly to have an explicit equivalent of "nullability-preserving" implicit *valid* conversions in symmetry with nullable scalar type declarations and weak-typing mode (e.g. `(?string) $int_or_null` or `(?int) $numeric_string_or_null`) for use in strict-typing mode. But there are indeed various combinations of "invalid" conversions (although one could argue they are programming errors or bugs to fix), and people seem to expect different things from a new "(?type)" cast syntax (not to speak of the existing "(type)" cast) as how to handle those "failures"... Honestly as a newbie here I'm feeling more tired than I had expected and I'm not sure if we'll find a syntax+semantics pair that will reach a consensus... Suggestions and comments very welcome! -- Guilliam Xavier
  105238
April 11, 2019 11:42 markyr@gmail.com (Mark Randall)
On 11/04/2019 08:52, Guilliam Xavier wrote:
> Honestly as a newbie here I'm feeling more tired than I had expected > and I'm not sure if we'll find a syntax+semantics pair that will reach > a consensus... Suggestions and comments very welcome!
Don't stress yourself about it. At the end of the day we're all just here because we want to improve the language, and a person's willingness to debate the pros and cons, and adjust if necessary, is naturally a extremely valuable part of the RFC authoring process. When you eventually call the vote itself, regardless of whether it passes or fails, you should both be holding your heads high that you've made the effort. -- Mark Randall