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. So yes, `[?'foo' => string]` and `['foo' => ?string]` are indeed different. The former accepts `[]`, while the latter accepts `['foo' => null]`. > $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
