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

  100837
October 7, 2017 18:34 me@sammyk.me (Sammy Kaye Powers)
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
  100934
October 24, 2017 15:37 petercowburn@gmail.com (Peter Cowburn)
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?
> Thanks, > Sammy Kaye Powers > sammyk.me > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  100935
October 24, 2017 16:14 pollita@php.net (Sara Golemon)
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
  100960
October 27, 2017 11:17 petercowburn@gmail.com (Peter Cowburn)
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 >
  100966
October 27, 2017 13:46 pollita@php.net (Sara Golemon)
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