On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote: > > > On 25 June 2024 21:24:32 BST, Rob Landers <rob@bottled.codes> wrote: > >The only way you’d observe this (that I can think of) is by performing a > >for-each loop over the array. > > There are many ways you can observe the difference between an absent key and > a null value; here are just a handful off the top of my head: > > - array_key_exists() (that's literally its purpose!) > - array_keys() > - count() (if the array held "an infinite number of nulls", we should return > infinity for every array!) > - json_encode() > - print_r(), var_dump(), var_export() > - extract() > > It may be questionable to give meaning to the difference in some of these > cases, but different it definitely is.
True, but I was mainly referring to what you would do after performing an 'is', in which case, you probably wouldn't be using any of those functions, or if you needed to, then why do you need 'is'? Even with the $hasFoo = $arr is [?'foo' => string]; You still have to run array_key_exists() to determine whether the key exists, which means you likely still need to figure out a default value, and null-coalesce is perfect for that ... but then it just points out that it isn't that useful of a check, and that it is inconsistent with itself. If you are running array_keys(), then why bother performing an 'is' when you should already know the structure—that's the entire point of it. If you are running a count(), this kind of goes back to the same thing, but I would think count() would be run on a collection of data rather than structured data. For json_encode, I could see something like this being a "final check" of some sort, but most people are likely json_encoding objects these days. This might be a good use case for this syntax, but I feel like this is the wrong way to solve the problem. print_r, var_dump, etc. are more or less debugging tools. At least, I've never seen their output used for program execution. I could be wrong. extract() can go get crushed by an RFC :) but it does occasionally have its usefulness. Even then, until PHP 9, an undefined variable will still be null. > > > > If we don't like it, we can always create an RFC to treat non-existent keys > > as an error instead of a warning. > > I believe that is the explicit intention or desire of those who raised it > from Notice to Warning. It would certainly prevent some bugs where a typo > leads to the wrong key being accessed. > > Personally, I'd like to see a few use cases catered for first, like > $counters[$key]++ and $groups[$key][] = $value; Perhaps by introducing some > equivalent of Python's "defaultdict". Because I do agree that the current > behaviour is useful sometimes (even if I disagree in how to describe it). I think arrays have their uses, but I'd rather see some purpose-built data structures where you can fully take advantage of their performance properties—things like linked lists, heaps, etc. Yeah, there's SPL, but its interfaces are kind of a mess since you can use a queue like a deque or a stack (which is just weird and might or might not have performance implications), for example. > > > Regards, > Rowan Tommins > [IMSoP] > — Rob
