Re: [RFC] Consistent type errors for internal functions

From: Date: Tue, 05 Feb 2019 23:40:30 +0000
Subject: Re: [RFC] Consistent type errors for internal functions
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-104216@lists.php.net to get a copy of this message
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

« previous php.internals (#104216) next »