# Preventing `isset` from complaining about stuff inside square brackets not being set

- Thread: https://externals.io/message/132174
- Original archive: https://news-web.php.net/php.internals/132174
- Started by Juris Evertovskis on 2026-08-05T18:12:26+00:00
- Messages: 1
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #132174 — Juris Evertovskis — 2026-08-05T18:12:26+00:00

URL: https://externals.io/message/132174#132174

Hello, list!

 

I?d like to do a little temperature check on the behaviour of `isset`.

 

Currently `isset($maybeObject->optionalKey)` returns `true` or `false`
without any warnings if

1. `$maybeObject->optionalKey` is `193`

2. `$maybeObject->optionalKey` is `null`

3. `$maybeObject` is an object that doesn?t have the `optionalKey` field

4. `$maybeObject` is `null`

5. `$maybeObject` is undefined

6. `$maybeObject` is a string, array, whatev?

 

In my understanding a key idea in the design of `isset` was that it is there
so you could check whether the whole `$result->athlete->name` will produce
something showable instead of having to step by step verify `isset($result,
$result->athlete, $result->athlete->name)`. And it does the same for arrays
supporting arbitrary level of key depth.

 

This fails inside array access, i.e. `$array[$maybeObject->optionalKey]`.
Now the cases from above work as follows

1.  `$maybeObject->optionalKey` is `193`

returns `true` or `false` and that?s it

2. `$maybeObject->optionalKey` is `null`

DEPRECATED  Using null as an array offset is deprecated, use an empty string
instead.

3. `$maybeObject` is an object that doesn?t have the `optionalKey` field

WARNING  Undefined property: stdClass::$optionalKey.

DEPRECATED  Using null as an array offset is deprecated, use an empty string
instead.

4. `$maybeObject` is `null`

WARNING  Attempt to read property "optionalKey" on null.

DEPRECATED  Using null as an array offset is deprecated, use an empty string
instead.

5. `$maybeObject` is undefined

WARNING  Undefined variable $maybeObject.

WARNING  Attempt to read property "optionalKey" on null.

DEPRECATED  Using null as an array offset is deprecated, use an empty string
instead.

6. `$maybeObject` is a string, array, whatev?

WARNING  Attempt to read property "b" on array.

DEPRECATED  Using null as an array offset is deprecated, use an empty string
instead.

 

It?s also a bit inconsistent in that the DEPRECATED warning goes away if
`$array` itself is undefined or a bool/number/string. Or gets replaced with
an error if `$array` is an object.

 

To me it looks like `isset` is not doing its job. I?d expect
`isset($array[$maybeObject->optionalKey])`to return without complaints and I
expect the `??` to not complain either if the verifiable contents was empty.

 

When I?m putting stuff into an array, it?s significant the `$array[null]`
and `$array['']` override each other. When I?m extracting contents the info
that `$array[$someKey]` is empty is enough. The cast might matter if the
result is non-empty, but I don?t care that the impossible `null` key got
casted to an undefined `''` one. Having to check `$someKey` separately seems
to betray the idea of `isset`.

 

I would like to propose warnings/deprecations from array access inside an
`isset`. To make the stuff inside square brackets behave just as silently as
if it was wrapped in an `isset` itself.

 

What do you think?

 

BR,

Juris