PHP 8.5: Warum der Pipe-Operator bei Arrays an Grenzen stößt

PHP 8.5 führte den Pipe-Operator ein, der auf einer RFC von Larry Garfield basiert und mit 33 zu 7 Stimmen angenommen wurde. Die Syntax wirkt zunächst verlockend: Eine Kette von Operationen wird von links nach rechts gelesen, ohne verschachtelten Code. Ein klassisches Beispiel illustriert die Idee:

$slug = $title |> trim(...) |> strtolower(...);

Hier fließt der Datentyp nahtlos durch die Transformationen, und der Code liest sich wie eine natürliche Abfolge. Doch sobald Entwickler:innen den Operator mit PHP-Arrays einsetzen – die in den meisten Codebasen die zentrale Rolle spielen – zeigen sich unerwartete Hürden.

Warum der Pipe-Operator bei Arrays an seine Grenzen stößt

Ein typisches Szenario ist die Verarbeitung von Benutzereingaben, etwa bei der Bereinigung und Sortierung von Tags. Der ursprüngliche Code sieht so aus:

$cleanTags = array_values(
    array_filter(
        array_map(fn($t) => strtolower(trim($t)), $rawTags),
        fn($t) => strlen($t) >= 3
    )
);
sort($cleanTags);

Drei verschachtelte Funktionen, gefolgt von einer Sortierung, die als eigenständige Anweisung stehen muss, da sort() einen booleschen Wert zurückgibt und das Array per Referenz modifiziert. Die Ausführungsreihenfolge (von innen nach außen) widerspricht dem Lesefluss (von außen nach innen).

Mit dem Pipe-Operator sollte dieser Code eleganter werden:

$cleanTags = $rawTags
    |> (fn($ts) => array_map(fn($t) => strtolower(trim($t)), $ts))
    |> (fn($ts) => array_filter($ts, fn($t) => strlen($t) >= 3))
    |> array_values(...)
    |> (function ($ts) { sort($ts); return $ts; });

Der Code liest sich nun von oben nach unten und wirkt strukturierter. Doch hinter den Kulissen lauern drei kritische Probleme, die in den einfachen Beispielen der RFC nicht auftauchen.

Problem 1: Argumente in falscher Reihenfolge

Funktionen wie array_map und array_filter erwarten ihre Argumente in unterschiedlicher Reihenfolge:

• array_map(callable $callback, array $array) erwartet zuerst die Callback-Funktion.
• array_filter(array $array, ?callable $callback) erwartet zuerst das Array.

Der Pipe-Operator übergibt den linken Wert jedoch immer als erstes Argument an die rechte Funktion. Das bedeutet:

$result = $rawTags |> array_filter(...); // Funktioniert, da das Array als erstes Argument erwartet wird
$result = $rawTags |> array_map(...);     // Führt zu einem Fehler, da das Array als Callback interpretiert wird

Um array_map verwenden zu können, muss die Funktion in eine Lambda-Funktion eingekapselt werden, um die Argumente umzudrehen. Im obigen Codebeispiel erfordert dies zusätzliche Wrapper für beide Funktionen. Nur array_values passt direkt, da es ein einziges Argument erwartet.

Der Pipe-Operator offenbart damit nicht nur die Inkonsistenzen der Standardbibliothek, sondern macht sie sogar deutlicher sichtbar. Jede Kette, die Funktionen wie array_map, array_filter oder array_reduce kombiniert, erfordert zusätzliche Wrapper.

Problem 2: Klammern um Pfeilfunktionen sind Pflicht

Betrachten wir die Wrapper im vorherigen Beispiel:

|> (fn($ts) => array_map(fn($t) => strtolower(trim($t)), $ts))

Die Klammern um die Pfeilfunktion sind kein Stilmittel, sondern zwingend erforderlich. Ohne sie würde die Funktion alles bis zum Ende der Zeile erfassen:

$result = $rawTags |> fn($ts) => array_map(...) |> array_values(...);

Der Parser interpretiert dies als eine einzige Pfeilfunktion, die von array_map(...) bis |> array_values(...) reicht. Die Folge: Die Kette bricht zusammen und besteht nur noch aus einem Schritt.

Dieses Problem wurde erst durch eine Korrektur in der RFC vom 28. August 2025 behoben. Die Regel lautet nun: Jede Pfeilfunktion in einer Pipe-Kette muss in Klammern gesetzt werden. Einmal vergessene Klammern führen zu subtilen Fehlern, die schwer zu debuggen sind.

Die Marketing-Beispiele der RFC umgehen dieses Problem, indem sie einfache, einstellige Callables wie trim(...) oder strtolower(...) verwenden. Sobald jedoch eine Funktion aus der Standardbibliothek mit mehr als einem Argument oder nicht-unärer Signatur verwendet wird, landen Entwickler:innen schnell wieder bei (fn($x) => ...)-Konstruktionen.

Problem 3: Funktionen mit Referenzparametern lassen sich nicht verketten

Der letzte Schritt im Codebeispiel ist aus gutem Grund unschön:

|> (function ($ts) { sort($ts); return $ts; });

Er kann nicht als einzeilige Pfeilfunktion geschrieben werden und lässt sich auch nicht als erstes-class Callable verwenden. Die RFC schließt solche Funktionen explizit aus: Jede Funktion, deren erstes Parameter per Referenz übergeben wird, kann nicht in einer Pipe-Kette verwendet werden. Dazu gehören unter anderem:

• sort(), rsort(), usort(), ksort()
• array_push(), array_pop(), array_shift(), array_unshift()
• array_walk()

$rawTags |> sort(...);      // Fehler: Parameter wird per Referenz erwartet
$rawTags |> array_pop(...); // Gleicher Fehler

Als Workaround muss die gesamte Closure verwendet werden, die das Array modifiziert und zurückgibt. In der Praxis wird sort() daher meist außerhalb der Pipe-Kette aufgerufen, und das Ergebnis wird in die Kette eingespeist.

Wo der Pipe-Operator wirklich glänzt

Trotz der genannten Einschränkungen gibt es Szenarien, in denen der Pipe-Operator seine Stärken voll ausspielen kann. Besonders bei Ketten von einstelligen Standardfunktionen entfaltet er seine Eleganz:

$slug = $title
    |> trim(...)
    |> strtolower(...)
    |> (fn($s) => preg_replace('/[^a-z0-9]+/', '-', $s));

$payload = $body
    |> json_encode(...)
    |> gzencode(...)
    |> base64_encode(...);

Hier fließt der Datentyp nahtlos durch die Transformationen, ohne dass zusätzliche Wrapper oder Klammern nötig sind. Auch Objekte mit einer __invoke-Methode oder Instanzmethoden lassen sich problemlos kombinieren. Dies ist vermutlich der ursprüngliche Anwendungsfall, für den der Operator konzipiert wurde.

Warum Sammlungsbibliotheken die bessere Wahl sein könnten

Ein Blick auf moderne Sammlungsbibliotheken zeigt, wie eine konsistente API die Probleme des Pipe-Operators elegant umgeht. Die gleiche Tag-Bereinigung lässt sich mit einer solchen Bibliothek so schreiben:

$cleanTags = listOf($rawTags)
    ->map(fn(string $t) => strtolower(trim($t)))
    ->filter(fn(string $t) => strlen($t) >= 3)
    ->sorted();

Hier entfällt das manuelle Einkapseln von Funktionen, die Klammern um Pfeilfunktionen und die umständliche Handhabung von array_values. Die Methoden map(), filter() und sorted() sind Teil eines Objekt-APIs, bei dem das Array implizit als $this verfügbar ist und die Callback-Funktion immer als erstes explizites Argument erwartet wird.

Das Beispiel verwendet die Bibliothek von noctud, aber ähnliche Ansätze finden sich in anderen Sammlungsbibliotheken wie illuminate/collections, doctrine/collections oder ramsey/collection. Der entscheidende Vorteil liegt nicht in der spezifischen Implementierung, sondern in der Tatsache, dass eine konsistente Methodenkette die Inkonsistenzen der Standardbibliothek vermeidet.

Fazit: Der Pipe-Operator ist ein Schritt in die richtige Richtung – aber nicht die finale Lösung

Der Pipe-Operator in PHP 8.5 ist zweifellos ein Fortschritt für die Lesbarkeit und Wartbarkeit von Code. Doch die Probleme mit der Standardbibliothek zeigen, dass PHP an dieser Stelle noch Nachholbedarf hat. Die Inkonsistenzen bei Funktionssignaturen, die fehlende Unterstützung für Referenzparameter und die Notwendigkeit zusätzlicher Wrapper machen den Operator für viele Alltagsszenarien weniger praktisch, als es zunächst den Anschein hat.

Langfristig könnte eine native Sammlungs-API – ähnlich den Iteratoren in anderen Sprachen – die bessere Lösung sein. Bis dahin bleibt Entwickler:innen nur die Wahl zwischen umständlichen Workarounds oder dem Rückgriff auf externe Bibliotheken. Der Pipe-Operator ist ein Schritt in die richtige Richtung, aber er ist kein Allheilmittel.