Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116918
To: internals@lists.php.net
Date: Mon, 24 Jan 2022 23:47:32 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Long-Term Planning for PHP 9.0 Error Promotion
From: marandall@php.net (Mark Randall)
Message-ID: <php.internals-116918@news.php.net>

Internals,

PHP 9.0, likely a few years away at this point, is our next opportunity 
to make significant breaking changes.

So I thought it would be appropriate to start a thread discussing what 
breaking changes we might want to include in it, specifically in 
relation to error handling behaviour both at engine level, and 
potentially library level.

By discussing and passing RFCs sooner rather than later, end users and 
library maintainers will have much more advanced notice than if we 
waited until 8.4 had released.

My goal is to help coordinate putting forth a set of individual RFCs, or 
maybe a collective set similar to 
https://wiki.php.net/rfc/engine_warnings that will specifically target 
PHP 9.0, even though that version does not yet have a release date, or 
even a release year.

Nothing in this conversation will preclude others from passing 
additional RFCs in the future years that also target PHP 9 error 
promotion, or, for that matter, reversing those decisions potentially 
made here, if necessary.


For my part I will be putting forward two votes which will hopefully 
complete the migration process started in Nikita's engine warnings RFC:


** Undefined Variables Promoted to Error **

PHP currently treats reading an undefined variable as though it were a 
null, emitting a warning message in the process. This was previously 
promoted from a notice in the PHP 8 engine warnings RFC.

At the time a 3 way vote was held between promoting to an error 
exception, a warning, or leaving it as a notice.

At the time, 56% voted in favour of throwing an Error, 28% in favour of 
a warning, and the remainder leaving it as a notice.

My understanding is that many of those who voted to raise it to a 
warning did so because they felt that jumping straight from a notice to 
an Error was too much in one go.

As it will have been a warning for around 5 years by the time PHP 9 is 
released, I expect that there will now be a healthy super majority to 
bump this up to throwing an error.



** Redefine Constants Promoted to Error / ValueError **

Attempting to redefine a constant either via 'const x' or define 
currently emits a warning, as well as failing.

My straw poll 
(https://wiki.php.net/redefine_constants_exception_strawpoll) gives a 
strong indication that there is an appetite to promote this from a 
warning to an error, potentially throwing a ValueError, in PHP 9.

This will bring it more into line with the result of attempting to 
redefine other constructs such as functions and classes.


** Other Recommendations **

Let's open a discussion as to what we might want to do in the future, 
and depending on how things shake out, we can decide what route to take 
with regards to bringing RFCs to vote.

--
Mark Randall