Re: [RFC] Consistent type errors for internal functions

From: Date: Wed, 06 Feb 2019 08:56:02 +0000
Subject: Re: [RFC] Consistent type errors for internal functions
References: 1 2 3 4  Groups: php.internals 
Request: Send a blank email to internals+get-104232@lists.php.net to get a copy of this message
On Wed, Feb 6, 2019 at 9:43 AM Nicolas Grekas <nicolas.grekas@gmail.com> wrote: > > https://wiki.php.net/rfc/consistent_type_errors >>> >>> >>> Would it make sense and be possible to trigger a deprecation notice in >>> PHP 7.4? >>> >>> That might help the ecosystem move forward in a smooth way instead of >>> experimenting the failure when actually moving to 8. >>> >> >> We generally consider a warning a "harder" error than a deprecation >> > > Do all situations that will throw after the RFC trigger a warning right > now? Eg var_dump(substr(null, 1)); doesn't trigger anything but returns > false - does that mean it will not throw a TypeError in your proposal? > That's correct, it will not throw a TypeError. If the call currently succeeds, then it will continue to succeed. substr(null, 1) is considered a perfectly valid substr() call right now. if you are deliberately suppressing warnings, in which case chances are > very good that you are also suppressing deprecations. > > This assumption is wrong in the Symfony ecoystem! > We built the deprecation framework around silenced (and unsilenced) > deprecations, which are all caught and logged. > So it would make a huge difference actually, at least for situations where > no warning is triggered (see substr example above). > Right, but a warning is always triggered here. If there were no warning, then yes, I'd of course agree that this should throw a deprecation first. Nikita

« previous php.internals (#104232) next »