# Proposal: Shorthand initialization and destructuring of associative arrays

- Thread: https://externals.io/message/116177
- Original archive: https://news-web.php.net/php.internals/116177
- Started by Konrad Baumgart on 2021-09-27T09:27:02+00:00
- Messages: 5
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #116177 — Konrad Baumgart — 2021-09-27T09:27:02+00:00

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

Hi everyone,

I'd like to propose 2 syntactic sugars:
$array = [ => $data]; // the same as $array = ['data' => $data]
and
[ => $data] = $array; // the same as ['data' => $data] = $array

My biggest use-case for this would be conveniently returning multiple
things from a function, like:

function getDataForDashboard() {
  …
  return [ => $dailyAggregations, => $weeklyAggregations];
}

[ => $dailyAggregations, => $weeklyAggregations] = getDataForDashboard();

Similar effects can be achieved with `compact()`/extract() functions,
but I dislike those functions because they make it hard to find usages
of variables. Using numerical arrays instead makes the code less
readable and more error-prone for me. Using ['dailyAggregations' =>
$dailyAggregations,…] would force you to split code into multiple
lines and negatively affect readability.

I was recently developing with js/ts and I liked the ease of returning
multiple items from a function as an object, while still preserving
their name.

I have spare time this October, so I would happily get into php
interpreter by developing this.

I'm looking forward for your feedback,
Konrad Baumgart

---

## #116178 — Lynn — 2021-09-27T12:07:13+00:00

URL: https://externals.io/message/116177#116178 · In reply to: #116177

> I was recently developing with js/ts and I liked the ease of returning
> multiple items from a function as an object, while still preserving
> their name.
>

I recently encountered this as well in Typescript. I believe the syntax is
something like this?
```js
const someProperty = "something";

const foo = {
    someProperty,
    anotherProperty: "Something else",
};

// same as
const foo = {
    someProperty: someProperty,
    anotherProperty: "Something else",
};
```
Obviously this won't work with PHP arrays, which is probably why you
decided for `=> $someProperty`.

I'm a big no-no when it comes to `compact()` and `extract()`. These
functions make my life hell. Despite knowing what they do, it still takes
me a lot of reading to try and figure out what they do. Even now I will
have to go to the documentation to understand exactly how either of them
work. Renaming a variable in a certain scope should not break something
outside of that scope, and I see this as a big problem in the proposal.
When I take your example, spot the error that will cause everything to
break runtime with limited static analysis to let you know (hint: missing a
g in the first variable).
```php
return [ => $dailyAgregations, => $weeklyAggregations];
```
Refactoring tools could just ignore the outside scope and automatically
change it, yet this won't solve anything for text find and replace.
```php
return [
    'dailyAggregations' => $theNewVariableName,
    => $weeklyAggregations,
];
```

If something like this were to be introduced, I'd happily see it happen
with anonymous objects and interfaces accepting properties:

```php
interface DashboardAggregations
{
    public readonly array $dailyAggregations;
    public readonly array $weeklyAggregations;
}

function getDashboardData() : DashboardAggregations
{
    $dailyAggregations = [];
    $weeklyAggregations = [];

    // ...
    return {
        $dailyAggregations,
        $weeklyAggregations,
    };

    // same as
    return {
        dailyAggregations: $dailyAggregations,
        weeklyAggregations: $weeklyAggregations,
    };

    // same as (if properties in interfaces were allowed)
    return new class($dailyAggregations, $weeklyAggregations) implements
DashboardAggregations {
        public function __construct(
            public readonly array $dailyAggregations,
            public readonly array $weeklyAggregations,
        ) {}
    };
}
```
If you then really need the destructuring, you could do something like this
(just a random syntax chosen), though I'd still be in favor of leaving this
aside as you now have a nice object with properties that are accessible.
```php
{$dailyAggregations, $weeklyAggregations} = getDashboardData();
```

This way php could verify the return value with the return type, and static
analyzers can determine the structure of what's to be returned. Imo this
functionality is not worth the headache with arrays.

That said, it feels like this proposal is more of a tuple/multiple return.

---

## #116210 — Nikita Popov — 2021-10-04T09:37:44+00:00

URL: https://externals.io/message/116177#116210 · In reply to: #116177

> Hi everyone,
>
> I'd like to propose 2 syntactic sugars:
> $array = [ => $data]; // the same as $array = ['data' => $data]
> and
> [ => $data] = $array; // the same as ['data' => $data] = $array
>
> My biggest use-case for this would be conveniently returning multiple
> things from a function, like:
>
> function getDataForDashboard() {
>   …
>   return [ => $dailyAggregations, => $weeklyAggregations];
> }
>
> [ => $dailyAggregations, => $weeklyAggregations] = getDataForDashboard();
>
> Similar effects can be achieved with `compact()`/extract() functions,
> but I dislike those functions because they make it hard to find usages
> of variables. Using numerical arrays instead makes the code less
> readable and more error-prone for me. Using ['dailyAggregations' =>
> $dailyAggregations,…] would force you to split code into multiple
> lines and negatively affect readability.
>
> I was recently developing with js/ts and I liked the ease of returning
> multiple items from a function as an object, while still preserving
> their name.
>
> I have spare time this October, so I would happily get into php
> interpreter by developing this.
>
> I'm looking forward for your feedback,
> Konrad Baumgart
>

I'm generally in favor of this functionality. Unfortunately the syntax
options we have for this are not as nice as in other languages. [=> $x] is
probably the most reasonable choice where array literals are concerned.
https://wiki.php.net/rfc/named_params#shorthand_syntax_for_matching_parameter_and_variable_name
also has some thoughts on this topic, as named params have the same problem.

Regards,
Nikita

---

## #116219 — Konrad Baumgart — 2021-10-04T19:15:13+00:00

URL: https://externals.io/message/116177#116219 · In reply to: #116178

> I have spare time this October, so I would happily get into php interpreter by developing this.
Unfortunately my plans to have spare time FAILED and I'm not able to
contribute in the near future.

> If something like this were to be introduced, I'd happily see it happen with anonymous objects and interfaces accepting properties:
Using classes/interfaces rather than associative arrays is superior in
'enterprise' projects, but sometimes I just want to quickly return
tuple or construct json response.

> This way php could verify the return value with the return type, and static analyzers can determine the structure of what's to be returned. Imo this functionality is not worth the headache with arrays.
We recently got #[ArrayShape]. Maybe associative arrays will get more
love from static analyzers and will be suitable for 'tuple returns'.

---

## #116221 — Sara Golemon — 2021-10-04T20:14:11+00:00

URL: https://externals.io/message/116177#116221 · In reply to: #116219

> > […]
> interpreter by developing this.
> Unfortunately my plans to have spare time FAILED and I'm not able to
> contribute in the near future.
>
>
I'm procrastinating writing slides for Longhorn, so here's a quick and
dirty implementation to work with:
https://github.com/sgolemon/php-src/commit/4156d9d989314b2d60d1031ab9e02faaefa248f9

Not actually sure it's got value, but you shouldn't be held back from
proposing it by a lack of implementation.

-Sara