# Modify language grammar to allow trailing commas in function/method calls

- Thread: https://externals.io/message/39157
- Original archive: https://news-web.php.net/php.internals/39157
- Started by Evan Priestley on 2008-07-21T23:46:58+00:00
- Messages: 4
- 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

---

## #39157 — Evan Priestley — 2008-07-21T23:46:58+00:00

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

This was floated in 2003 but had weak advocation and didn't seem to  
come to a decisive resolution:

	http://marc.info/?l=php-internals&m=106685833011253&w=2

Basically, the proposal is to modify the grammar to allow trailing  
commas in function and method calls, so this becomes a parseable PHP  
construct:

	f(1, 2, 3,);

This patch applies only to function and method calls; it does not  
apply to function or method definitions. It also does not allow the  
degenerative case of "f(,)".

The real value of relaxing this rule is in nontrivial cases that span  
across multiple lines:
	
	sprintf(
		'long example pattern with %d conversions: %s',
		$several,
		$conversions
	);

This sort of construction makes the code more readable but also  
exposes you to trailing-comma errors. You can easily introduce an  
error either by removing the last parameter or by changing parameter  
order. At least in my experience, these are relatively common syntax  
errors, and ones that are easy to make when making edits that are  
apparently minor. In the above example, I can remove the "%s"  
conversion, remove the "$conversions" parameter, and inadvertently  
introduce a syntax error because I have neglected to remove the comma  
after "$several". Similarly, I can change the parameter order by  
modifying the string and swapping $several for $conversions, but  
introduce a syntax error by neglecting to move the comma.

In the current grammar, if a function or method call has been written  
with parameters broken across multiple lines, adding or removing a  
trailing parameter means you need to modify two lines of code instead  
of one. This muddies and reduces the value of "blame" features in  
revision control. It also makes diffs slightly larger and noisier,  
which can make code reviews take a little longer since you have to  
scan the line and make sure the only change is to the trailing comma.

The looser grammar is easier to use and more consistent: it's easier  
to add, remove, or move parameters in an editor since you only need  
to use line-oriented editor operations, and you don't need to  
mentally distinguish between an array context and a parameter context.

In the original thread, Andi Gutmans explained that the decision to  
allowing trailing commas in array() literals is supported by the  
argument that it makes code generation easier. It seems like this  
argument applies to trailing commas in function definitions just as  
easily, and that the general ease-of-use arguments laid out above  
provide at least as much value as this (particularly since this  
specific code generation problem is solvable with `implode()`).

Andi also argued that this reduces readability and prevents assigning  
semantics to a trailing comma in the future. While I agree that it  
reduces readability in the "f(1, 2,)" case, I disagree that it  
reduces readability in the less trivial multi-line case and it  
greatly enhances "writeability". The possibility that the language  
would ever benefit from assigning semantics here, while worth  
considering, seems small. While my language architect credentials are  
pretty weak, I can't think of any reasonable meaning. Many languages  
accept trailing commas in data definitions (apparently including Java 
(!) now[1]), and some (such as Python[2]) accept them in calls; in  
all cases, the behavior is to ignore them. If PHP provided a  
different semantic, this would be somewhat startling.

In general, trailing commas are increasingly an accepted part of the  
grammars of modern languages. Beyond Java, Ruby and Python, Firefox  
now accepts them in Javascript object definitions (which is surefire  
way to tell that someone didn't test in IE). While they are more  
often accepted in data definitions than calls, I don't see a strong  
reason to distinguish between the cases.

This change has no impact on backward compatibility. It does makes it  
slightly more difficult to write code which runs across multiple  
versions of PHP. However, because it fails fast and explicitly, it's  
an error which is easy to detect and resolve when you decide you want  
to support more versions of PHP with your project. It's also  
straightforward to write a script that uses the tokenizer to safely  
and unambiguously remove trailing commas (I'd be happy to furnish  
such a script if people think there's value in it and there's a  
reasonable place to put it).

The diff in the original thread still seems correct, at least against  
a relatively recent release -- I applied it to PHP 5.2.5 and ran the  
tests, as well as verifying that the build could parse and execute  
code which used trailing commas in calls.

So, what's the feeling on this? We're trying to weigh the merits of  
rolling it into our stack at Facebook, but we'd feel a lot more  
comfortable if it was present upstream.

Thanks,
Evan Priestley

[1] http://java.sun.com/docs/books/jls/second_edition/html/ 
arrays.doc.html#11358
[2] http://docs.python.org/ref/calls.html

---

## #39170 — Christian Schneider — 2008-07-22T10:51:36+00:00

URL: https://externals.io/message/39157#39170 · In reply to: #39157

Evan Priestley wrote:
> support more versions of PHP with your project. It's also
> straightforward to write a script that uses the tokenizer to safely and
> unambiguously remove trailing commas (I'd be happy to furnish such a

The script "convertsyntax.php" at http://cschneid.com/php/ already
provides this functionality so this is already covered :-)

- Chris

---

## #39182 — Rodrigo Saboya — 2008-07-22T12:55:36+00:00

URL: https://externals.io/message/39157#39182 · In reply to: #39157

Evan Priestley escreveu:
> This was floated in 2003 but had weak advocation and didn't seem to come 
> to a decisive resolution:
> 
>     http://marc.info/?l=php-internals&m=106685833011253&w=2
> 
> Basically, the proposal is to modify the grammar to allow trailing 
> commas in function and method calls, so this becomes a parseable PHP 
> construct:
> 
>     f(1, 2, 3,);
> 
> This patch applies only to function and method calls; it does not apply 
> to function or method definitions. It also does not allow the 
> degenerative case of "f(,)".
> 
> The real value of relaxing this rule is in nontrivial cases that span 
> across multiple lines:
>     
>     sprintf(
>         'long example pattern with %d conversions: %s',
>         $several,
>         $conversions
>     );
> 

You could just do this:

sprintf(
     'long example pattern with %d conversions: %s'
     ,$several
     ,$conversions
);

I really don't see a great benefit here, and as you pointed out it would 
make code written with trailing commas incompatible with previous 
versions of PHP.

--
Rodrigo Saboya

---

## #39189 — Richard Quadling — 2008-07-22T14:33:18+00:00

URL: https://externals.io/message/39157#39189 · In reply to: #39182

2008/7/22 Rodrigo Saboya <rodrigo.saboya@bolsademulher.com>

> Evan Priestley escreveu:
>
> > […]
> You could just do this:
>
> sprintf(
>    'long example pattern with %d conversions: %s'
>    ,$several
>    ,$conversions
> );
>
> I really don't see a great benefit here, and as you pointed out it would
> make code written with trailing commas incompatible with previous versions
> of PHP.
>
> --
> Rodrigo Saboya
>
>
> --
> 
> 
>
>
Just thinking of other languages that allow you to skip params simply by
using commas. Whilst this isn't supported in PHP, allowing a trailing comma
and skipped parameters could look quite interesting!

foo(,,,,,,,);


I must admit, I get stung with this in JS when I'm building AJAX option sets
through Prototype for IE (I think like arrays in PHP which allow trailing
,), but I soon learned to do it properly.

I don't see this as a huge advantage.

Regards,

Richard Quadling.
-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"