[PHP-DEV] var_export array syntax

Mailing Lists php.internals
1

Hi!

I'm a seasoned PHP developer (started around when PHP 2 was still in use), yet this is the first time I'm getting involved beyond documentation fixes. I have ~0 knowledge in the internals, so bear with me.

Since I've been around that long, I've seen PHP evolve steadily. But one thing I kept asking myself was why the old array syntax is still promoted by some parts of user-facing functions, namely var_export. That happens to for example be used by tools like PhpStorm/Xdebug to copy current contents of variables while debugging.

My personal preferences (deprecate/kill the old array syntax altogether) aside, I wonder what the path forward is and what blocks it. RFC var-export-array-syntax has been created 6 years ago but I cannot see why it stalled, esp. since it seems to be confined to a very specific part of the source code.

I remember to have read somewhere that the current syntax is used in many phpt files which would have to be adapted. Given the current day and age, that sounds like something that AI would do while asleep. So what else would be an issue?

So I thought I'd ask here first before creating yet another RFC that might go stale just as quickly as the existing one.

My concrete proposal:
1. add a (user) config switch that allows to enable var_dump to use the new array syntax, off by default in whichever PHP version this land first (e.g. 8.6 if it's not too late already). phpt files can stay as is, but a new test for when the switch is On would be needed.
2. switch the default to On in a later PHP version (9.0 the latest), then adapting the phpt files
3. first deprecate and then remove the config switch in even later versions

WDYT?

Greetings,

Jens

2

On Thu, Aug 13, 2026, at 1:25 PM, dev@hatlak.de wrote:

Hi!

I'm a seasoned PHP developer (started around when PHP 2 was still in
use), yet this is the first time I'm getting involved beyond
documentation fixes. I have ~0 knowledge in the internals, so bear with
me.

Since I've been around that long, I've seen PHP evolve steadily. But
one thing I kept asking myself was why the old array syntax is still
promoted by some parts of user-facing functions, namely var_export.
That happens to for example be used by tools like PhpStorm/Xdebug to
copy current contents of variables while debugging.

My personal preferences (deprecate/kill the old array syntax
altogether) aside, I wonder what the path forward is and what blocks
it. RFC var-export-array-syntax has been created 6 years ago but I
cannot see why it stalled, esp. since it seems to be confined to a very
specific part of the source code.

I remember to have read somewhere that the current syntax is used in
many phpt files which would have to be adapted. Given the current day
and age, that sounds like something that AI would do while asleep. So
what else would be an issue?

So I thought I'd ask here first before creating yet another RFC that
might go stale just as quickly as the existing one.

My concrete proposal:
1. add a (user) config switch that allows to enable var_dump to use the
new array syntax, off by default in whichever PHP version this land
first (e.g. 8.6 if it's not too late already). phpt files can stay as
is, but a new test for when the switch is On would be needed.
2. switch the default to On in a later PHP version (9.0 the latest),
then adapting the phpt files
3. first deprecate and then remove the config switch in even later
versions

WDYT?

Greetings,

Jens

Without stating an opinion on the matter, here's some prior discussions of the topic:

--Larry Garfield

3

On Thu, 13 Aug 2026 at 19:25, <dev@hatlak.de> wrote:

Hi!

I'm a seasoned PHP developer (started around when PHP 2 was still in use), yet this is the first time I'm getting involved beyond documentation fixes. I have ~0 knowledge in the internals, so bear with me.

Since I've been around that long, I've seen PHP evolve steadily. But one thing I kept asking myself was why the old array syntax is still promoted by some parts of user-facing functions, namely var_export. That happens to for example be used by tools like PhpStorm/Xdebug to copy current contents of variables while debugging.

My personal preferences (deprecate/kill the old array syntax altogether) aside, I wonder what the path forward is and what blocks it. RFC var-export-array-syntax has been created 6 years ago but I cannot see why it stalled, esp. since it seems to be confined to a very specific part of the source code.

I remember to have read somewhere that the current syntax is used in many phpt files which would have to be adapted. Given the current day and age, that sounds like something that AI would do while asleep. So what else would be an issue?

So I thought I'd ask here first before creating yet another RFC that might go stale just as quickly as the existing one.

My concrete proposal:
1. add a (user) config switch that allows to enable var_dump to use the new array syntax, off by default in whichever PHP version this land first (e.g. 8.6 if it's not too late already). phpt files can stay as is, but a new test for when the switch is On would be needed.
2. switch the default to On in a later PHP version (9.0 the latest), then adapting the phpt files
3. first deprecate and then remove the config switch in even later versions

WDYT?

Greetings,

Jens

Hi Jens,

IMHO, the two main reasons for the lack of change are apathy and lack
of agreement as to what exactly the better syntax is. There have been
multiple proposals to change this. There was also
PHP: rfc:readable_var_representation RFC, which was
rejected.

The var_export() function is supposed to be PHP-executable first, and
human-readable second. So as long as the code can be understood by
humans, copied into a PHP file and executed, the function works as
designed. As long as the old array syntax is available in PHP, the
var_export() function doesn't require any changes. So why change
anything if the format doesn't matter?

Secondly, whenever the output of var_export is mentioned, people start
complaining about how many things look "wrong" in its output. If we
only change the output to use short array syntax, people will ask why
this change was made and not the others. Because of this, a new
function was proposed as a better option, not without its own
bikeshedding.

I think a lot of PHP developers would welcome the change to
var_export's output, but first you would have to provide solid
arguments for the above two points.

Regards,
Kamil