On Tue, Jun 25, 2024, at 01:20, Ilija Tovilo wrote: > On Mon, Jun 24, 2024 at 9:54 PM Robert Landers <landers.rob...@gmail.com> > wrote: > > > > > The first means b is an optional key, but if it’s there, can only be a > > > string. The second says b is a required key, but it may be a string or > > > null. If there were a binding involved, that determines the type of the > > > binding in incompatible ways. I’m fine with requiring bindings to be > > > nullable for optional keys, but it strikes me as strictly less flexible > > > and not consistent with the rest of PHP’s behavior, at least not under > > > E_ALL. > > > > > > > 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). > > 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. > > $arr = ['a' => 'a string']; > > $arr is ['a' => string, ?'b' => $value, ...]; > > > > This syntax implies that a non-existent key is a special case, and if > > it passes as-is, it will be. If there is a binding and the key is > > missing, what happens to that binding? > > This is the same problem as `|`. Variable bindings within optional > keys must be forbidden. I already mentioned that to Larry when we > thought about this idea. > > Ilija > — Rob
