On Wed, Jun 26, 2024, at 21:50, Morgan wrote: > On 2024-06-26 09:58, Rob Landers wrote: > > On Tue, Jun 25, 2024, at 23:10, Rowan Tommins [IMSoP] wrote: > >> > >> > >> 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. > > > So the issue has nothing to do with this hypothetical infinity of > unobservable nulls, and comes entirely down to the fact that with this > pattern a variable may pass > a) because it does not have a key named 'foo', or > b) because it has a key named 'foo' with a string value.
I think this will be my last email on the subject because it’s like talking to a brick wall. There’s nothing hypothetical about it. while(true) var_dump([][random_int()]); > > In other words, "this key is optional, but if it is defined it must > match this pattern". Seriously, write out using it both ways. I asked in the beginning for someone to give a realistic example showing a practical difference in the final implementation and I haven’t seen one. I will gracefully eat my hat. The main issue is that key-existence-check is logically inconsistent with itself (if you say the key shouldn’t exist or be a string, you’d be surprised to get null from that key!) And with that, I bid adieu to this topic. > > On its lonesome, that doesn't look very useful, but I expect it would be > one component of a larger pattern (such as "['bar' => string, ?'foo' => > string, ...]"). Rather than (near-)duplicate blocks for "it does not > have the key" and "it has the key and it holds a string", there can be > one block (which might or might not care about the distinction). > — Rob
