Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [Discussion] Allow a trailing comma in function calls »

[RFC] [Discussion] Allow a trailing comma in function calls

php.internals

Sammy Kaye Powers

8 years ago
Hello internals friends! The RFC to allow a trailing comma in function calls is up for discussion: https://wiki.php.net/rfc/trailing-comma-function-calls Summary: - Targets PHP 7.3 - The previous vote on this combined function calls & declarations in the same vote (my bad!) - This RFC affects function calls only, not declarations Thanks, Sammy Kaye Powers sammyk.me

Peter Cowburn

8 years ago
On 7 October 2017 at 19:34, Sammy Kaye Powers <me@sammyk.me> wrote:
> Hello internals friends! > > The RFC to allow a trailing comma in function calls is up for discussion: > > https://wiki.php.net/rfc/trailing-comma-function-calls > > Summary: > > - Targets PHP 7.3 > - The previous vote on this combined function calls & declarations in > the same vote (my bad!) > - This RFC affects function calls only, not declarations >
I know it's late in the game, but I have a quick question. This RFC includes a couple of "Not really a function" functions (namely isset() and unset()) that will also be able to have a trailing comma, but I'm failing to find the discussion on including "not really a function" calls in this RFC. Why were those specific non-functions choices included? Why only those?

Sara Golemon

8 years ago
On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn <petercowburn@gmail.com> wrote:
> I know it's late in the game, but I have a quick question. This RFC > includes a couple of "Not really a function" functions (namely isset() and > unset()) that will also be able to have a trailing comma, but I'm failing > to find the discussion on including "not really a function" calls in this > RFC. Why were those specific non-functions choices included? Why only those? >
I'd guess because those are the only constructs which appear function-like *and* exhibit variadic behavior. empty/die/exit/print/require/include/require_once/include_once/__HALT_COMPILER don't have a variadic mode so allowing trailing commas in them would be pointless. -Sara

Peter Cowburn

8 years ago
On 24 October 2017 at 17:14, Sara Golemon <pollita@php.net> wrote:
> On Tue, Oct 24, 2017 at 11:37 AM, Peter Cowburn <petercowburn@gmail.com> > wrote: > > I know it's late in the game, but I have a quick question. This RFC > > includes a couple of "Not really a function" functions (namely isset() > and > > unset()) that will also be able to have a trailing comma, but I'm failing > > to find the discussion on including "not really a function" calls in this > > RFC. Why were those specific non-functions choices included? Why only > those? > > > I'd guess because those are the only constructs which appear > function-like *and* exhibit variadic behavior. > empty/die/exit/print/require/include/require_once/include_ > once/__HALT_COMPILER > don't have a variadic mode so allowing trailing commas in them would > be pointless. >
That's a fair point, then maybe we should consider declare() too? Also, I know that "echo" is a "doesn't even look like a function" but can that be considered as if we're changing any language constructs at all in this RFC, then that might benefit too. Note, I'm just saying "consider" on purpose, rather than suggesting any change to the RFC actually be made.

Sara Golemon

8 years ago
On Fri, Oct 27, 2017 at 7:17 AM, Peter Cowburn <petercowburn@gmail.com> wrote:
> On 24 October 2017 at 17:14, Sara Golemon <pollita@php.net> wrote: >> I'd guess because those are the only constructs which appear >> function-like *and* exhibit variadic behavior. >> >> empty/die/exit/print/require/include/require_once/include_once/__HALT_COMPILER >> don't have a variadic mode so allowing trailing commas in them would >> be pointless. > > That's a fair point, then maybe we should consider declare() too? >
Perhaps, but since we've already entered voting, it'll have to be a separate RFC at this point. That, or we reset and I don't think it's worthwhile for declare because it's only got three possible values, all of which can easily fit a single line.
> Also, I > know that "echo" is a "doesn't even look like a function" but can that be > considered as if we're changing any language constructs at all in this RFC, > then that might benefit too. Note, I'm just saying "consider" on purpose, > rather than suggesting any change to the RFC actually be made. >
At a shot-from-the-hip guess, I'd assume that would introduce parser ambiguity because of the lack of delimiting parenthesis. -Sara