[RFC] Allow trailing comma in function call argument lists View as Markdown

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

I'd be really reluctant to add this -- it's yet another (superfluous)
syntactical sugar, there is no patch, and how does this work with bound
variables (use keyword)?

cheers,
Derick

Marcello,

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Please feedback,

Marcello Duarte

I like the concept. I dislike the syntax. It looks too much like a JSON
object declaration, and it feels like it should be returning an object
instead of a closure/anonymous function. Additionally, I don't like that
it's also a closure. Short functions like this should be for simple
functions...

Perhaps:

lambda $x: trim($x);

$x: trim($x);

Or something similar...

Anthony

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Please feedback,

Duh, I don't think function(){} is long.

--
Regards,
Mike

2013/2/19 Marcello Duarte mduarte@inviqa.com:

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Please feedback,

Marcello Duarte

BC break detected:

<?php
{
echo "foo\n";
return "bar";
};

echo "baz\n";
return 42;
?>

The {} would probably be a closure that is not assigned to anything
while the current behaviour is to print "foo" and exit while returning
"bar".

-1 since it only saves 10 chars ("function()") without real added value.

Hi,

I don't really like to write every time a "long" 'function()', only for passing a little callback like 'function ($v) { var_dump($v); }'...:

Nice proposal, but writing the last argument outside of the function call could be confusing... An user-function is not a language construct (like while etc.)

regards,
Bob

Am 19.2.2013 um 13:57 schrieb Marcello Duarte mduarte@inviqa.com:

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Please feedback,

Marcello Duarte

Hello,

Inspired by Sara, here is another RFC, I finally got around to draft:

https://wiki.php.net/rfc/short-syntax-for-anonymous-function

Please feedback,

Marcello Duarte

I really don't like syntax for this. It makes it hard to follow. Removing
a couple of characters while making the syntax harder to follow isn't
a good thing imho.

Also it's a BC break, like Patrick mentioned.

Have a nice day,
Florin

Florin Patan
https://github.com/dlsniper

There's already been an overwhelming negative reaction to this
particular proposed syntax so I won't belabor the point much. In
short, this is too similar to block statements and does have BC
issues.

--

IF (and I stress if) we add a a shorter anonymous function syntax I'd
like it to be geared towards one-liners because that's where the
current syntax feels really verbose, especially when you close over
other variables:

function ($n) use ($m) { return $m * $n; }

Versus one potential option:

($value) |$m| => $m * $n;

This syntax is short and expressive at the expense of clarity.
Basically all short-syntax has that trade-off, so I am personally fine
with it. The only other potential problem I see is parsing it; someone
more familiar with PHP's parser would have to verify whether that
would be a problem.

Sara,

I wasnt commenting that this RFC was different, just in agreement that this
syntax is more in line with the list() construct (which then might
reflect the skipparams rfc))
If i wasnt clear: from a user point of view: i am all for this RFC ;)

Met vriendelijke groet,

Robin Speekenbrink
Kingsquare BV

2013/2/19 Sara Golemon pollita@php.net

On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
robin@kingsquare.nl wrote:

Just a question from one of the lingering listeners: would this change
also
ease the skipping of default values for parameters? (as discussed for
RFC
https://wiki.php.net/rfc/skipparams)

That way it would be consistent with this RFC and the list() construct ?

It's orthogonal to skipparams. It'd neither help nor hurt based on
the recommendations of that RFC.

With regard to list(), it already supports expressions like this:
list($x,) = array(123); so nothing more needs to be done for it and
it's not at odds with either of these RFCs.

-Sara

On Tue, Feb 19, 2013 at 4:41 AM, Kingsquare.nl - Robin Speekenbrink
robin@kingsquare.nl wrote:

Just a question from one of the lingering listeners: would this change also
ease the skipping of default values for parameters? (as discussed for RFC
https://wiki.php.net/rfc/skipparams)

That way it would be consistent with this RFC and the list() construct ?

It's orthogonal to skipparams. It'd neither help nor hurt based on
the recommendations of that RFC.

With regard to list(), it already supports expressions like this:
list($x,) = array(123); so nothing more needs to be done for it and
it's not at odds with either of these RFCs.

I would vote +1 on this solely for the sake of consistency. I've never liked the idea behind the parser's actions on constructs (list, array).

-Sara

Opening RFC to allow trailing comma in function call argument lists

https://wiki.php.net/rfc/trailing-comma-function-args
For the record, I've updated the RFC just now to include
function/method/closure declarations as well:

function foo(
$bar,
$baz,
) {

}

Not a pattern I see as much, but for the sake of consistency, it
doesn't hurt to put it on the table for discussion.

I would argue against the RFC.

The trailing comma is useful with arrays since it is not uncommon that members
need to be added to an array over time. This is often as a result of changes
outside of the program (eg: another user added to an ACL). Such a change does
not alter the purpose or functionality that is represented by the array, it just
does it for more somethings (users in my example).

Much source/version control is line based and so trailing commas helps keep
differences short.

With functions: I do not see arguments being added in the same way, ie you are
getting the function to do more of the same by adding an extra argument. If an
extra argument is added it is because what the function does has changed in some way.
This is very different from the just-a-bit-more scenario that you have with arrays.

If a function has a list of arguments that is expected to change, many
programmers would do that by passing an array to the function and arrays can
already have trailing commands ....

Also: many other languages (eg C, Perl) allow a trailing comma in arrays, but
not to function arguments. This change would make PHP different from what many
programmers might expect.

--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
#include <std_disclaimer.h>

--

The one place I would find this to be super handy would be when specifying arguments to sprintf(), and other variable argument functions.

Cheers,
David

On Thu, Mar 14, 2013 at 6:32 AM, Peter Cowburn petercowburn@gmail.comwrote:

Some unofficial votes going either way... Let's open the voting to
see where things fall.

Don't forget to start a new thread, as described in the Voting RFC [1].

[1] https://wiki.php.net/rfc/voting#voting

--

I noticed that multiple people who expressed support for the RFC on this
thread have since cast "No" votes on the RFC. I'm confused. Does "No"
correspond to supporting the idea in this case, or did something happen
outside this thread that changed people's minds about it?

--Kris