Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105214 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 38888 invoked from network); 10 Apr 2019 19:57:50 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 10 Apr 2019 19:57:50 -0000 To: internals@lists.php.net References: <5cadfed8.1c69fb81.31f7d.1c49SMTPIN_ADDED_MISSING@mx.google.com> <5cae100d.1c69fb81.548c.48a4SMTPIN_ADDED_MISSING@mx.google.com> Date: Wed, 10 Apr 2019 17:55:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Posted-By: 94.0.205.114 Subject: Re: [PHP-DEV] [RFC] Nullable Casting From: markyr@gmail.com (Mark Randall) Message-ID: 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