> On 29/12/2021 16:58, Lynn wrote: > > While I'd love for this inconsistency to go away, I also know that this > is > > most likely such a big change that it causes months of work and broken > code > > because it relies on this behavior. It wouldn't surprise me if this > > singular change would cause more work than all previous BC breaks > combined. > > > I was about to say the same thing - this is one of those ingrained > behaviours that is very hard to analyse use of without running the code, > so only someone with an extraordinarily good test suite would detect > that their code was affected before it went live. > > I encounter this issue with an array of zipcode as key, and let's say some delay as int: ['00001' => 2, '00002' => 5, ..., '10000' => 4, ... ]; If I want all the zipcode with a delay superior to 3, combining array_keys and array_filter will give me an array of string and int, instead of an array of only string ; like I would have expected.
Maybe a way to reduce the BC-break would be to say that - The type of the key won't change anymore i.e. array_search(0, ['10' => 0]) will be '10' and not 10. - $array[10] will return $array[10] ?? $array['10'] - $array['10'] will return $array['10'] ?? $array[10] This would avoid the issue with $products[$_GET['id']] VS $products[(int)$_GET['id']] and still be a first step in the improvement of this situation.
