Re: [RFC] Consistent type errors for internal functions
| From: | Nikita Popov | 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