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

[BohwaZ]

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
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Kamil Tekiela]

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

[Nikita Popov]

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 pure implementation perspective) is that
> we
> > need to throw the warning and continue running. But the warning might
> call
> > a custom error handler, which may modify state that the virtual machine
> > does not expect to be modified. The PHP VM plays increasingly complex
> games
> > to prevent this, but despite all that complexity, this problem cannot be
> > fully solved while this remains a warning, rather than an exception.
>
>
> Just so it has been mentioned: This could also be addressed by removing
> the warning (-:C
>
> Out of curiosity: If undefined variables would be turned into exceptions,
> is the fact that now almost every operation can throw an exception that
> much easier to handle?
>

Almost every operation can *already* throw an exception -- if something
throws a warning, then that warning may be promoted to an exception by a
custom error handler.

But yes, dealing with exceptions is much simpler, because they abort
control flow.

Regards,
Nikita

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

[Christian Schneider]

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 warning and continue running. But the warning might call
> a custom error handler, which may modify state that the virtual machine
> does not expect to be modified. The PHP VM plays increasingly complex games
> to prevent this, but despite all that complexity, this problem cannot be
> fully solved while this remains a warning, rather than an exception.


Just so it has been mentioned: This could also be addressed by removing the 
warning (-:C

Out of curiosity: If undefined variables would be turned into exceptions, is 
the fact that now almost every operation can throw an exception that much 
easier to handle?

- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Nikita Popov]

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 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.
>

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 warning and continue running. But the warning might call
a custom error handler, which may modify state that the virtual machine
does not expect to be modified. The PHP VM plays increasingly complex games
to prevent this, but despite all that complexity, this problem cannot be
fully solved while this remains a warning, rather than an exception.

Same goes for other warnings in the engine of course, undefined variables
are just the biggest offender, because this particular warning can occur as
part of nearly any operation. The additional complexities that arise when
you combine this problem with a JIT compiler are left as an exercise to the
reader.

Regards,
Nikita

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

[Robert Landers]

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 gone the way of making initializing
variables simpler and simpler over the years, almost to the point of not
being required.

The fact that PHP fires a warning now is probably enough for anyone writing
any code. If people choose to ignore warnings
they're free to do that. Though I suppose they're also free to fork PHP and
remove the thrown error too :D

> > There's no bug here, nothing is unintentional, and the intent is clear
>
> I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell
> whether or not this code is suffering from a merge conflict, and I cannot
guarantee that whatever type `maybe();` returns
> here works. If at some point the return type of `null` is changed to
`false`, while the assumption of undefined is `null`,
> passing `false` to a nullable typed argument later on will break.

That's what unit tests are for. ;) I can count on one hand the number of
times I've seen a bad merge in my entire 15+ year career,
so that wouldn't be an immediate conclusion I'd come to when seeing
something like this. It's much more likely it would be
intentional than not (without checking the history), but I probably
wouldn't bother in this case. If tests pass, don't fix it... just add
more tests.

> Our ecosystem of static analysers are fantastic, but they're standalone
> tools outside the remit of internals.

I think you hit the nail on the head Mark. I'd really love to see PHP have
a bundled static analysis tool.

Robert Landers
Software Engineer
Utrecht NL


On Sat, Jan 29, 2022 at 11:55 PM Lynn  wrote:

> 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 wouldn't argue that a car doesn't need
> > airbags because you've tested that the breaks work.
> >
> > To stay with your car analogy: A driving assistant system (especially
> when
> > wrongly interpreted as auto-pilot) can lead drivers to not paying
> attention
> > to the road any more. Which means even systems designed to help can have
> > negative effects.
> >
> > > With runtime checking, the engine should always try to protect against
> > the unexpected, irrespective of if other checking has already been
> > performed by outside sources.
> >
> > I think we've been over this: I don't think the engine should force me to
> > write too much unnecessary stuff just because I have to tell it I am
> sure I
> > mean what I wrote. There is a balance between explicit declarations and
> > conciseness, we just disagree where the sweet spot is.
> >
>
> To stay with the car analogy: Seatbelts were once considered unnecessary as
> well.
>
> Just because you know for sure you know you mean what you wrote, doesn't
> mean everyone else knows. They have to read the code you didn't write to
> know for sure.
>
> On Wed, Jan 26, 2022 at 7:16 PM Christian Schneider  >
> wrote:
>
> > Am 26.01.2022 um 18:37 schrieb Lynn :
> > > I don't understand how variable initializers are considered boilerplate
> > and make it easier to read without.
> >
> > [off-list as I think this has been discussed before]
> >
> > Example:
> >
> > function count_words($words)
> > {
> > foreach ($words as $word)
> > $counts[$word++];
> >
> > return (array)$counts;
> > }
> >
> > vs.
> >
> > Function count_words($words)
> > {
> > $words = [];# <-- Boilerplate
> > foreach ($words as $word)
> > {
> > $counts[$word] ??= 0;   # <-- Currently worse boilerplate
> > but beside your point
> > $counts[$word++];
> > }
> >
> > return $counts;
> > }
> >
> > I find the first version easier to understand but I guess we'll have to
> > agree to disagree here.
> >
> > Regards,
> > - Chris
>
>
> I would appreciate it if you keep the replies to the mailing list. Though
> while I'm at it, your examples are why it's important that we have PHP to
> let us know when things are broken.
>
> You're not going to convince me that not initializing variables is a good
> thing, I've had to fix way too much code where that kind of cowboy coding
> was at fault. As a reader I cannot see if the lack of a variable
> initialization is intentional, so I have to go through the history of the
> file to verify this behavior, and then I add the initialization so the next
> developer seeing this won't have to waste a lot of time by doing the same.
>
> A huge amount of changes in PHP are based 

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

[Lynn]

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 wouldn't argue that a car doesn't need
> airbags because you've tested that the breaks work.
>
> To stay with your car analogy: A driving assistant system (especially when
> wrongly interpreted as auto-pilot) can lead drivers to not paying attention
> to the road any more. Which means even systems designed to help can have
> negative effects.
>
> > With runtime checking, the engine should always try to protect against
> the unexpected, irrespective of if other checking has already been
> performed by outside sources.
>
> I think we've been over this: I don't think the engine should force me to
> write too much unnecessary stuff just because I have to tell it I am sure I
> mean what I wrote. There is a balance between explicit declarations and
> conciseness, we just disagree where the sweet spot is.
>

To stay with the car analogy: Seatbelts were once considered unnecessary as
well.

Just because you know for sure you know you mean what you wrote, doesn't
mean everyone else knows. They have to read the code you didn't write to
know for sure.

On Wed, Jan 26, 2022 at 7:16 PM Christian Schneider 
wrote:

> Am 26.01.2022 um 18:37 schrieb Lynn :
> > I don't understand how variable initializers are considered boilerplate
> and make it easier to read without.
>
> [off-list as I think this has been discussed before]
>
> Example:
>
> function count_words($words)
> {
> foreach ($words as $word)
> $counts[$word++];
>
> return (array)$counts;
> }
>
> vs.
>
> Function count_words($words)
> {
> $words = [];# <-- Boilerplate
> foreach ($words as $word)
> {
> $counts[$word] ??= 0;   # <-- Currently worse boilerplate
> but beside your point
> $counts[$word++];
> }
>
> return $counts;
> }
>
> I find the first version easier to understand but I guess we'll have to
> agree to disagree here.
>
> Regards,
> - Chris


I would appreciate it if you keep the replies to the mailing list. Though
while I'm at it, your examples are why it's important that we have PHP to
let us know when things are broken.

You're not going to convince me that not initializing variables is a good
thing, I've had to fix way too much code where that kind of cowboy coding
was at fault. As a reader I cannot see if the lack of a variable
initialization is intentional, so I have to go through the history of the
file to verify this behavior, and then I add the initialization so the next
developer seeing this won't have to waste a lot of time by doing the same.

A huge amount of changes in PHP are based on what other languages do (or
sometimes rather don't). With the amount of the web that PHP powers, it's a
good thing that PHP grabs the good bits and improves itself. Ensuring that
variables are properly initialized is one of them, as it protects the
developers from making preventable mistakes without requiring external
tools.

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

[Christian Schneider]

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 that the breaks work.

To stay with your car analogy: A driving assistant system (especially when 
wrongly interpreted as auto-pilot) can lead drivers to not paying attention to 
the road any more. Which means even systems designed to help can have negative 
effects.

> With runtime checking, the engine should always try to protect against the 
> unexpected, irrespective of if other checking has already been performed by 
> outside sources.

I think we've been over this: I don't think the engine should force me to write 
too much unnecessary stuff just because I have to tell it I am sure I mean what 
I wrote. There is a balance between explicit declarations and conciseness, we 
just disagree where the sweet spot is.

I do for example admire the power of Haskell's type system but I would never 
want PHP to try to implement it.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[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 that the breaks work.


Defense in depth.

Our ecosystem of static analysers are fantastic, but they're standalone 
tools outside the remit of internals. Maybe that software has a bug, 
maybe it hasn't yet been programmed to recognise the side effects of a 
new feature that was added, maybe the user has not updated the library 
in a while.


With runtime checking, the engine should always try to protect against 
the unexpected, irrespective of if other checking has already been 
performed by outside sources.


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Christian Schneider]

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, but this argument seems rather impotent. Only fully realized 
> features are allowed? What if there is not agreement on the details of some 
> of the edgecases? Something better should be rejected because it's not 
> something perfect?

I was probably too brief there, let me elaborate a bit.

An error on reading an undefined variable does the "fail" part. And it 
partially delivers on the "fast" part as it fails at the first access, not at a 
later point.
But, and that was my point, it is still failing at runtime, maybe long after 
deployment if it is in an obscure code path.
If a static analyzer manages to catch it at development time then that is a lot 
better.

This has an impact on how I evaluate the positive effect of error-on-undefined 
and so far my conclusion was a net-negative compared to the current situation.

Side-note: An additional downside of having the increased safety net on reading 
undefined variables can be that developers think they do not need to have other 
checks like a static analyzers which might do an even better job to make their 
code better. But that's not my main point.

- Chris

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

[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, but this argument seems rather impotent. Only fully realized
features are allowed? What if there is not agreement on the details of some
of the edgecases? Something better should be rejected because it's not
something perfect?

This is an attitude I have encountered from management at jobs before, but
seems very odd to me from a development perspective.

The proposed error may not be good as its own change (personally I could go
either way on it), but this particular explanation is not a reason to vote
against something, it is a rationalization. There may be good reasons to
object to this, but I'd like to hear what those are instead.

Jordan

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

[Reinis Rozitis]

> 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 for derailing, but out of interest - why choose a loosely typed language 
in the first place then?

rr

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Lynn]

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();
> }
> ---
>
> There's no bug here, nothing is unintentional, and the intent is clear.
> Now,
> if we want to get rid of the warning we need to say $doOtherThing = false
> before getting to the first if-statement, but should this halt everything
> in
> production? I don't personally think so and it would be undesirable for it
> to do so.
>

 Let me go over this.

> There's no bug here, nothing is unintentional, and the intent is clear

I cannot guarantee there's no bug, I cannot guarantee that this is
intentional, and the intent is certainly not clear. I can't tell whether or
not this code is suffering from a merge conflict, and I cannot guarantee
that whatever type `maybe();` returns here works. If at some point the
return type of `null` is changed to `false`, while the assumption of
undefined is `null`, passing `false` to a nullable typed argument later on
will break.

> Now, if we want to get rid of the warning we need to say $doOtherThing =
false before getting to the first if-statement

Thank you for pointing to the example above. `null` and `false` are
different values. Your assumption here is that setting it to `false` would
fix the problem, but the actual value would've been `null` and changing it
to `false` might actually break more.

> but should this halt everything in production? I don't personally think
so and it would be undesirable for it to do so.

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.

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

[Robert Landers]

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 in a security
context 100% of the time so your definition of "safe" may not be
appropriate for other people's projects.

> I would posit that the vast majority of reads
> on undefined variables are in fact unintentional side effects from
> branching logic and are not the real intention at all.

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();
}
---

There's no bug here, nothing is unintentional, and the intent is clear. Now,
if we want to get rid of the warning we need to say $doOtherThing = false
before getting to the first if-statement, but should this halt everything in
production? I don't personally think so and it would be undesirable for it
to do so.

Robert Landers
Software Engineer
Utrecht NL


On Thu, Jan 27, 2022 at 11:41 PM Mark Randall  wrote:

> 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 because a boolean was passed to a function that expects a
> string, or in this case it might be because an undefined variable has
> been read.
>
> Notices / Warnings are irrelevant to this under the default
> configuration, as in the absense of a userland error handler the engine
> will happily allow code to continue executing even after a probably
> undesirable state has been detected.
>
> So what we're talking about here is changing the engine's definition of
> what is safe to exclude read operations on an undefined variable.
>
> I understand the argument that the behaviour is well defined, at least
> for some operations, but I would posit that the vast majority of reads
> on undefined variables are in fact unintentional side effects from
> branching logic and are not the real intention at all.
>
> If someone is insistent on working with nulls, there is an easy to use,
> fully backwards compatible way to avoid these errors, which is to define
> a variable as null prior to any branching logic.
>
> For everyone else, we should offer this entirely sensible safety net.
>
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

[Christian Schneider]

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_reporting level shows a warning.

What you want to do is take away the option of *opting out* of this warning. 
And that's where I disagree.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Mark Randall]

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 because a boolean was passed to a function that expects a 
string, or in this case it might be because an undefined variable has 
been read.


Notices / Warnings are irrelevant to this under the default 
configuration, as in the absense of a userland error handler the engine 
will happily allow code to continue executing even after a probably 
undesirable state has been detected.


So what we're talking about here is changing the engine's definition of 
what is safe to exclude read operations on an undefined variable.


I understand the argument that the behaviour is well defined, at least 
for some operations, but I would posit that the vast majority of reads 
on undefined variables are in fact unintentional side effects from 
branching logic and are not the real intention at all.


If someone is insistent on working with nulls, there is an easy to use, 
fully backwards compatible way to avoid these errors, which is to define 
a variable as null prior to any branching logic.


For everyone else, we should offer this entirely sensible safety net.

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


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Larry Garfield]

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 issue with this is that while it seems to work towards the goal of 
> "fail fast" it does not completely fulfill its promise.
> 
> What do you gain by making undefined variables an error? You force 
> developers to sprinkle their code with variable initializations where 
> they might be sure that the well-defined behavior of undefined 
> variables is fine in their code. Why is that a problem?
>
> One of the burdens of early statically typed languages was that you had 
> to declare everything in detail. It was with the advent of type 
> inference that some of the typing overhead could be reduced and a 
> balance between safety and readability through DRY was reached.
>
> Forcing to initialize everything moves PHP against DRY while the safety 
> gained by aborting the program is debatable, even though better 
> approaches (like static analysis) are available now. To me it's about 
> using the right tool for the right job.

That ship sailed in 8.0 when undefineds were promoted to Warnings.  Undefined 
variables are already a "you need to fix this, the engine says you should feel 
bad" issue.  For better or worse.

I don't think it's as dire as you claim, though.  We're not talking about PHP 
going the way of old-C, where you had to pre-define all variables at the start 
of the function.  You can still define variables on-the-fly when you first 
*write* to them.  It's when you first *read* from them that is a very bad time 
to be stealth-defining a variable.  Anything correct that happens at that point 
is by chance, not by design.  It's already a presumptive bug everywhere it 
happens, modulo a few edge cases (like the counter array someone else brought 
up, which is valid).

That said, I am not convinced that a fatal is the correct answer, either.  In 
an interpreted language, we can't guarantee correctness until executing the 
code.  IDEs and other static tools already complain about undefineds.  The 
engine already yells in your face about it if you ignore the analyzers.  I am 
not sure what additional value is gained by making the scream even louder.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Jakub Zelenka]

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 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 to get exact numbers but estimates like [1]
>> or even packagist stats like [2] (I'm aware that not every project uses
>> composer but still better than nothing) could give us some idea. I'm
>> mainly
>> worried that we could introduce too many breaking changes that make
>> migrations (especially for old projects) much harder.
>>
>> [1] https://w3techs.com/technologies/details/pl-php
>> [2] https://blog.packagist.com/php-versions-stats-2021-1-edition/
>>
>
> A more updated statistic:
> https://stitcher.io/blog/php-version-stats-january-2022
>
> Continuously generated output at https://packagist.org/php-statistics
>
>
Thanks for those more up to date stats. Thinking about it, it probably more
shows what PHP versions is the current development on but probably doesn't
reflect the amount of code running in production. I think it's logical that
the older versions won't get too many updates so there won't be that many
installs. It's still useful metric to have though.


> I also maintain a number of PHP 5 (closed-source) projects that don't use
> packagist nor composer, but that's really just their problem, as they will
> need to upgrade to ~7.0.0 first anyway.
>

Yeah althought they will loose PHP 7 docs once we go to PHP 9 but don't
think that PHP 5 users are such a big worry due to distro support (see
below).


> Also, my customers are gently asked to sign a piece of paper in which I'm
> not responsible for their bad security awareness.
> For those projects, should it be needed, Zend provides commercial support
> as a "OMG WE DON'T ACTUALLY WANT TO PAY TO ACTUALLY IMPROVE OUR CRITICAL
> INFRASTRUCTURE" last resort.
>

I think RHEL 7 still supports (provides security updates)  PHP 5.4 from
what I read. It's support ends in 2024 which would be probably ok for us. I
see bigger issue with PHP 7 users as RHEL 8 is shipped with 7.2 so support
for that version should be there until 2029. The PHP 7.4 support will be
even longer for Ubuntu 20.04 LTS which should end in 2030. Please correct
me if I'm wrong as this just what I googled. :)

What I want to say is that those LTS users should still have an easy path
to update and ideally we should keep the docs available for them. It
already happened for PHP 5 users and it might mean that some of those users
will never update and possibly change the language. Also we should not
forget that there was much bigger motivation to update from 5 to 7 than it
is from 7 to 8 due to perf improvements and if w3techs is partially
correct, than 20% is still a lot. I think we could try to support the PHP 7
LTS users better. I realise that waiting till 2030 might be too long but
2025 sounds too soon. Maybe something like 2028 or 2027 would be more
sensible.

Regards

Jakub

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

[Dik Takken]

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, specifically in 
relation to error handling behaviour both at engine level, and 
potentially library level.


Recently I came across the following array destructuring edge case:

[$a, $b] = 1;

This statement is perfectly valid. No exception, no error, no notice, 
nothing. Its effect is that it assigns null to both variables. IMHO the 
above should be a compile time error.


Also, I think the following should throw a TypeError when the right hand 
side is not iterable:



[$a, $b] = $c;

Currently, the above statement silently assigns null to both $a and $b.

In the context of a foreach loop, the behavior is slightly better. The 
following generates a warning:


foreach (1 as [$b, $c]);

As does the following if $a is not iterable:

foreach ($a as [$b, $c]);

As array destructuring is conceptually related to array unpacking I 
would expect the engine to handle similar cases in the same way. This is 
not the case though. The following statement throws a TypeError since 
PHP 8.0:


var_dump(...1);

And, while we are at it, the following is a fatal error:

$a = [...1];

while the following throws an Error exception (should be TypeError?) 
when $b is not iterable:


$a = [...$b];

Perhaps these oddities / inconsistencies are good candidates for 
addressing in PHP 9.0?


Regards,
Dik Takken

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Christian Schneider]

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 "fail 
fast" it does not completely fulfill its promise.

What do you gain by making undefined variables an error? You force developers 
to sprinkle their code with variable initializations where they might be sure 
that the well-defined behavior of undefined variables is fine in their code. 
Why is that a problem?

One of the burdens of early statically typed languages was that you had to 
declare everything in detail. It was with the advent of type inference that 
some of the typing overhead could be reduced and a balance between safety and 
readability through DRY was reached.

Forcing to initialize everything moves PHP against DRY while the safety gained 
by aborting the program is debatable, even though better approaches (like 
static analysis) are available now. To me it's about using the right tool for 
the right job.

> However, internals is not responsible for getting people to use a static 
> analyser, we are responsible for the behaviour of the engine, and right now 
> the engine is, I think, too lax in this regard.

My counterpoint would be that there are other topics where internals decided 
that something is better handled in user-land than on the engine level.

You could say that the engine can provide an additional layer but I could 
counter that it discourages people from using a static analyzer because they 
have a (possibly false) sense of security.

> That you're manually patching PHP to change official behaviour (which was 
> passed by RFC) puts your individual use case well outside of what should be 
> considered when voting.


Let me explain: First we were suppressing some warnings in an error_handler 
(and we are not the only ones doing it) and the decision to go one step further 
was taken because we didn't want to pay the performance penalty after 
collecting enough experience with not having this warning.

While you may disagree with that approach it is still an indication that there 
are different views on this, which should be considered.
The loser of a vote should not be completely ignored ;-)

Anyway, I think we've covered the two sides of the story quite well now, I'll 
refrain from making this thread longer than necessary.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Mark Randall]

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 
problems that may occur during runtime.


Third party static analysers are great, and I am a strong proponent of 
Psalm.


However, internals is not responsible for getting people to use a static 
analyser, we are responsible for the behaviour of the engine, and right 
now the engine is, I think, too lax in this regard.


We should be aiming to provide a reasonably safe experience out the box.

That you're manually patching PHP to change official behaviour (which 
was passed by RFC) puts your individual use case well outside of what 
should be considered when voting.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Mark Randall]

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 array.

If there were one it would be an independent vote the same as "Undefined 
Array Index" in https://wiki.php.net/rfc/engine_warnings which promoted 
it to warning in 8.0.


As it's marked as a warning, I would expect it to still get upgraded at 
some point in PHPs lifetime, maybe even in PHP 9, but I am not proposing 
it with this batch of updates.


Mark Randall

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Lynn]

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 not being actively developed, nor being improved to work
with newer php versions shouldn't block the future of PHP.

On Wed, Jan 26, 2022 at 5:35 PM Christian Schneider 
wrote:

>
> This is where we disagree: I think being able to use undefined variables
> and indices avoids boiler plate code and can make it easier to read.
>

How do you determine that a missing variable initializer isn't a bug or
broken merge? I encountered this as recently as yesterday. It's easy to
miss, hard to find out what the actual code is supposed to be doing while
you're digging through your commit history. Especially when working on
bigger applications with more contributors this can lead to a serious
issue. Luckily the bug I fixed didn't have any big implications, but it
could've just as easily been a mistake costing thousands of euros.

I don't understand how variable initializers are considered boilerplate and
make it easier to read without. It makes things unclear and unpredictable,
and can unintentionally change behavior of your code when not being
cautious. Considering "easier to read" is being taken quite literally here,
I'll change it to "easier to understand". When in the future, either
tomorrow or in 5 years, a developer reads my code, the last thing that
developer wants is to make assumptions of how the code is supposed to work
when things are seemingly missing.

That said, my focus is on variables. Imo index initializers are part of a
bigger discussion that encompasses (dynamic) data structures and shouldn't
be treated the same.

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

[Christian Schneider]

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 case
> basis", ref the original discussion:
> 
> https://externals.io/message/112327
> 
> The only feedback I've received is that it's a "terrible idea" (no
> details), "it's a bit late" (deprecations have already been issued, full
> steam ahead?), and the typical objections/negativity (-4 points on
> externals.io, not quite a record, but getting there).

For the record: I'm in favor of pursuing this RFC, I think disallowing null for 
functions like strlen does more harm than good.

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Rowan Tommins]

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 the 
error further, we find elegant solutions for the valid use cases.


For instance, the following code is safe, useful, and readable:

$countsByDayByCategory = [];
foreach ( $someData as $item ) {
    $countsByDayByCategory[ $item['day'] ][ $item['category'] ]++;
}

While there are definitely cases where spotting unset array keys would 
be useful, the current "fix" for this code leads to repetitive and hard 
to read code, which is probably *easier* to miss a mistake in:


$countsByDayByCategory = [];
foreach ( $someData as $item ) {
    $countsByDayByCategory[ $item['day'] ] ??= [];
    $countsByDayByCategory[ $item['day'] ][ $item['category'] ] ??= 0;
    $countsByDayByCategory[ $item['day'] ][ $item['category'] ]++;
}


Python has a "defaultdict" which lets you define the default for each 
dimension up front, rather than needing conditionals inside the loop, 
something like this:


$countsByDayByCategory = new DefaultDict(new DefaultDict(0));
foreach ( $someData as $item ) {
    $countsByDayByCategory[ $item['day'] ][ $item['category'] ]++;
}

I would be very interested in having something similar in PHP, and other 
suggestions to similar use cases, rather than just marching onwards with 
errors.



Regards,

--
Rowan Tommins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Craig Francis]

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 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 case
basis", ref the original discussion:

https://externals.io/message/112327

The only feedback I've received is that it's a "terrible idea" (no
details), "it's a bit late" (deprecations have already been issued, full
steam ahead?), and the typical objections/negativity (-4 points on
externals.io, not quite a record, but getting there).

The view seems to be that every single PHP developer must use *strict*
static analysis (e.g. Psalm at levels 1 to 3, with no baseline), and tools
like Rector or PHPCompatibility (neither of which handle this problem;
where I'll note that it will be hard to do, as it involves tracking every
single variable from source to sink).

While I'm not a C programmer, I was just thinking of replacing some uses of
`Z_PARAM_STR` with something similar to `Z_PARAM_STR_OR_NULL`, maybe
calling it `Z_PARAM_STR_ALLOW_NULL`, where it would return an empty string
for NULL with scripts not using `strict_types`... but I got the impression
this would be unacceptable.

So I assume, with this PHP 9.0 discussion, we should just get on with this
ideological purity, move on from deprecation, and raise a Fatal Error for
everyone committing heinous crimes such as:

echo htmlspecialchars($name);

Where `$name` might contain NULL, due to using something like
`($_GET['name'] ?? NULL)`, as used by some minor frameworks
like Laravel, Symfony, CakePHP, CodeIgniter, etc - a pattern used to denote
a value not being provided by the user.

As an aside, I love how the RFC template includes this example quote from
Rasmus:

> PHP is and should remain:
> 1) a pragmatic web-focused language
> 2) a loosely typed language
> 3) a language which caters to the skill-levels and platforms of a wide
range of users

And, yes, I am venting, but who cares, I'm not going to change anyones mind.

Craig

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

[Christian Schneider]

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 static code analysis implemented in these projects 
> within a foreseeable time due to the sheer size. Updating PHP to a newer 
> version will get development time because we can't stay behind, thus 
> enforcing these good standards.

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.

> Imo convenience is not a good argument to write code that's potentially 
> bugged and harder to grasp for the reader.

This is where we disagree: I think being able to use undefined variables and 
indices avoids boiler plate code and can make it easier to read.

But then again I know that this is all highly dependent on your environment.
I'm only trying to get across that it is IMHO not a clear-cut decision if such 
a change is worth it. That's all.

Regards,
- Chris

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

[Lynn]

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 well-defined constructs like $count++ or
> $counts[$word]++ to be useful. That's why we actually patch our  PHP to not
> emit warnings for undefined variable or index ...
> 3) ... which could be impossible at some point once the engine internally
> makes assumptions that the program does not continue after an undefined
> variable. But then again maybe I worry too much :-)
>
> I'll vote 'no' on this one again and would ask you to consider leaving
> this (like many other things) to the realm of static analyzers instead of
> hard-wiring it in the engine, even if you don't use undefined variables
> personally.
>

Far too often I encounter code where I don't know if it was a variable with
a typo, a bad merge, or simply incrementing an undefined variable,
especially in the context of legacy code. It leaves me with a lot of
guessing and side-tracking when trying to find bugs or make changes. Yes
this can be enforced by static code analysis, but quite frankly getting
tired of having to fight for this in many projects that don't use it. It's
much, much harder and costs much more effort to have to convince a whole
lot of people all the time of something being better, and having to rely on
blog posts that people *might *read. My experience is that people don't
care for these rules and recommendations if they are opt-in and in fact
make it harder to implement.

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 static code analysis implemented in these projects
within a foreseeable time due to the sheer size. Updating PHP to a newer
version *will *get development time because we can't stay behind, thus
enforcing these good standards.

Imo convenience is not a good argument to write code that's potentially
bugged and harder to grasp for the reader.

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

[Christian Schneider]

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.
> 
> 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.



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 well-defined constructs like $count++ or 
$counts[$word]++ to be useful. That's why we actually patch our  PHP to not 
emit warnings for undefined variable or index ...
3) ... which could be impossible at some point once the engine internally makes 
assumptions that the program does not continue after an undefined variable. But 
then again maybe I worry too much :-)

I'll vote 'no' on this one again and would ask you to consider leaving this 
(like many other things) to the realm of static analyzers instead of 
hard-wiring it in the engine, even if you don't use undefined variables 
personally.

Please don't flame me, I just wanted to point out that there is an opposing 
view on internals to consider ;-)

Regards,
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[Marco Pivetta]

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 has got at least 80% and the PHP 5 usage is close
> to zero. I know that it's hard to get exact numbers but estimates like [1]
> or even packagist stats like [2] (I'm aware that not every project uses
> composer but still better than nothing) could give us some idea. I'm mainly
> worried that we could introduce too many breaking changes that make
> migrations (especially for old projects) much harder.
>
> [1] https://w3techs.com/technologies/details/pl-php
> [2] https://blog.packagist.com/php-versions-stats-2021-1-edition/
>

A more updated statistic:
https://stitcher.io/blog/php-version-stats-january-2022

Continuously generated output at https://packagist.org/php-statistics

I also maintain a number of PHP 5 (closed-source) projects that don't use
packagist nor composer, but that's really just their problem, as they will
need to upgrade to ~7.0.0 first anyway.
Also, my customers are gently asked to sign a piece of paper in which I'm
not responsible for their bad security awareness.
For those projects, should it be needed, Zend provides commercial support
as a "OMG WE DON'T ACTUALLY WANT TO PAY TO ACTUALLY IMPROVE OUR CRITICAL
INFRASTRUCTURE" last resort.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

[Jakub Zelenka]

>
> 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 to get exact numbers but estimates like [1]
or even packagist stats like [2] (I'm aware that not every project uses
composer but still better than nothing) could give us some idea. I'm mainly
worried that we could introduce too many breaking changes that make
migrations (especially for old projects) much harder.

[1] https://w3techs.com/technologies/details/pl-php
[2] https://blog.packagist.com/php-versions-stats-2021-1-edition/

Regards

Jakub

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

[Max Semenik]

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, warnings or
notices. I don't want to have any more situations like "Oh, there was
something wrong with your code. Hope you'll notice this in your error logs.
Meanwhile, the app will just kinda limp along, likely resulting in bogus
data/behavior." There should only be E_DEPRECATED for things that will
change in a future release and E_ERROR for rare situations that can't be
reasonably handled with exceptions (like  uh, unhandled exceptions and OOM
errors). Everything else should be an exception, period.

-- 
Best regards,
Max Semenik