Re: [RFC] Consistent type errors for internal functions

Ben Ramsey <ben@benramsey.com> schrieb am Sa. 16. Feb. 2019 um 18:35: > > On Feb 5, 2019, at 05:22, Nikita Popov <nikita.ppv@gmail.com> wrote: > > > > Hi internals, > > > > 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 > > > > 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. > > > I like this RFC, and from a user perspective, this consistency is > much-needed. > > While warnings don’t affect continued processing, uncaught TypeErrors do. > What is the recommended upgrade path for users? How will this affect the > silence @-operator, since I’m sure many users use that to squelch these > warnings, and they accept the null or false return value as acceptable for > processing the rest of the script. > > Cheers, > Ben This exception is only for argument errors. Fopen would continue to warn + false when file doesnt exist, which is what @ is nostly used for (using fopen as example) > >