Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:119128
MIME-Version: 1.0
References: <CAMXcktOiFH-0f0PG9cKkkVaczjNLSzQzzPUBcoLyn54X=c74og@mail.gmail.com>
 <D494A14E-0733-406B-844E-DD2D3FBB7EB4@php.net> <CAMXcktNEW9ZyvzOdseaz3yu7zLAKq5LrF74=FAk62BTbF+0qFQ@mail.gmail.com>
In-Reply-To: <CAMXcktNEW9ZyvzOdseaz3yu7zLAKq5LrF74=FAk62BTbF+0qFQ@mail.gmail.com>
Date: Tue, 13 Dec 2022 11:08:27 -0500
Message-ID: <CAMXcktN3mresWgezV+v7QYKqQ5-TFw6sEB7rf3cZNa8KNcDzoQ@mail.gmail.com>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008ae0ba05efb7d5ed"
Subject: Re: [PHP-DEV] Revisiting RFC: Engine Warnings -- Undefined array index
From: dliebner@gmail.com (Dan Liebner)

--0000000000008ae0ba05efb7d5ed
Content-Type: text/plain; charset="UTF-8"

Can I also just point out that by current definitions the "null coalescing
operator" isn't properly named, it should be the "undefined/null coalescing
operator". The only reason it is able to get away with not raising an error
for undefined variables is that it's described as "syntactic sugar" for
isset(), which is itself the exception to the rule for not raising
undefined errors. Other languages, such as JavaScript, would raise an error
for an expression such as `undefinedvar ?? 0`. And JavaScript conveniently
offers the undefined primitive for precisely handling attempted accesses of
undefined keys, while retaining the brevity and convenience of a
truthy/falsy `obj.key` check.

If you're set on raising errors and eventually exceptions for undefined key
accesses, we need a concise, performant way to say `isset($varExpression) ?
$varExpression : null` that's still way more concise than `$varExpression
?? null` that's baked into the language.

On Tue, Dec 13, 2022 at 7:53 AM Dan Liebner <dliebner@gmail.com> wrote:

> > No, code doesn't break. It now shows a warning instead of an error.
> There is no behavioural change.
> It breaks my app. Does that count? And didn't you follow up by referencing
> this as "adding settings that change behaviour"? Does it change behavior or
> not?
>
> > Adding a configuration setting to make this a notice on some
> installations and not on others, would just mean that anything that needs
> to be able to run everywhere needs to take care to not rely on the setting
> either way, making it harder to develop portable code.
> What code now relies on this raising a warning rather than a notice that
> can't consistently deal with it by using isset or the null coalescing
> operator? Or are you subtly referring to the fact that this RFC is a
> stepping stone to escalating the severity to throwing an error?
> https://wiki.php.net/rfc/undefined_variable_error_promotion -> "This RFC
> proposes that accessing an undefined variable is rendered illegal behaviour
> in the next major version of PHP, and will result in an Error exception
> being thrown if it occurs."
>
> Here's another suggestion:
> Make accesses to undefined array keys (objects, variables, etc) return a
> new `undefined` primitive. That way, developers who are focused on writing
> concise, readable code can continue to write and maintain code manageably,
> and developers who are keen on writing a lot of code in a more "strict"
> manner can handle undefined array key accesses consistently, without having
> to rely on configuration settings.
>
> > just fix your code.
> Practically speaking, I'd much more likely stay on 7.4 or migrate to Node.
>
>
> On Mon, Dec 12, 2022 at 5:52 PM Derick Rethans <derick@php.net> wrote:
>
>> On 12 December 2022 22:20:27 GMT, Dan Liebner <dliebner@gmail.com> wrote:
>>
>> >It has been proposed to make the error level of "Undefined index"
>> >configurable so that teams and individual developers can decide for
>> >themselves how they want this situation to be handled. Given that:
>> >
>> >   - PHP has been treating this as an E_NOTICE for over 20 years
>>
>> But not in the last three years.
>>
>> >   - the change is a breaking change affecting many large codebases
>> >   ubiquitously (unless one were to unadvisedly suppress E_WARNING
>> errors)
>>
>> No, code doesn't break. It now shows a warning instead of an error. There
>> is no behavioural change.
>>
>> >   - 7.4 is now deprecated
>>
>> Yes, as each release does 2+1 years. Which also means you've had 3 years
>> to address this in your code base(s) already.
>>
>> >I think making the error level of "Undefined index" configurable is a
>> very
>> >reasonable suggestion, and I support it.
>>
>> Adding a configuration setting to make this a notice on some
>> installations and not on others, would just mean that anything that needs
>> to be able to run everywhere needs to take care to not rely on the setting
>> either way, making it harder to develop portable code.
>>
>> We're also not generally anything near keen on adding settings that
>> change behaviour , and suggesting to add one to make a warning a notice
>> seems very far short of a bar that needs to be reached before many of us
>> would agree to add a setting to make PHP less portable.
>>
>> Alternatively you can just fix your code.
>>
>> >Are we able to revisit this topic as a community and potentially bring in
>> >more PHP developers from around the world to weigh in?
>>
>> You're always free to follow the RFC process, but I think you'll just up
>> wasting your, and everybody else's, time with it.
>>
>> I can't see this being reversed, nor a setting added for, through an RFC
>> process.
>>
>> cheers
>> Derick
>>
>>

--0000000000008ae0ba05efb7d5ed--