PHP 8.6 Alpha 1: Was tatsächlich drin ist

Letzte Woche habe ich geschrieben, dass der PHP-8.6-Feature-Stand vor Alpha 1 kürzer ist als erwartet und dass "akzeptiert" nicht "gemergt" bedeutet. Auf LinkedIn hatte ich angekündigt, mir die Alpha genauer anzuschauen, sobald sie da ist. Sie ist jetzt da, seit dem 2. Juli. Zeit für den Realitäts-Check.

Die kurze Antwort: PFA hat es geschafft. Letzte Woche stand in der Statustabelle "Akzeptiert, Implementation läuft, Status in Alpha 1 unklar". Diese Unsicherheit ist jetzt aufgelöst. Partial Function Application ist Teil von Alpha 1, mit der finalen Platzhalter-Syntax.

Statusvergleich: Montags-Prognose gegen Alpha-1-Realität

Partial Function Application: Was jetzt wirklich funktioniert

Die finale Syntax nutzt ? für einzelne Platzhalter und ... um alle verbleibenden Argumente offen zu lassen. Das ist großzügiger als die einfache Version, die ich letzte Woche skizziert hatte. PFA unterstützt Named Arguments, Parameter-Reordering und Variadics.

// Einzelne Platzhalter an beliebiger Position:
function logMessage(string $level, string $context, string $message): string {
return "[$level][$context] $message";
}

$errorAuth = logMessage('ERROR', 'auth', ?);
echo $errorAuth('Invalid token'); // [ERROR][auth] Invalid token

// Mehrere Platzhalter gleichzeitig:
function add4(int $a, int $b, int $c, int $d): int { return $a + $b + $c + $d; }
$f = add4(1, ?, 3, ?);
echo $f(2, 4); // 1+2+3+4 = 10

// Named Arguments und Reordering:
$f = add4(b: 2, d: 4, c: ?, a: ?);
echo $f(1, 3); // dieselbe Rechnung, andere Reihenfolge

// Alle offen lassen: entspricht First-Class-Callables aus PHP 8.1
$f = add4(...);

Was die kurze Vorschau letzte Woche nicht zeigen konnte: PFA und der Pipe-Operator aus PHP 8.5 sind als Paar gedacht. Larry Garfield, einer der RFC-Autoren, beschreibt es so, dass beide Features 2021 gemeinsam vorgeschlagen und beide abgelehnt wurden, jetzt aber getrennt eingeführt werden und zusammen erst ihren vollen Nutzen entfalten.

// Das Pipe-Operator-Problem aus PHP 8.5 ist damit gelöst:
$result = $data
|> array_filter(?, fn($x) => $x > 0)
|> array_map(strtoupper(...), ?);
// Keine Wrapper-Closures mehr nötig für mehrargumentige Funktionen

Zwei Funde, die letzte Woche noch nicht bekannt waren

First-Class-Callable-Caching

Wer strtoupper(...) oder ähnliche First-Class-Callables innerhalb einer Schleife oder einer häufig aufgerufenen Funktion erzeugt, hat bisher bei jedem Aufruf ein neues Callable-Objekt bekommen. Die Engine cached diese Instanzen jetzt, wenn sie stateless sind. Das reduziert Allokationen in Code, der viele Callables erzeugt, ohne dass am Code selbst etwas geändert werden muss.

TAILCALL VM für Windows

PHP 8.5 hatte die TAILCALL-VM-Optimierung für rekursive Aufrufmuster eingeführt, allerdings nur für bestimmte Compiler-Toolchains. Alpha 1 bringt diese Optimierung jetzt auch für Windows-Builds unter Clang 19. Für Windows-Server-Deployments mit rekursionslastigem Code (Parser, Tree-Traversal, bestimmte Serializer-Patterns) ist das ein direkter Performance-Gewinn ohne Codeänderung.

Beide Punkte waren in keiner der Vorschauen bis Ende Juni sichtbar. Das ist der eigentliche Wert eines Alpha-Checks gegenüber einer reinen RFC-Liste: Nicht jede Verbesserung läuft über ein RFC-Voting, manche werden einfach committed.

Was weiterhin offen ist

Closure-Optimierungen (automatisches static für Closures ohne $this) und die Float-Endianness-Modifizierer für pack()/unpack() waren im März akzeptiert, sind aber in den bisherigen Alpha-1-Berichten nicht eindeutig als gelandet bestätigt. Das heißt nicht, dass sie fehlen. Es heißt, dass ich dazu keine verlässliche Quelle gefunden habe, die über die reine RFC-Annahme hinausgeht.

Dasselbe gilt für die neuen Reflection-Methoden isReadable() und isWritable(). Wer auf diese Features angewiesen ist, sollte selbst gegen die Alpha-1-Quellen bauen und prüfen, statt sich auf Sekundärquellen zu verlassen. Genau das ist der Unterschied zwischen "wahrscheinlich drin" und "verifiziert drin".

True Async bleibt draußen. Daran hat sich nichts geändert, und es wird sich für PHP 8.6 auch nichts mehr ändern.

Was das für Ihre Timeline bedeutet

Der Plan aus der vergangenen Woche bleibt unverändert richtig: CI-Job gegen Alpha laufen lassen, Deprecation-Warnings sammeln, Production-Deployment frühestens nach dem ersten Bugfix-Release im Dezember. PFA und die beiden neuen Performance-Features ändern daran nichts. Sie sind ein gutes Zeichen für die Qualität des Feature-Sets, kein Grund für einen früheren Zeitplan.

Wie ich im Artikel von letzter Woche beschrieben habe, ist der Wert der Alpha-Phase die Kompatibilitäts-Frühwarnung, nicht die Feature-Jagd. Das gilt auch mit PFA an Bord.