The PER 3.1 migration document states in section 11:
The opening bracket of a multiline array MUST NOT be placed on its own line. This rule applies to arrays in all contexts, not only assignments. For example:
<?php
return [
'foo',
'bar',
];
someFunction([
'foo',
'bar',
]);
And the section 11 of the spec states
When an array declaration is split across multiple lines, the opening bracket MUST NOT be placed on its own line.
But the example shown violates this already with the 2nd nested array as in
$arr2 = [
'multi',
'line',
'declaration',
['values' => 1, 5, 7],
[
'nested',
'array',
],
];
This gets even worse when combined with call argument rules in section 4.7:
Argument lists MAY be split across multiple lines, where each subsequent line is indented once. When doing so, the first item in the list MUST be on the next line, and there MUST be only one argument per line. A single argument being split across multiple lines (as might be the case with a closure or array) does not constitute splitting the argument list itself.
A multi-argument call written in multi-line style always violates either rules of section 4.7 or 11:
someFunction(
$baz, [
'foo',
'bar',
],
);I think what the addendum in PER 3.1 wants to say is that an array written in multi-line style needs to be treated as a compact single-line item when applying other rules. "Compact single-line item" is no term specified yet and there might be better ones to describe this, but basically similar to a scalar or a variable etc.
This automatically fixes the nested array example in section 11 and its in line with the example shown in the PER 3.1 diff section 11
someFunction([
'foo',
'bar',
]);if this is interpreted as a function call in single-line style.
This is also in line with the example showing a multi-argument call in single-line style in section 4.7:
somefunction($foo, $bar, [
// ...
], $baz);As a consequence, it would clarify the ambiguity in multi-argument calls in multi-line style to be
someFunction(
$baz,
[
'foo',
'bar',
],
);but also (!):
someFunction(
[
'foo',
'bar',
],
$baz,
);It would also mean that a single-argument call written in multi-line style such as
someFunction(
$someVar,
);(which is valid according to PER) still enables to write
someFunction(
[
'foo',
'bar',
],
);unless there is a rule enforcing to write single-array-argument calls in single-line style always...
The PER 3.1 migration document states in section 11:
And the section 11 of the spec states
But the example shown violates this already with the 2nd nested array as in
This gets even worse when combined with call argument rules in section 4.7:
A multi-argument call written in multi-line style always violates either rules of section 4.7 or 11:
I think what the addendum in PER 3.1 wants to say is that an array written in multi-line style needs to be treated as a compact single-line item when applying other rules. "Compact single-line item" is no term specified yet and there might be better ones to describe this, but basically similar to a scalar or a variable etc.
This automatically fixes the nested array example in section 11 and its in line with the example shown in the PER 3.1 diff section 11
if this is interpreted as a function call in single-line style.
This is also in line with the example showing a multi-argument call in single-line style in section 4.7:
As a consequence, it would clarify the ambiguity in multi-argument calls in multi-line style to be
but also (!):
It would also mean that a single-argument call written in multi-line style such as
(which is valid according to PER) still enables to write
unless there is a rule enforcing to write single-array-argument calls in single-line style always...