On 23/02/2022 23:03, Mark Randall wrote:
On 23/02/2022 19:32, Rowan Tommins wrote
I think that wording change should be part of the proposed change in
the RFC. Otherwise, a lot of people simply won't know the decision to
remove it has been made and will be surprised when 9.0 comes around.
It
On 24/02/2022 02:31, Bob Weinand wrote:
However, should your RFC pass, it is not possible to say "hey, I generally consider
this a low impact class of errors, please try to continue".
This is correct.
As the custodians of the language, it is our responsibility to decide
what the engine
Hey Mark,
For me, there's a fundamental shortcoming of this proposal:
- You cannot opt out.
Currently, as you describe in your RFC, it is perfectly possible, to opt into
making this category of errors fail hard (throw an exception in an error
handler).
However, should your RFC pass, it is not
On 23/02/2022 19:32, Rowan Tommins wrote
I think that wording change should be part of the proposed change in the
RFC. Otherwise, a lot of people simply won't know the decision to remove
it has been made and will be surprised when 9.0 comes around.
It is already part of the RFC within the
On 23/02/2022 18:42, Mark Randall wrote:
It may be that in 8.2 if this RFC passes that message will change to
include "This will throw an error in PHP 9"
I think that wording change should be part of the proposed change in the
RFC. Otherwise, a lot of people simply won't know the decision to
On 23/02/2022 18:02, Nicolas Grekas wrote:
I mean in addition yes, deprecation before warning.
I don't see this happening.
An engine warning is as stark a mechanism as we have available that you
either made a mistake, or shouldn't be doing something, without
preventing you from actually
Yeah, please don't: yet another side effect, deep in some `vendor` cruft.
Just stop it, please: I almost have PTSD from 8.1.
On Wed, 23 Feb 2022, 19:02 Nicolas Grekas,
wrote:
> Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a
> écrit :
>
> > On 23.02.2022 at 16:29, Nicolas Grekas wrote:
>
Le mer. 23 févr. 2022 à 17:59, Christoph M. Becker a
écrit :
> On 23.02.2022 at 16:29, Nicolas Grekas wrote:
>
> > Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a
> écrit :
> >
> >> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
> >> nicolas.grekas+...@gmail.com> wrote:
> >>
> >>> But this
On 23.02.2022 at 16:29, Nicolas Grekas wrote:
> Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit :
>
>> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
>> nicolas.grekas+...@gmail.com> wrote:
>>
>>> But this makes me think: we should trigger a deprecation just before all
>>> corresponding
Le mar. 22 févr. 2022 à 14:56, Marco Pivetta a écrit :
> On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas <
> nicolas.grekas+...@gmail.com> wrote:
>
>>
>> But this makes me think: we should trigger a deprecation just before all
>> corresponding warnings!
>>
>
> Please, no more deprecation
On Tue, Feb 22, 2022 at 2:53 PM Nicolas Grekas
wrote:
>
> But this makes me think: we should trigger a deprecation just before all
> corresponding warnings!
>
Please, no more deprecation warnings, make it stop
Yes, undefined variables are a problem, but I just spent 6 months in
`vendor/` code
Le mar. 22 févr. 2022 à 12:07, Mark Randall a écrit :
> On 22/02/2022 09:15, Nicolas Grekas wrote:
> > I very much call for an implementation to be provided before starting any
> > vote on the topic btw.
> The RFC states on its first line that accessing an undefined variable
> emits an
I have tried to no avail to be removed from this list. So I will just spam
this until I am removed.
On Tue, Feb 22, 2022, 3:15 AM Nicolas Grekas
wrote:
> Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a
> écrit :
>
> > On 17/02/2022 23:28, Mark Randall wrote:
> > > I present:
> > >
> > >
On 18/02/2022 11:23, Rowan Tommins wrote:
- undefined array keys
- undefined object properties
- array access on a non-array
- property access on a non-object
I'd encourage those to be discussed, but they are unrelated to this RFC.
I think most of them would pass fairly easily, but undefined
On 22/02/2022 09:15, Nicolas Grekas wrote:
I very much call for an implementation to be provided before starting any
vote on the topic btw.
The RFC states on its first line that accessing an undefined variable
emits an E_WARNING. If it does not currently emit an E_WARNING then it
is out of
Le ven. 18 févr. 2022 à 12:24, Rowan Tommins a
écrit :
> On 17/02/2022 23:28, Mark Randall wrote:
> > I present:
> >
> > https://wiki.php.net/rfc/undefined_variable_error_promotion
>
>
> It would be good to have a "Scope" or "Unaffected Functionality" section
> here, because there are a number
kef>
From: Rowan Tommins
Sent: Friday, February 18, 2022 2:56:07 PM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] Undefined Variable Error Promotion
On 18/02/2022 12:31, Mark Randall wrote:
> I would claim that the unary operators behave slightly
On 18/02/2022 12:31, Mark Randall wrote:
I would claim that the unary operators behave slightly different, if
it were a case of cooerce to zero, the behaviour of null++ and null--
would be expected to be the same as operating on 0, but it's not.
null++ is allowed, but null-- returns null, and
On 18/02/2022 10:50, Rowan Tommins wrote:
Other than an optimised implementation, there's nothing particularly
special about the ++ operator's handling of null, it behaves the same as
any other arithmetic operator:
I would claim that the unary operators behave slightly different, if it
were
On 17/02/2022 23:28, Mark Randall wrote:
I present:
https://wiki.php.net/rfc/undefined_variable_error_promotion
It would be good to have a "Scope" or "Unaffected Functionality" section
here, because there are a number of closely related things which were
also raised from Notice to Warning
On 18/02/2022 08:51, Mark Randall wrote:
The only reason this works at all is because an undefined variable
read falls back to null, and the increment operator is hardcoded to
treat null++ as 1.
Other than an optimised implementation, there's nothing particularly
special about the ++
On 18/02/2022 07:48, Robert Landers wrote:
Just out of curiosity, why is the 3rd case being included here? Is it just
because it's currently a warning > When I first taught PHP in 2011, I was told
> post-increment/decrement was sugar for `isset($var) ? $var + 1 : 1`
This is not the case,
Hi Mark,
Just out of curiosity, why is the 3rd case being included here? Is it just
because it's currently a warning? The current behavior is well documented
and known since ... forever? When I first taught PHP in 2011, I was told
post-increment/decrement was sugar for `isset($var) ? $var + 1 :
Internals,
Following on from my previous thread, I think we are now in a position
where we can begin formal discussions on an RFC to promote undefined
variables to Error exceptions in PHP 9.0.
I present:
https://wiki.php.net/rfc/undefined_variable_error_promotion
I still intend to bring
24 matches
Mail list logo
