New PHP syntax worth considering

[KorvinSzanto]

I've gone through the PHP versions since 7.3 which was the most recently released when PSR-12 was accepted and gathered a list of syntax that we may want to cover in this PER. This list is likely incomplete so please add a comment if there's more I should add.

PHP 7.3: https://www.php.net/manual/en/migration73.php

• Add section describing nowdoc and heredoc #5 Heredoc / Nowdoc indention: https://3v4l.org/lTXHQ
• Array destructuring: https://3v4l.org/85FjD
• Add a section on trailing commas #18 Trailing commas in function / method calls: foo(1, 2, 3,)

PHP 7.4: https://www.php.net/manual/en/migration74.php

• Update the abstract/final section to cover all modifier keywords #19 Class property types: public int $foo;
• Add a section on short-lambdas #17 Short functions: fn(int $foo) => $foo * 2
• Numeric literal separator: $int = 1_000_000;
• __serialize and __unserialize vs using Serializable
• Nested ternaries require parenthesis in some situations post 7.4, we should consider using SHOULD NOT for nested ternaries.

PHP 8.0: https://www.php.net/manual/en/migration80.php

• Describe named arguments. #42 Named Arguments: foo(1, c: 2) https://3v4l.org/tglTA
• Add Attributes style guide #26 Attributes: https://3v4l.org/veQIX
• Constructor property promotion: https://3v4l.org/2hirZ
• Add handling for compound types. #45 Union types: Foo|Baz vs Foo | Baz
• Add match section #21 Match expressions: https://3v4l.org/2s8uK
• Throw as expression: $a = $b ?: throw Exception('b is falsy');
• Add a section on trailing commas #18 Trailing comma in parameter list: https://3v4l.org/RGf19
• FILTER_VALIDATE_BOOL over FILTER_VALIDATE_BOOLEAN when using filter_var

PHP 8.1: https://www.php.net/manual/en/migration81.php

• Array unpacking with string keys: $array = [...$otherData, 'b' => 1];
• Named arguments used after argument unpacking: $result = foo(...$args, namedArg: 123) https://3v4l.org/PN7kg
• Add section on enumerations. #7 Enums: https://3v4l.org/8Dljv
• First class callables: foo(...) vs foo( ... )
• Add handling for compound types. #45 Intersection types: Foo&Bar vs Foo & Bar
• new keyword in parameter initializers: https://3v4l.org/vcqT5
• Update the abstract/final section to cover all modifier keywords #19 Readonly properties

PHP 8.2: https://github.com/php/php-src/milestone/4

• Clarify that classes should follow the same modifier order as methods. #41 Readonly classes

Extra potential things to cover:

• Visibility keyword is not required when specifying readonly: public function __construct(readonly $foo)

[Girgias]

__serialize and __unserialize vs using Serializable

Serializable is deprecated (see https://wiki.php.net/rfc/phase_out_serializable) and is meant as a compatibility layer for old implementations.

FILTER_VALIDATE_BOOL over FILTER_VALIDATE_BOOLEAN

FILTER_VALIDATE_BOOL was added as it is the canonical type name, therefore this one should be recommended IMHO

For composite types, no spaces IMHO, especially when mixing union and intersection types (soon inc.) having loads of spaces is going to be detrimental to readability IMHO.

[KorvinSzanto]

Serializable is deprecated (see https://wiki.php.net/rfc/phase_out_serializable) and is meant as a compatibility layer for old implementations.

I wanted to include anything not removed just in case

FILTER_VALIDATE_BOOL was added as it is the canonical type name, therefore this one should be recommended IMHO

👍 We already require folks use bool over boolean so this makes sense.

For composite types, no spaces IMHO, especially when mixing union and intersection types (soon inc.) having loads of spaces is going to be detrimental to readability IMHO.

I'm not so sure on this one, PSR-12 currently prefers spaces around other binary operators and other languages that have similar syntax also tend to prefer the spaces. ^{1 2 3} I agree these declarations will get harder to read as they get longer especially since we don't have a great way to make larger union types portable like type FooBarBazType = Foo | Bar | Baz;. That said, I think we're going to have that issue whether we require spaces or not so we will probably need think about multiline declarations with something like:

function foo(): 
    null |
    SomeReallyLongClassName |
    SomeReallyLongOtherClassNameInterface |
    SomeReallyLongOtherOtherClassNameInterface
{
    return 1;
}

Footnotes

1. https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html#unions-with-common-fields ↩

2. https://flow.org/en/docs/types/intersections/ ↩

3. https://docs.python.org/3/library/typing.html#typing.Union ↩

[Jean85]

In regard to multiline declaration, IMHO we should suggest to put the operators at the start of the line, so it makes immediately clear that there's a continued declaration (or operation, in other contexts like with || and &&):

function foo(): 
    null
    | SomeReallyLongClassName
    | SomeReallyLongOtherClassNameInterface
    | SomeReallyLongOtherOtherClassNameInterface
{
    return 1;
}

[Crell]

From what I've seen, union types are generally written without spaces right now. At least that's what TYPO3 has been doing as we add types for v12.

IF going multiline, I agree the | should be at the start, as is typical for other similar constructs.

[ricardoboss]

Looking at Typescript, union and intersection type declarations include spaces around operators (see https://github.com/microsoft/TypeScript/blob/main/src/lib/es5.d.ts#L174 for example).

[Crell]

PR for short closures: #17

[Crell]

PR for trailing commas: #18

[Crell]

PR for typed properties and readonly: #19

[Crell]

PR for attributes: #26

[Crell]

Things I think we can be silent on:

• Numeric literal separator: Is there a guideline here to use?
• __serialize vs Serializable: The latter is deprecated anyway, so I don't know that we have much to add beyond the language itself.
• Throw as an expression: I really don't know what we'd even say here.
• new in parameter defaults: Again, I'm not sure there's anything to standardize here that isn't already covered by other statements. (Eg, space on either side of the =.)

[Crell]

PR for FCC: #27

[TimWolla]

Numeric literal separator: Is there a guideline here to use?

I don't think there is a generally applicable guideline other than “yes, please make use of it”. The “correct” grouping depends on a context:

const ONE_EURO_IN_CENTS = 1_00;
const THOUSAND_EUROS_IN_CENTS = 1_000_00;
const HUNDRED_THOUSAND = 100_000;
const ONE_MILLION = 1_000_000;