I present:
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 in 8.0:
- undefined array keys
- undefined object properties
- array access on a non-array
- property access on a non-object
I think it is sensible to discuss those separately, but it would be good
to make that clear.
Similarly, it would be good to have more discussion of what "accessing"
means, as the current examples are quite narrow, only showing direct use
and the ++ operator. Other functionality potentially affected:
- passing the variable to a function, presumably excluding by-reference
parameters which don't currently warn - all the combined assignment operators -
https://www.php.net/manual/en/language.operators.assignment.php - the array append operator ($a[] = 42;) does NOT currently give an
undefined variable Warning - variable variables, e.g. "$b = 'a'; echo $$b;"
- the
compact()pseudo-function
There's probably others that I've missed.
Regards,
--
Rowan Tommins
[IMSoP]
Le ven. 18 févr. 2022 à 12:24, Rowan Tommins rowan.collins@gmail.com a
écrit :
I present:
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 in 8.0:
- undefined array keys
- undefined object properties
- array access on a non-array
- property access on a non-object
I think it is sensible to discuss those separately, but it would be good
to make that clear.Similarly, it would be good to have more discussion of what "accessing"
means, as the current examples are quite narrow, only showing direct use
and the ++ operator. Other functionality potentially affected:
- passing the variable to a function, presumably excluding by-reference
parameters which don't currently warn- all the combined assignment operators -
https://www.php.net/manual/en/language.operators.assignment.php- the array append operator ($a[] = 42;) does NOT currently give an
undefined variable Warning- variable variables, e.g. "$b = 'a'; echo $$b;"
- the
compact()pseudo-functionThere's probably others that I've missed.
I 100% agree with that. An "Unaffected Functionality" section would be much
welcome.
I would add to the list: isset($foo) when $foo is first seen.
(To me this should not throw anything, like for uninitialized properties.)
If the RFC is about promoting the current warnings to Error without adding
any other Error at places that currently don't throw any warnings, then it
could be useful to say so. And if the RFC is going to propose to throw
Error at places that are currently warning-less, the list should be
explicit.
I very much call for an implementation to be provided before starting any
vote on the topic btw.
This is typically the kind of topic where getting into the actual code
might help spot edge cases.
Thanks for the RFC btw!
Nicolas
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 anE_WARNINGthen it
is out of scope of this RFC.
It is not sensible to provide a full implementation for something that
will require extensive engine and test changes for something several
years into the future, during which many other changes will be made.
A sensible time for this would be after the branch is cut for 8.4.
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 nicolas.grekas+php@gmail.com
wrote:
Le ven. 18 févr. 2022 à 12:24, Rowan Tommins rowan.collins@gmail.com a
écrit :I present:
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 in 8.0:
- undefined array keys
- undefined object properties
- array access on a non-array
- property access on a non-object
I think it is sensible to discuss those separately, but it would be good
to make that clear.Similarly, it would be good to have more discussion of what "accessing"
means, as the current examples are quite narrow, only showing direct use
and the ++ operator. Other functionality potentially affected:
- passing the variable to a function, presumably excluding by-reference
parameters which don't currently warn- all the combined assignment operators -
https://www.php.net/manual/en/language.operators.assignment.php- the array append operator ($a[] = 42;) does NOT currently give an
undefined variable Warning- variable variables, e.g. "$b = 'a'; echo $$b;"
- the
compact()pseudo-functionThere's probably others that I've missed.
I 100% agree with that. An "Unaffected Functionality" section would be much
welcome.I would add to the list: isset($foo) when $foo is first seen.
(To me this should not throw anything, like for uninitialized properties.)If the RFC is about promoting the current warnings to Error without adding
any other Error at places that currently don't throw any warnings, then it
could be useful to say so. And if the RFC is going to propose to throw
Error at places that are currently warning-less, the list should be
explicit.I very much call for an implementation to be provided before starting any
vote on the topic btw.
This is typically the kind of topic where getting into the actual code
might help spot edge cases.Thanks for the RFC btw!
Nicolas
- 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 array keys
is out the outlier and has a reasonable chance of being rejected at this
time. However, with their being 4 years before the launch of 9.0 (and
the next opportunity to change it) opinion may change between now and then.
I've updated the RFC to define accessing a variable as attempting to
read its value for use in an expression without accounting for the
possibility of it being unset.
I have also included the warning message to narrow this down further,
and noted that things which account for undefined variables such as
isset, empty and null coalesce will remain unaffected.
If there's am existing formal definition someone wishes to contribute,
I'd be happy to update it.
One thing maybe worth mentioning is that while most operators such as
++, +=, .= etc will be covered by this change, $undefined[] = 1; will
not be.
Mark Randall