Hi Rob
On Tue, Jun 25, 2024 at 9:05 AM Rob Landers <[email protected]> wrote:
>
> On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote:
>
> On Mon, Jun 24, 2024 at 9:54 PM Robert Landers <[email protected]> wrote:
> >
> > To be honest, this is one of the smaller concerns I have with the new
> > syntax. There might be some misunderstanding here, though. A
> > non-existent key is NULL, always has been, and always will be.
>
> This is just not accurate. Inexistent indexes are not null in PHP,
> they are undefined. PHP implicitly coerces undefined to null, because
> undefined is not a value accessible to users. The same occurs when
> accessing $undefinedVariable. For arrays, this fact is observable
> through foreach, warnings when accessing the index, and likely
> others.
>
> This is a bit like telling someone who fell off a ladder that they didn’t “technically”
> fall, instead the Earth and them pulled at each other until they collided and the ground + body
> absorbed the energy.
>
> While yes, you are “technically” correct, what you describe is essentially unobservable
> from the context of the running code (unless you turn the warning into an error/exception). For all
> direct accesses of array values ($arr['key']) an array is infinitely full of nulls (I have
> actually depended on this property at one point for a bloom filter).
If null array values were indeed unobservable, then [] would be === to
[null] (or at least ==), and a foreach over [null] would result in 0
iterations. But neither of those are the case.
> So yes, [?'foo' => string] and ['foo' =>
> ?string] are indeed
> different. The former accepts [], while the latter accepts `['foo'
> => null]`.
>
> Are they actually different in practice though? That was my point. After the “is” in both
> cases, you’ll have to use null-coalescence to retrieve the value. For all intents, they are the
> same resulting code. If you can show a difference in the resulting code and how it is an
> improvement, I may be inclined to agree, but I can’t think of one.
Sure. If a null value were to mean "not set", then ['foo' => string]
should accept ['foo' => 'foo', 'bar' => null], which is
absolutely
observable if the code assumes it won't see any additional indexes.
Ilija