Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104232
MIME-Version: 1.0
References: <CAF+90c9E6O-12fKKY_kb5b_LvXgODbPpC73TNro+XpMewndT2Q@mail.gmail.com>
 <CAOWwgpk0EsJB1t6XEGQYL9Zj2e5oTFXo2ijv7Pn7HMzB=oA88w@mail.gmail.com>
 <CAF+90c9xKmK1ozY29RwpVVMOnDcn3kY=M2m9Pjv5f2hqX8RGoQ@mail.gmail.com> <CAOWwgpke6okcmqeeUcq1ScTfnxXKwzB87ZdNJ7TzdOfYXfSXnA@mail.gmail.com>
In-Reply-To: <CAOWwgpke6okcmqeeUcq1ScTfnxXKwzB87ZdNJ7TzdOfYXfSXnA@mail.gmail.com>
Date: Wed, 6 Feb 2019 09:56:02 +0100
Message-ID: <CAF+90c8BQgRpvhLCEhnpyhBm3jguY8QZ_nS7Eo9yCVe8o_LDLw@mail.gmail.com>
To: Nicolas Grekas <nicolas.grekas@gmail.com>
Cc: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000594de7058135e6d2"
Subject: Re: [PHP-DEV] [RFC] Consistent type errors for internal functions
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000594de7058135e6d2
Content-Type: text/plain; charset="UTF-8"

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

--000000000000594de7058135e6d2--