Greetings, internals!
In my practice, it is a very common case when I need to create an
associative array with varying structure, by that meaning that some
fields in the array are optional and are set conditionally. And of all
conditions the most frequent is checking for null-values: if the value
is null, then this field should be omitted from the final result.
Unfortunately, PHP currently does not offer any shorthand syntax for
declaring such fields in a compact way. In most cases for each of such fields
we need to have a dedicated "if", like:
// $array is first filled with all required fields
// Then we add all optional fields based on some condition
if ($value !== null) {
$array['field'] = $value;
}
This often leads to cumbersome code.
My proposal, which already has a prototype implementation, is following.
When declaring an associative array, add a new null-coalescing double
arrow for the fields which should be omitted if the value is null:
$array = [
'field1' => $param1,
'field2' => $param2,
'field3' ?=> $param3,
];
In this case, if $param3 === null, the created array would only
contain 'field1' and 'field2' from start, without the need to later
get rid of 'field3'.
This syntax will also allow more generalized conditions. For example,
instead of:
if ($someCondition) {
$array['field'] = $value;
}
You could create such array from start, if you are OK with such code-style:
$array = [
// other fields
'field' ?=> $someCondition ? $value : null,
];
The token '?=>' given here is mainly just an example, because the
exact form should be discussed anyway (this one, as well as others,
have pros and cons).
So, before I create an RFC for this feature, I would like to get
initial feedback: would this feature be welcome in general?
Prototype implementation for it:
https://github.com/Amegatron/php-src/tree/conditional-array-elements
Or just the diff with current master:
https://github.com/php/php-src/compare/master...Amegatron:php-src:conditional-array-elements
This is still a prototype though, some additional work must be done of
course, not counting the tests.
A slightly bigger example:
https://gist.github.com/Amegatron/06da8770e46e116b05f1c290cb0d56fc
Looking forward to your feedback.
Cheers,
Alexander Egorov.
Greetings, internals!
In my practice, it is a very common case when I need to create an
associative array with varying structure, by that meaning that some
fields in the array are optional and are set conditionally. And of all
conditions the most frequent is checking for null-values: if the value
is null, then this field should be omitted from the final result.Unfortunately, PHP currently does not offer any shorthand syntax for
declaring such fields in a compact way. In most cases for each of such fields
we need to have a dedicated "if", like:// $array is first filled with all required fields
// Then we add all optional fields based on some condition
if ($value !== null) {
$array['field'] = $value;
}This often leads to cumbersome code.
My proposal, which already has a prototype implementation, is following.
When declaring an associative array, add a new null-coalescing double
arrow for the fields which should be omitted if the value is null:$array = [
'field1' => $param1,
'field2' => $param2,
'field3' ?=> $param3,
];In this case, if $param3 === null, the created array would only
contain 'field1' and 'field2' from start, without the need to later
get rid of 'field3'.This syntax will also allow more generalized conditions. For example,
instead of:if ($someCondition) {
$array['field'] = $value;
}You could create such array from start, if you are OK with such code-style:
$array = [
// other fields
'field' ?=> $someCondition ? $value : null,
];The token '?=>' given here is mainly just an example, because the
exact form should be discussed anyway (this one, as well as others,
have pros and cons).So, before I create an RFC for this feature, I would like to get
initial feedback: would this feature be welcome in general?Prototype implementation for it:
https://github.com/Amegatron/php-src/tree/conditional-array-elementsOr just the diff with current master:
https://github.com/php/php-src/compare/master...Amegatron:php-src:conditional-array-elementsThis is still a prototype though, some additional work must be done of
course, not counting the tests.A slightly bigger example:
https://gist.github.com/Amegatron/06da8770e46e116b05f1c290cb0d56fcLooking forward to your feedback.
Cheers,
Alexander Egorov.
My first thought is that the current code, which assigns potentially null values, works fine if you throw an array_filter() at it at the end.
$array = [
'field1' => $param1,
'field2' => $param2,
'field3' => $param3_which_is_null,
];
$a = array_filter($array);
// $a now omits the null fields
My second thought is that this is yet another reason why using associative arrays as if they were a data structure is wrong and should be avoided; just use a class and everything will be fine. If you need to serialize it later, there's many serializers on the market if JsonSerialize isn't sufficient.
So this doesn't seem like a worthwhile addition to me.
--Larry Garfield
Thanks for the feedback!
пт, 29 мая 2026 г., 19:06 Larry Garfield larry@garfieldtech.com:
My first thought is that the current code, which assigns potentially null values, works fine if you throw an
array_filter()at it at the end.$array = [
'field1' => $param1,
'field2' => $param2,
'field3' => $param3_which_is_null,
];$a = array_filter($array);
// $a now omits the null fields
array_filter will only cover the cases when you need to filter all
fields by the same criteria (null's in this case).
But it does not fit the case when you still have some mandatory fields
even if they are null, but some are optional.
At least in the simplest form, but otherwise in more complex forms
we'll still come up with additional code.
My second thought is that this is yet another reason why using associative arrays as if they were a data structure is wrong and should be avoided; just use a class and everything will be fine. If you need to serialize it later, there's many serializers on the market if JsonSerialize isn't sufficient.
Wrong or not, using arrays as an intermediate for serializing is still
very common.
Also, it is a common case when developers have their in-house
serialization mechanisms.
But whatever serialization you use, the serialization library by itself will
still need to perform corresponding "if"'s or other logic to
conditionally include/exclude the fields.
So, such feature can prove useful for serialization libraries themselves.
Another thing is that we don't only work with production-ready code
which presumably already
has or should have a proper "infrastructure" for serialization. We can
still work with some draft
or MVP projects where we need to do things fast and simple first. And
such feature can prove handy.
array_filter will only cover the cases when you need to filter all
fields by the same criteria (null's in this case).
But it does not fit the case when you still have some mandatory fields
even if they are null, but some are optional.
At least in the simplest form, but otherwise in more complex forms
we'll still come up with additional code.
A data format that has a mix of required-even-if-null and optional fields is a broken data format. We should not design language features around a broken data format. (I realize that the broken data format is often provided by a 3rd party, not the PHP developer, so it's not the PHP developer's fault that the data format is broken. But the point stands that we should not build around that.)
My second thought is that this is yet another reason why using associative arrays as if they were a data structure is wrong and should be avoided; just use a class and everything will be fine. If you need to serialize it later, there's many serializers on the market if JsonSerialize isn't sufficient.
Wrong or not, using arrays as an intermediate for serializing is still
very common.
Also, it is a common case when developers have their in-house
serialization mechanisms.But whatever serialization you use, the serialization library by itself will
still need to perform corresponding "if"'s or other logic to
conditionally include/exclude the fields.
So, such feature can prove useful for serialization libraries themselves.Another thing is that we don't only work with production-ready code
which presumably already
has or should have a proper "infrastructure" for serialization. We can
still work with some draft
or MVP projects where we need to do things fast and simple first. And
such feature can prove handy.
Disclosure: I am the author of Crell/Serde, one of the aforementioned serialization libraries. It's also super easy to just "drop into" a project and start using, even without wiring it into a container or anything. And I wouldn't make use of this feature, as it doesn't fit the way Serde works to begin with.
--Larry Garfield
array_filter will only cover the cases when you need to filter all
fields by the same criteria (null's in this case).
But it does not fit the case when you still have some mandatory fields
even if they are null, but some are optional.
At least in the simplest form, but otherwise in more complex forms
we'll still come up with additional code.A data format that has a mix of required-even-if-null and optional fields is a broken data format. We should not design language features around a broken data format. (I realize that the broken data format is often provided by a 3rd party, not the PHP developer, so it's not the PHP developer's fault that the data format is broken. But the point stands that we should not build around that.)
I generally agree with you about broken data formats, but I think it does not
really relate to the language feature itself. The reason and motivation why I'm
suggesting this feature is not to promote building around broken data formats,
but to have a convenient syntax for what is anyway being done more or
less often.
It is always developer's decision or necessity to do things this or that way,
and PHP anyway (as any other language) allows developers to have whatever
data-structures they want without obligation to do things "right", because
"right" is often very relative. The language is first and foremost an
instrument.
Specifically, associative arrays by themselves are completely
decoupled from what
exactly they are used for, and PHP anyway allows to dynamically add or
remove (unset)
keys from them. So, the feature I'm suggesting is about having a more convenient
tool for that, and not about building around bad data formats.