Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Same thing, not everyone wants to use strict types, and the change in PHP 8.1 is a pain, adding (string) everywhere just means adding more code with no gain just to get around a limitation of the language. So thank you Craig for this RFC :) -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

I am on the fence about this change? How about we remove the warning from pre-increment operator and turn the rest into warnings? Is this possible? Would it be a good compromise?

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Sun, Jan 30, 2022 at 5:41 PM Christian Schneider wrote: > Am 30.01.2022 um 16:55 schrieb Nikita Popov : > > Something I want to add here is that there is also an important technical > > motivation behind promoting undefined variable notices to exceptions: The > > big problem with these (from a

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 30.01.2022 um 16:55 schrieb Nikita Popov : > Something I want to add here is that there is also an important technical > motivation behind promoting undefined variable notices to exceptions: The > big problem with these (from a pure implementation perspective) is that we > need to throw the warn

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Tue, Jan 25, 2022 at 12:47 AM Mark Randall wrote: > 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 incl

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Hi, > You're not going to convince me that not initializing variables is a good > thing Personally, I don't think uninitialized variables are a "good thing" but I also don't think they're a "bad thing" either. I'd just like to see it not matter when writing a simple one-off script. FWIW, C# has g

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Sat, Jan 29, 2022 at 8:58 PM Christian Schneider wrote: > Am 29.01.2022 um 20:03 schrieb Mark Randall : > > On 29/01/2022 16:33, Christian Schneider wrote: > >> If a static analyzer manages to catch it at development time then that > is a lot better. > > > > Of course it's better, but you woul

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 29.01.2022 um 20:03 schrieb Mark Randall : > On 29/01/2022 16:33, Christian Schneider wrote: >> If a static analyzer manages to catch it at development time then that is a >> lot better. > > Of course it's better, but you wouldn't argue that a car doesn't need airbags > because you've tested

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On 29/01/2022 16:33, Christian Schneider wrote: If a static analyzer manages to catch it at development time then that is a lot better. Of course it's better, but you wouldn't argue that a car doesn't need airbags because you've tested that the breaks work. Defense in depth. Our ecosystem

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 28.01.2022 um 23:57 schrieb Jordan LeDoux : > > On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider > wrote: > > My issue with this is that while it seems to work towards the goal of "fail > fast" it does not completely fulfill its promise. > > > Pardon me, b

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Thu, Jan 27, 2022 at 12:24 AM Christian Schneider wrote: > > My issue with this is that while it seems to work towards the goal of > "fail fast" it does not completely fulfill its promise. > > Pardon me, but this argument seems rather impotent. Only fully realized features are allowed? What if

RE: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

> Any type error should if you ask me. Unexpected types cause unexpected > behavior, and the longer PHP will try to continue with assumptions of types > and implicit casting, the bigger the damage can be. All this type juggling is > headache material and the less I see of it, the better. Sorry

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Fri, Jan 28, 2022 at 3:13 PM Robert Landers wrote: > I would posit differently. In my experience in upgrading code, it was > mostly intentional. > Here's an example: > > > if($doThing) { > $doOtherThing = maybe(); > } > // later > if($doOtherThing) { > doOtherThing(); > } > --- > > Th

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Hi, > So what we're talking about here is changing the engine's definition of > what is safe One of the benefits of PHP is it's resilience in the face of user input. The only time this isn't desired is in a security context (SQL queries, authentication, etc). Most applications are not operating i

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 27.01.2022 um 23:41 schrieb Mark Randall : > What we don't want to do, I think, is end up in a situation like JS where it > has to be opted in: https://www.w3schools.com/js/js_strict.asp That's why the majority decided a while ago that you don't have to opt-in right now: The default error_rep

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On 27/01/2022 22:09, Larry Garfield wrote: I am not sure what additional value is gained by making the scream even louder. For us to make something an exception at engine level, is to stop execution on the grounds that the engine no longer considers it safe to continue. That might be becau

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Thu, Jan 27, 2022, at 2:24 AM, Christian Schneider wrote: > Am 27.01.2022 um 05:17 schrieb Mark Randall : >> It is my firm believe that a language such as PHP should not be dependent on >> static analysers to protect users against engine-level problems that may >> occur during runtime. > > My

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Hey Marco, On Wed, Jan 26, 2022 at 1:20 PM Marco Pivetta wrote: > Hey Jakub, > > On Wed, Jan 26, 2022 at 1:58 PM Jakub Zelenka wrote: > >> > >> > PHP 9.0, likely a few years away at this point, is our next opportunity >> > to make significant breaking changes. >> > >> >> Maybe we should give us

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On 25-01-2022 00:47, Mark Randall wrote: 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, specifical

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 27.01.2022 um 05:17 schrieb Mark Randall : > It is my firm believe that a language such as PHP should not be dependent on > static analysers to protect users against engine-level problems that may > occur during runtime. My issue with this is that while it seems to work towards the goal of "f

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On 26/01/2022 14:48, Christian Schneider wrote: Please don't flame me, I just wanted to point out that there is an opposing view on internals to consider ;-) It is my firm believe that a language such as PHP should not be dependent on static analysers to protect users against engine-level pr

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On 26/01/2022 17:13, Rowan Tommins wrote: For instance, the following code is safe, useful, and readable: $countsByDayByCategory = []; foreach ( $someData as $item ) {     $countsByDayByCategory[ $item['day'] ][ $item['category'] ]++; } I myself am not planning to hold a vote on undefined ar

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider wrote: > My experience is quite the opposite: Systems will stay on older PHP > versions for much longer so they do not having to deal with the work. > Especially for shared hosting services. > Which is even worse in my books. Projects that are

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 26.01.2022 um 17:42 schrieb Craig Francis : > While I did begin an RFC to allow *some* functions to be more tolerant of > NULL, especially for those scripts not using `strict_types`: > > https://wiki.php.net/rfc/allow_null > > Or in other words, to "relax certain type requirements on a case by

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On 26/01/2022 14:48, Christian Schneider wrote: 2) Hot take: I still consider the well-defined constructs like $count++ or $counts[$word]++ to be useful I agree, particularly with regards array items rather than top-level variables. Last time this came up, I suggested that before promoting t

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Mon, 24 Jan 2022 at 23:47, Mark Randall wrote: > 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. > While I did begin an RFC to allow *some* functions to be

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 26.01.2022 um 16:55 schrieb Lynn : > I don't want to waste time trying to figure out if an undefined `$j++` is a > bug because it should've been `$i++`, or that `$i = 0;` is supposed to be > unused because someone forgot to remove it. Given the legacy I work with, > it's unrealistic to have s

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Wed, Jan 26, 2022 at 3:48 PM Christian Schneider wrote: > I do not think we should make undefined variables (and array indices?) an > error: 1) Static analysis has gotten a lot better and catches most of this, often > even earlier than the runtime check. > 2) Hot take: I still consider the we

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Am 25.01.2022 um 00:47 schrieb Mark Randall : > ** 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.

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

Hey Jakub, On Wed, Jan 26, 2022 at 1:58 PM Jakub Zelenka wrote: > > > > PHP 9.0, likely a few years away at this point, is our next opportunity > > to make significant breaking changes. > > > > Maybe we should give users a bit more time for adoption and consider major > version bump when PHP 8 h

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

> > PHP 9.0, likely a few years away at this point, is our next opportunity > to make significant breaking changes. > Maybe we should give users a bit more time for adoption and consider major version bump when PHP 8 has got at least 80% and the PHP 5 usage is close to zero. I know that it's hard

Re: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

On Tue, Jan 25, 2022 at 2:47 AM Mark Randall wrote: > 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. My personal opinion: there should be no old style errors

[PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

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 behaviou