Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...
https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Nikita
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Nikita
This would be a great addition, my "duplicate line" thanks you! (and so I)
Regards,
Lynn
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Nikita
Endorse.
I don't think there's anything more to add, just "endorse".
--Larry Garfield
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Nikita
Yes, please
Cheers,
Ben
Hi internals,
I'd just like to add that https://wiki.php.net/rfc/trailing_comma_in_parameter_list seems useful,
especially now that PSR-12 is approved and https://www.php-fig.org/psr/psr-12/#45-method-and-function-arguments recommends that
"When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them."
(Previously, I don't think there was any attempt at standardizing a recommendation of where the closing parenthesis should go)
class ClassName
{
public function aVeryLongMethodName(
ClassTypeHint $arg1,
&$arg2,
array $arg3 = [] // comma would be useful here when adding or removing in diffs
) {
// method body
}
}
- Tyson
I'd just like to add that https://wiki.php.net/rfc/trailing_comma_in_parameter_list seems useful,
especially now that PSR-12 is approved and https://www.php-fig.org/psr/psr-12/#45-method-and-function-arguments recommends that
"When the argument list is split across multiple lines, the closing parenthesis and opening brace MUST be placed together on their own line with one space between them."
(Previously, I don't think there was any attempt at standardizing a recommendation of where the closing parenthesis should go)
The text is identical for PSR-2[1], and even PEAR CS[2] put it that way.
So, yes, I'm +1 here.
[1] https://www.php-fig.org/psr/psr-2/#44-method-arguments
[2] https://pear.php.net/manual/en/standards.funcdef.php
--
Christoph M. Becker
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Nikita
I have no idea why we failed to approve trailing comma over lists in general,
but this seems to be a step forward. My git diff says +1
Thanks,
Márcio
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Nikita
Hi Nikita,
While I'd personally be fine with this change, I think we should
understand why the previous proposal failed rather than just hoping the
vote goes differently this time.
Specifically, this vote was only 3 years ago, and although it achieved a
majority, was well short of the 2/3 requirement:
https://wiki.php.net/rfc/list-syntax-trailing-commas#functionmethod_arguments_declarations_calls
Notably, a followup RFC proposing only function calls allow trailing
commas, passed a few months later, and includes this specific rationale:
https://wiki.php.net/rfc/trailing-comma-function-calls#wait_didn_t_we_just_vote_on_this
I was contacted by many “no” voters saying that they would have voted
“yes” for function calls, but “no” for function declarations. ThisRFC
proposes allowing a trailing comma in function call syntax only.
Looking back at the discussions from 2017, I can see a couple of people
taking that position, but not expanding on it. Does anyone still hold
that view, and want to explain why they feel that way?
Side-note - here's a quick timeline of related RFCs:
- Feb 2013: https://wiki.php.net/rfc/trailing-comma-function-args -
function calls only, rejected 15:20 - Oct 2015:
https://wiki.php.net/rfc/revisit-trailing-comma-function-args -
withdrawn in favour of next RFC - Nov 2015, voted Jan 2017:
https://wiki.php.net/rfc/list-syntax-trailing-commas - function calls
and parameters, rejected 24:20 - Oct 2017: https://wiki.php.net/rfc/trailing-comma-function-calls -
function calls only, passed 30:10 - Mar 2020: https://wiki.php.net/rfc/trailing_comma_in_parameter_list -
function parameters only...
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
Hi Rowan,
While I'd personally be fine with this change, I think we should
understand why the previous proposal failed rather than just hoping the
vote goes differently this time.
I think you have a good point here.
I've only been around for a short time so I can't comment on historical reasons.
And though I agree the proposal is logical and consistent, I have this
nagging feeling in the back of my brain:
Are we encouraging functions with long lists of parameters so that
they need to be on their own lines?
Personally I would probably never use this. But since the proposed
change sounds trivial, I have no strong feelings against it.
Best,
Jakob
Hi Rowan,
While I'd personally be fine with this change, I think we should
understand why the previous proposal failed rather than just hoping the
vote goes differently this time.I think you have a good point here.
I've only been around for a short time so I can't comment on historical reasons.
And though I agree the proposal is logical and consistent, I have this
nagging feeling in the back of my brain:
Are we encouraging functions with long lists of parameters so that
they need to be on their own lines?
Just to say, with descriptive names and type declarations (and now
union types), even a method with just two or three parameters can need
to be wrapped to keep lines below 120 characters ;) Maybe the RFC
could include an example?
But I am curious too about why it failed last time.
--
Guilliam Xavier
This would make PHP more consistent. Please add this!
Hi Rowan,
While I'd personally be fine with this change, I think we should
understand why the previous proposal failed rather than just hoping the
vote goes differently this time.I think you have a good point here.
I've only been around for a short time so I can't comment on historical reasons.
And though I agree the proposal is logical and consistent, I have this
nagging feeling in the back of my brain:
Are we encouraging functions with long lists of parameters so that
they need to be on their own lines?Just to say, with descriptive names and type declarations (and now
union types), even a method with just two or three parameters can need
to be wrapped to keep lines below 120 characters ;) Maybe the RFC
could include an example?But I am curious too about why it failed last time.
--
Guilliam Xavier
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...
Heads up: I plan to move this to voting tomorrow. Don't think there's much
to discuss here...
Nikita
Hi internals,
This has been declined in the past, but I just keep making this mistake,
and believe it deserves reconsideration...Heads up: I plan to move this to voting tomorrow. Don't think there's much
to discuss here...Nikita
Hello Nikita,
I'm personally favorable, but since some concern has been raised that
it might be interpreted as "encouraging" functions with many
parameters (and I fear that could be taken as a motive for voting
"no"), I would just suggest (again) that you could add an example (or
even replace the current one) of a function with only two/three
parameters that would still exceed 120 columns if on a single line
(with e.g. descriptive names, [union] type declarations for parameters
and/or return, and/or a class constant as default value for the last
parameter, that's not so uncommon)... Just my two cents ;)
Best regards,
--
Guilliam Xavier
I'm personally favorable, but since some concern has been raised that
it might be interpreted as "encouraging" functions with many
parameter
The only comment I saw was from Jakob Givoni that said:
"Are we encouraging functions with long lists of parameters so that
they need to be on their own lines?"
The answer to that is a pretty resounding "no".
Mark Randall
marandall@php.net