Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104216 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 26862 invoked from network); 6 Feb 2019 02:59:16 -0000 Received: from unknown (HELO localhost.localdomain) (76.75.200.58) by pb1.pair.com with SMTP; 6 Feb 2019 02:59:16 -0000 To: internals@lists.php.net References: Date: Wed, 6 Feb 2019 00:40:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Posted-By: 85.230.241.5 Subject: Re: [RFC] Consistent type errors for internal functions From: ajf@ajf.me (Andrea Faulds) Message-ID: Hi Nikita, Nikita Popov wrote: > I'd like to bring forward the following proposal for PHP 8, which will make > (zpp) parameter parsing failures always result in a TypeError (rather than > generating a warning+null, depending on circumstances): > > https://wiki.php.net/rfc/consistent_type_errors I like this proposal. IMO PHP's E_WARNING + NULL is the worst of its “Keep Calm and Carry On” (sorry) behaviours, it would be nice to get rid of it for good, rather than just in the comfy world of strict_types=1. > The goal here is to remove one of the inconsistencies between user-defined > and internal functions, and to put us in a position where we can actually > start specifying type information in arginfo without fear of breaking > things. Regrettably, as I pointed out to you via another channel, that idea also faces the problem of the other deliberate inconsistency I am responsible for in userland scalar type declarations, namely that the non-nullable variety of those reject null as a valid value, unlike internal functions which will happily coerce it. It's funny to mention this here, as the E_WARNING + NULL behaviour your RFC would drop was a primary justification of mine for making NULL special here. Unfortunately it's not the only case, I'm sure uncountably much PHP code relies on things like strlen($_GET['nonexistent']) working… but I digress. Thanks, Andrea