Handling whitespace after function-like language constructs name

[julienfalque]

The discussion at #4837 (comment) threw light at the fact that we don't always agree how to handle language constructs that more or less behave like functions.

There are various possible situations:

1. language constructs used exactly like functions, e.g. isset(), eval();
2. language constructs that can be used like functions, but not only, e.g. echo('foo') vs. echo 'foo', require('foo.php') vs. require 'foo.php';
3. language constructs whose usage looks like a function call: e.g. declare(), which can also be written declare() { ... };
4. language constructs that cannot be confused with functions, e.g. if () { ... }.

The discussion was about how to handle whitespace after the name of such language construct (i.e. echo('foo') vs. echo ('foo'). We currently have one rule that covers that (no_spaces_after_function_name) and a new rule proposed in #4435 (single_space_after_construct). This is problematic as some language constructs can be covered by both rules depending on whether they are considered a function or not.

IMO there are two possible ways to move forward:

• deprecate no_spaces_after_function_name in favor of a new rule that covers all cases, with configuration option(s) (changes in SingleSpaceAfterConstructFixer - Introduction #4435 would be merged in this new rule);
• make sure changes in SingleSpaceAfterConstructFixer - Introduction #4435 only covers language constructs that cannot be confused with functions (4) and cover the others (1, 2, 3) in no_spaces_after_function_name with a new configuration option.

Also, to avoid long discussions in future PR(s), we should define the exhaustive list of language constructs that are ambiguous and define in which category they are, e.g.: require → 2. language constructs that can be used like functions, but not only

• Agree on the solution to implement
• Define the list of language constructs and their nature

[guilliamxavier]

Thank you for tackling this issue. I generally agree but here are some facts & thoughts (tl;dr at the end):

• PSR-2 ("deprecated") and its successor PSR-12 don't specify any spacing rules for "language constructs", only for "control structure keywords" (vs "method and function calls"), hence some unfortunate room for interpretation (and disagreements).
• The PHP manual has a "Control Structures" section, and references "language constructs" in somes pages like "List of Keywords", "Variable functions", "Callbacks / Callables".
• include/require[_once] are documented as "control structure" (only, not "function"), so a literal application of PSRs should actually enforce a space after them (i.e. the opposite of current behavior).
• declare is also documented as "control structure" but PSR-12 has a specific rule for "declare statements" (which says "no space", reflecting common usage).
• echo/print are documented as "function" but also "language construct" ("not [actually] a [real] function"), which is also the case of e.g. exit() but with an important difference: parentheses (by the way, I have never seen "echo()" in the manual).
• As regards "arguments", echo/print are not different than include/require[_once] or even return, yield, throw, clone... (and we don't endorse "return('foo')").
• Even if e.g. "print(2 + 3)" can be considered acceptable by some (for print 2 + 3), I hope that everyone can agree that e.g. "print(2 + 3) / 4" is really misleading (no, that's actually not the same as "(print(2 + 3)) / 4" as would have been the case with a regular function like printf() or even a category-1 like eval(), that's actually the same as "print((2 + 3) / 4)", and the result is different!).

Therefore (IMO):

• include/require[_once] shouldn't be handled by no_spaces_after_function_name, but by single_space_after_construct (or, if you merge those rules, shouldn't be considered a function, but a construct).
• Already correct echo/print expressions involving parentheses (e.g. print (2 + 3) / 4) shouldn't be "fixed" to misleading writings (at least not by default).
• isset() & its "parentheses brothers" could be made "opt-in", in case someone would want to write e.g. "unset ($a, $b)" and not have it changed to "unset($a, $b)", arguing it's "not really a function" (even though it takes parentheses just like one)...