On Wed, Feb 6, 2019 at 12:40 AM Andrea Faulds <a...@ajf.me> wrote: > 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. >
Right, thanks for pointing that one out. We could either resolve this by making the behavior of internal functions consistent with user-defined ones here (which would be another BC break for another RFC), or alternatively we could make the arginfo handling for internal functions consistent with zpp. I already mentioned previously that we'll have to drop arginfo type checks for internal functions if we want to get serious about adding those type annotations, otherwise we'd be paying for duplicate type checks. That would leave us with just the zpp behavior, which allows null for scalars. It's not great, but probably much better than functions either accepting null or not depending on whether they use arginfo. Nikita
