This argument makes sense for arrays and objects (and I don't promote
> undefined index/property to exceptions for that reason), but I don't think
> it holds any water for simple variables. Writing @$counts[$key]++ is a lazy
> way to count values and avoid ugly boilerplate for if
> (isset($counts[$key])) { $counts[$key]++; } else { $counts[$key] = 1; }.
> But @$foo++ is just a really bad way of writing either $foo++ or $foo = 1.
> Outside of variable variables, the concept of a conditionally defined
> variable just doesn't make a lot of sense.
>
The variables are not conditionally declared on purpose, but as it's code
written 15~20 years ago, maintained, copy-pasted over and over and never
reviewed, there's a lot of issues that remain that my trigger an error
exception if this proposal is passed without migration path.
```
// a.php
if ($someCondition) { // comes from another file, never used, can't verify
existance
$foo = 'foo';
}
// b.php
$bar = 'bar';
// scenario1.php
include 'a.php'; // this would crash
include 'b.php';
echo $foo . $bar; // this would crash if the include didn't yet
// scenario2.php
$someCondition = true;
include 'a.php'; // this would not crash
include 'b.php';
echo $foo . $bar; // this would not crash
```
The problem with the above legacy code, which we sadly have spread through
a spaghetti of thousands of files, is that if it starts throwing errors
with no migration path, we simply can't update without spending possibly
weeks debugging and trying to find scenarios where this might trigger. Now
I'm not sure, but if I would've used `include_once` and combine this with
function/class scopes (people loved to do that in our legacy code), all
hell breaks loose and it will be nearly impossible to find the cases.
All I'm asking is for a clear upgrade path with deprecations so that my
code can be safely migrated over time, rather than have it crash with the
next version. Compared to <?php vs <?, this will break a lot and is not as
easy to fix. By having it throw deprecations which we can easily log to a
specific file, we can gather and fix the cases when we have time to spend
on technical debt, and by the time the warning will turn into an error
exception, we'll have fixed probably 90%+ of the cases, making the upgrade
possible.
Regards,
Lynn van der Berg
