On Wed, Apr 29, 2020, at 4:20 AM, tag Knife wrote: > Since the RFC to allow this behavour in PHP 8 has been accepted, I wish > to start talks on if we should amend PSR-12 to allow or disallow > trailing commas in function and method names. > > There is general confusion within the community why this RFC has been > firstly proposed and mostly accepted. With others welcoming the change > as they apparently do this error all the time. > > Personally I have never had a problem with accedently trailing a comma > in parameter lists and against this RFC, I think it promotes learned > bad habits instead of allowing people to learn from mistakes. > I am for disallowing trailing commas in parameter lists in either > PSR-12 or any future code style. > > Discuss. > > RFC: https://wiki.php.net/rfc/trailing_comma_in_parameter_list
Some context: That RFC was inspired by the parallel RFC for constructor promotion: https://wiki.php.net/rfc/constructor_promotion With that, it becomes more likely that constructors will be written "vertically," especially when combined with attributes, which are also about to pass: https://wiki.php.net/rfc/attributes_v2 In that case, having a comma on the last line has all the same advantages as for vertical array definition. When it's inline (the normal horizontal style we're all used to) then the extra comma really doesn't have a benefit. Disallowing the use of a new PHP feature entirely seems... pointless and counter productive, especially given the use cases it was intended for are about to become a lot more common. >From a process standpoint, PSR-12 is now immutable; it can have errata added, >but that's it. We've discussed before that fixed-PSRs are probably a not-good >model for a coding standard (esp since PHP 8 is going to have a number of new >features that PSR-12 obviously doesn't cover), and this is another example of >that. In the short-term, the best that could be done here is an errata saying "vertical things that allow a trailing comma should allow a trailing comma just like arrays do," but that would by definition be non-binding. I think at this point the answer is "do nothing until we figure out a new process for living standards rather than just fixed-point standards." --Larry Garfield -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a46f1d0d-ec9c-4747-869d-c260f33258ac%40www.fastmail.com.