PHP RFC: Trailing Boolean Operators

• Version: 1.1
• Date: 2026-02-02
• Author: Len Woodward, len@artisan.build
• Status: Under Discussion
• Target Version: PHP 8.6

This RFC proposes allowing trailing boolean operators (&&, ||, and, or) in parenthesized expressions, mirroring the existing support for trailing commas in arrays, function parameters, and other contexts.

<?php
 
// Currently invalid, proposed to be valid:
if (
    $user->isActive() &&
    $user->hasPermission('edit') &&
    $resource->isEditable() &&
) {
    // ...
}
 
?>

Allow a trailing &&, ||, and, or or at the end of a parenthesized boolean expression:

<?php
 
$result = (
    $a <= $b &&
    $b <= $c &&
    $c <= $a * $b &&
);
 
if (
    $user->isActive() &&
    $user->hasPermission('edit') &&
    $resource->isEditable() &&
) {
    // ...
}
 
?>

The trailing operator is syntactically permitted and ignored. The above is semantically equivalent to:

<?php
 
$result = (
    $a <= $b &&
    $b <= $c &&
    $c <= $a * $b
);
 
?>

This follows the same pattern as trailing commas: the parser consumes and discards the trailing token, leaving the AST unchanged.

PHP already supports trailing commas in multiple contexts:

• Arrays (since PHP 5.0): [1, 2, 3,]
• Function/method calls (since PHP 7.3): foo($a, $b,)
• Function/method declarations (since PHP 8.0): function foo($a, $b,) {}
• Closure use statements (since PHP 8.0): function() use ($a, $b,) {}
• match arms (since PHP 8.0)

The rationale for trailing commas applies equally to boolean operators:

1. Cleaner diffs: Adding or removing a condition only changes one line
2. Easier reordering: Conditions can be moved without adjusting punctuation
3. Reduced syntax errors: No need to remember to remove the operator when deleting the last condition

Without trailing operators (current behavior):

 if (
     $user->isActive() &&
-    $user->hasPermission('edit')
+    $user->hasPermission('edit') &&
+    $resource->isEditable()
 ) {

With trailing operators (proposed):

 if (
     $user->isActive() &&
     $user->hasPermission('edit') &&
+    $resource->isEditable() &&
 ) {

The trailing operator style produces a one-line diff for adding a condition, compared to a two-line diff that touches an unrelated line.

PSR-12 permits boolean operators at either the beginning or end of lines. Both styles are valid and used in practice. This RFC is not about whether trailing-operator style should exist — it already does. This RFC addresses the friction inherent in that style: the need to modify the final line when adding or removing conditions.

Trailing commas have proven valuable in PHP and are now supported across arrays, function calls, function declarations, closure use statements, and match arms. This RFC extends the same principle to boolean operators.

Leading-operator style is valid, but it doesn't solve the problem — it just moves it. Both current styles have a “special” line that requires modification when reordering:

Leading style — reorder first two conditions:

 if (
-    $isAdmin
-    || $isEditor
+    $isEditor
+    || $isAdmin
     || $isModerator
 ) {

Two lines touched to swap two conditions.

Trailing style (current) — reorder last two conditions:

 if (
     $isAdmin ||
-    $isEditor ||
-    $isModerator
+    $isModerator ||
+    $isEditor
 ) {

Same problem, different location.

With trailing operators (proposed) — reorder any two:

 if (
     $isAdmin ||
-    $isEditor ||
     $isModerator ||
+    $isEditor ||
 ) {

Each condition is a self-contained line. Reordering is a single-line move.

The PEAR coding standard recommends leading operators partly because “it's easier to comment out a line.” But this is a workaround for the lack of trailing operator support — a workaround that trades one problem (commenting) for another (reordering the first condition). With trailing operators, both commenting and reordering become single-line operations:

<?php
 
if (
    $a &&
    // $b &&  // commented out cleanly
    $c &&     // can be moved anywhere
) {
    // ...
}
 
?>

This RFC doesn't deprecate or discourage leading-operator style — it simply solves the underlying problem that makes both current styles require multi-line edits in certain cases.

Trailing boolean operators are permitted in:

1. Parenthesized expressions: ($a && $b &&)
2. Control structure conditions: if, elseif, while, do-while, switch
3. Match expressions: match ($expr) { ... } (for consistency)

Trailing boolean operators are NOT permitted in:

1. Bare expressions: $x = $a &&; (syntax error)
2. Return statements: return $a &&; (syntax error)
3. Array elements: [$a &&] (syntax error)

This restriction is natural because trailing operators only make sense in contexts where the expression is already delimited by parentheses.

Basic usage in an if statement:

<?php
 
if (
    $order->isPaid() &&
    $order->isShipped() &&
    $order->isDelivered() &&
) {
    $order->archive();
}
 
?>

Using the OR operator:

<?php
 
$canAccess = (
    $user->isAdmin() ||
    $user->isEditor() ||
    $user->isModerator() ||
);
 
?>

In a while loop:

<?php
 
while (
    $iterator->valid() &&
    $count < $limit &&
) {
    process($iterator->current());
    $iterator->next();
    $count++;
}
 
?>

With the and/or keywords:

<?php
 
$result = (
    $a and
    $b and
    $c and
);
 
?>

Edge case - nested parentheses:

<?php
 
$complex = (
    ($a && $b &&) ||
    ($c && $d &&) ||
);
 
?>

This is a purely additive change. Code that was previously a syntax error becomes valid. No existing valid code changes meaning.

No backward compatibility breaks are expected.

PHP 8.6

IDEs, language servers, and static analyzers will need to update their parsers to recognize the new syntax. However, since this is purely additive (previously-invalid syntax becoming valid), existing tooling will not break — it will simply report false-positive syntax errors until updated.

Auto-formatters may choose to add or remove trailing operators based on configuration, similar to how they handle trailing commas.

None. The change is at the parser level only.

None.

None. The change is at the parser level; compiled bytecode is identical with or without the trailing operator.

None at this time.

This RFC intentionally does not address:

• Trailing operators in other contexts (e.g., bitwise |, &)
• The xor operator (less commonly used in multiline expressions)

These could be proposed separately if there is demand.

Primary vote requiring a 2/3 majority:

Proof of concept implementation: To be added

The implementation is parser-only. No changes are required to:

• The lexer (tokens already exist)
• The AST node types
• The compiler
• The VM/opcodes

The trailing operator is consumed by the parser and discarded, identical to how trailing commas are handled via possible_comma.

In Zend/zend_language_parser.y:

Add new rule:

paren_expr:
        expr
    |   expr T_BOOLEAN_AND      { $$ = $1; }
    |   expr T_BOOLEAN_OR       { $$ = $1; }
    |   expr T_LOGICAL_AND      { $$ = $1; }
    |   expr T_LOGICAL_OR       { $$ = $1; }
;

Modify existing rules to use paren_expr instead of expr in parenthesized contexts (if, while, do-while, switch, elseif, and general parenthesized expressions).

1. Zend/zend_language_parser.y — Grammar rules (~10 lines)
2. Zend/tests/operators/trailing_boolean_operators_basic.phpt — Basic functionality tests
3. Zend/tests/operators/trailing_boolean_operators_error.phpt — Error case tests

After the RFC is implemented, this section should contain:

1. the version(s) it was merged into
2. a link to the git commit(s)
3. a link to the PHP manual entry for the feature

• PSR-12: Extended Coding Style
• PHP RFC: Trailing Commas in Function Calls
• PHP RFC: Trailing Commas in Parameters
• PHP RFC: Trailing Commas in Closure Use Lists

To be updated based on mailing list discussion.

• 2026-02-03: Removed incorrect claims about JavaScript/Ruby supporting this feature; clarified that this is a novel extension of the trailing comma principle; added “Why Not Leading Operators?” section addressing the main counter-argument
• 2026-02-02: Initial RFC draft created