I like the idea but I don't like the implementation. If merged, this will make the code use sometimes array(...) and sometimes [...] so the codebase will be inconsistent. It's better to make this change at once in the entire codebase applying PHP-CS-Fixer to all branches.

👎
we still have to merge 3.4 into 4.0 for some years to come.
I just spent yesterday's afternoon merging 2.7 up to master and loosing my time because we decided to remove all those /** Constructor. */ docblocks.
Fortunately for those, it's a do once job. Here, this will make fabbot fail on any file touched by a PR on 4.1, encouraging ppl to move from array() to [], thus breaking merges every time we do them.
Being consistent is of course also a good argument.

Following the conversation in #22862, everybody kind of agreed that we should use PHP7+ syntaxes for all new code bases.

@nicolas-grekas I think your point is valid: cases where PRs are just updating existing usage of array() to [] will give merge conflicts for no benefit and if we merge this CS change, they won't be automatically catched by fabbot. What about making clear to contributors not to update existing array() usages but allow them to use [] for new contributions?

What about making clear to contributors not to update existing array() usages but allow them to use [] for new contributions?

This won't work in practice. Non-regular contributors don't read the guidelines and don't follow them. This would cause lots of problems.

@javiereguiluz but we can't "make this change at once in the entire codebase" until 2018 because 2.7/2.8 have PHP 5.3 (that do not have the short-array syntax) as minimum PHP version.

correct, let's discuss this again in one year.

Closing for now as explained.

👍