Re: [RFC] Nullable Casting

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