Update
Update 08.09.2026: Dieser Artikel wurde vollständig auf den Stand von PHP 8.6 Beta 2 (getaggt am 25.08.2026) aktualisiert. Die wichtigste Korrektur gegenüber der ursprünglichen Fassung: True Async ist an der Abstimmung gescheitert und wurde zusätzlich von den Autoren selbst zurückgezogen. Der Status auf php.watch lautet seit dem 22.07.2026 explizit „Withdrawn", nicht „Declined".
Warum dieses Update nötig war
In der ursprünglichen Fassung dieses Artikels war der Ausgang bei True Async noch offen. Inzwischen hat sich die Lage geklärt, deutlicher, als es der reine Vote-Ausgang vermuten lässt. Gleichzeitig hat sich mit Beta 2 der restliche Featureumfang so weit gefestigt, dass sich eine vollständige Bestandsaufnahme lohnt, statt einzelne Alpha- und Beta-Meldungen nachzuverfolgen.
Dieser Artikel fasst den aktuellen Stand zusammen: was tatsächlich in 8.6 landet, was der große Deprecation-Sweep bedeutet und was für Symfony-Projekte konkret zu prüfen ist.
True Async: Zurückgezogen, nicht nur abgelehnt
Der Unterschied ist mehr als Semantik. Eine abgelehnte RFC bedeutet, dass die Community gegen den Vorschlag gestimmt hat, der Autor aber grundsätzlich weiter daran festhalten kann. Der Status „Withdrawn" bedeutet, dass der Autor selbst den Vorschlag zurückgezogen hat, bevor es überhaupt zur finalen Abstimmung kam.
Bei True Async ist genau das passiert. Die RFC wurde am 25.12.2025 erstellt und zuletzt am 22.07.2026 aktualisiert, mit dem Status Withdrawn. Die beiden Companion-RFCs, die Engine-API und das Scope-Konzept für strukturierte Nebenläufigkeit, stehen weiterhin unter „Under discussion", ohne dass ein Voting-Termin absehbar ist. Ein Landing in einer späteren PHP-Version über mehrere Release-Zyklen hinweg bleibt möglich, ist aber aktuell reine Spekulation.
Kurz: Wer produktiv mit Async-PHP arbeitet, plant für 8.6 weiterhin mit ReactPHP, AMPHP oder Swoole. An dieser Einschätzung ändert sich absehbar nichts. Thematisch ergänzend die FrankenPHP-Background-Worker.
Partial Function Application: Version 2 mit einer wichtigen Nachschärfung
Anders als True Async ist PFA v2 angenommen und in Beta 2 vollständig implementiert. Die Syntax nutzt ? für genau ein Argument und ... für eine variadische Anzahl:
$makeSlug = str_replace(' ', '-', ?); echo $makeSlug('Hello World'); // Hello-WorldDas ergänzt den mit PHP 8.5 eingeführten Pipe-Operator sinnvoll, da dieser eine Callable mit genau einem Parameter verlangt. PFA liefert genau diese Callable, ohne dass eine separate Closure geschrieben werden muss.
Zwischen Alpha und Beta kam eine relevante Änderung dazu. Die Folge-RFC „Partial Function Application: Handling of Optional Parameters" von Tim Düsterhus, Arnaud Le Blanc und Larry Garfield wurde am 20.04.2026 angenommen. Sie macht alle Platzhalter-Parameter zu Pflicht-Parametern, statt die Optionalität des Ziel-Parameters zu übernehmen. Der Grund ist Konsistenz: Eine Signatur, die für statische Analyse lesbar bleibt, ist wichtiger als eine automatisch vererbte Optionalität, die im Zweifel zu Verwirrung führt.
Einschränkungen bleiben bestehen: keine partielle Anwendung auf Konstruktoren, Sonderregeln beim Referenz-Handling, benannte Platzhalter nur unter Bedingungen und Besonderheiten bei func_get_args().
Io\Poll: Unterbau, kein Async-Ersatz
Die Polling-API im Namespace Io\Poll bringt mit Context, Event und StreamPollHandle ein schmales Set an Klassen für effizientes I/O-Multiplexing. Verfügbar sind epoll unter Linux und WSAPoll unter Windows, jeweils als Ersatz für stream_select() ab einer gewissen Skalierung.
$context = new Io\Poll\Context(); $handle = $context->register($stream, Io\Poll\Event::Readable); $context->wait(Time\Duration::fromSeconds(5));Weitere bestätigte Features im Überblick
Neben PFA und der Polling-API landen mit Beta 2 mehrere kleinere, aber praktisch relevante Ergänzungen.
clamp() ist eine globale Funktion, die einen Wert auf einen Bereich begrenzt: clamp(mixed $value, mixed $min, mixed $max): mixed. Sie wirft einen ValueError, wenn $min größer als $max ist oder einer der beiden Werte NAN ist. Geprüft wird zuerst gegen das Maximum, dann gegen das Minimum. Die Funktion arbeitet mit Zahlen, mit nicht-numerischen Strings, die lexikografisch verglichen werden, und mit vergleichbaren Objekten wie DateTimeImmutable.
Time\Duration ist eine neue readonly-Klasse mit Nanosekunden-Präzision für Zeitspannen, mit Methoden wie fromSeconds(), fromMilliseconds(), add() und multiplyBy(), sowie direkter Vergleichbarkeit über die Standard-Operatoren.
Readonly-Properties dürfen jetzt Defaultwerte tragen, was seit den Property Hooks auf Interfaces in PHP 8.4 sinnvoll geworden ist. Das enum SortDirection { case Ascending; case Descending; } ersetzt die bisherigen Integer-Konstanten SORT_ASC und SORT_DESC typsicher, wobei Built-ins wie array_multisort() das neue Enum noch nicht direkt unterstützen.
Kleinere, aber im Alltag nützliche Ergänzungen: grapheme_strrev() kehrt Strings korrekt auf Grapheme-Cluster-Ebene um, was bei Emoji und kombinierten Zeichen einen echten Unterschied zum byte-basierten strrev() macht. Fehler bei json_decode() zeigen jetzt die Position im Payload an, was das Debuggen fehlerhafter Daten beschleunigt. Und das Attribut #[Override] greift jetzt auch für Klassenkonstanten.
Was in Beta 2 speziell dazukam
Release-Manager Matteo Beccati hat Beta 2 zwei Tage vor dem geplanten Termin getaggt, am 25.08. statt am 27.08.2026. Dadurch rutschten laut linuxcompatible.org drei Features durch die Soft-Freeze-Lücke: eine SNMP-Überarbeitung mit AES-192- und AES-256-Unterstützung, Endianness-Modifier für pack() und unpack() über die Zeichen < und >, sowie die Möglichkeit, in Klassenkonstanten gespeicherte Objekte direkt zu mutieren.
Zusätzlich wurde das Session-Hardening nachgezogen: SessionHandler::validateId() ist jetzt tatsächlich implementiert, wodurch session.use_strict_mode überhaupt erst wirkt. Der überwiegende Teil von Beta 2 besteht allerdings aus einem Memory-Safety-Sweep, unter anderem mehrere Use-after-free-Korrekturen in DOM, ein Crash-Fix im Opcache Tracing JIT und eine Korrektur im Lazy-Fetch-Modus von PDO_PGSQL.
Der Deprecation-Sweep: 31 von 35 angenommen
Die Sammel-RFC „Deprecations for PHP 8.6", koordiniert von Gina P. Banyard, bündelte 35 Einzelabstimmungen. Das Voting lief zwei Wochen und schloss am 10.08.2026 um 13:00 UTC. Ergebnis: 31 Vorschläge angenommen, 4 abgelehnt. Deprecations bedeuten in PHP 8.6 zunächst nur E_DEPRECATED-Warnungen, eine tatsächliche Entfernung ist frühestens für PHP 9.0 zu erwarten.
Unter den angenommenen Deprecations mit besonders deutlichem Ergebnis: Rückgabewerte aus __construct() und __destruct(), die Funktion mysqli_get_charset() mit 100 Prozent Zustimmung, sowie der Funktionsname readonly, der mit 97,5 Prozent angenommen wurde und damit den bekannten WordPress-Lexer-Hack überflüssig macht. Auch is_double(), is_integer(), is_long() und doubleval() sind deprecated, ebenso spl_object_hash() zugunsten von spl_object_id() und die CSV-Methoden von SplFileObject.
Vier Vorschläge scheiterten. Am knappsten war das list()-Konstrukt mit einem exakten Gleichstand von 23 zu 23 Stimmen bei einer Enthaltung, was die nötige Zweidrittel-Mehrheit klar verfehlte. Dieser Vorschlag hatte mit 12.275 Vorkommen in 5.545 Dateien auch den höchsten gemessenen Impact aller Deprecation-Kandidaten. Ebenfalls abgelehnt wurden in, out und inout als reservierte Identifier, der dechunk-Stream-Filter sowie der _()-Alias für gettext.
Die abgelehnte dechunk-Deprecation ist für Symfony-Projekte eine gute Nachricht: Der Filter wird intern vom HTTP-fopen-Wrapper und in userland von symfony/http-client sowie php-http/message genutzt, ohne dass ein Ersatz angeboten wurde. Symfony-Projekte werfen deshalb in 8.6 keine dechunk-Deprecation, unabhängig davon, ob die eigene Codebasis die pure-PHP-Alternative nutzt, die Symfony bereits seit Version 8.2 implementiert hat.
Was das für Symfony-Projekte konkret bedeutet
Die geänderten Session-Defaults verdienen besondere Aufmerksamkeit. session.use_strict_mode, session.cookie_httponly und session.cookie_samesite stehen jetzt standardmäßig auf 1, 1 und Lax, statt wie bisher aus oder ungesetzt zu sein.
Das kann bestehendes Verhalten brechen: extern gelieferte oder geteilte Session-IDs werden künftig abgewiesen, JavaScript-Zugriff auf den Session-Cookie über document.cookie ist blockiert, und Cross-Site-POST-Flows wie SP-initiiertes SAML-SSO oder ältere Cross-Origin-Formulare benötigen jetzt explizit SameSite=None; Secure statt sich auf die bisherigen Defaults zu verlassen.
// Falls Ihr Setup auf Cross-Site-POST angewiesen ist ini_set('session.cookie_samesite', 'None'); ini_set('session.cookie_secure', '1');Symfony 7.4 LTS verlangt PHP ab Version 8.2 und läuft damit technisch bereits auf 8.6. Die formale Framework-Kompatibilität neuer PHP-Minors folgt erfahrungsgemäß mit einigen Wochen bis Monaten Verzögerung nach dem jeweiligen GA-Release, ein Punkt, der bei der Migrationsplanung relevant ist. Details zur Symfony-Versionsstrategie und wann sich ein Wechsel lohnt, haben wir im Artikel zu Symfony LTS und aktueller Version eingeordnet.
Aus der Praxis
Der pragmatischste erste Schritt für laufende Projekte ist, PHP 8.6 lokal oder in Docker über das Image php:8.6-rc-cli laufen zu lassen und die eigene CI-Suite dagegen zu fahren, solange Bug-Reports gegen den Release noch etwas bewirken können, also bis zum Hard Feature Freeze mit RC1 am 24.09.2026. Ergänzend meldet PHPStan mit der Erweiterung phpstan-deprecation-rules zuverlässig deprecated Nutzung im eigenen Code, was deutlich schneller geht als das manuelle Durchsuchen der Codebasis nach den 31 angenommenen Deprecations.
Einordnung: Wann sich der Blick auf 8.6 jetzt schon lohnt
Für produktive Systeme bleibt der aktuelle Zeitpunkt eine Testphase, kein Umstiegszeitpunkt. Der GA-Release ist für den 19.11.2026 angesetzt, mit den Zwischenschritten Beta 3 am 10.09., Hard Feature Freeze samt RC1 am 22. beziehungsweise 24.09., und drei weiteren Release Candidates bis Anfang November.
Wer jetzt schon testet, hat noch echten Einfluss auf den Release, weil Bug-Reports gegen Beta 2 und Beta 3 den fertigen Stand noch formen können. Nach RC1 ist der Branch praktisch eingefroren und gemeldete Probleme landen bestenfalls noch als Fußnote im nächsten Minor-Release. Für Bestandscode mit unmittelbarem Handlungsbedarf sind vor allem die Session-Defaults relevant, für alles andere reicht ein Blick auf die eigene PHPStan-Deprecation-Liste, sobald die eigene Testsuite gegen 8.6 grün ist.
Technische Einordnungen wie diese veröffentliche ich regelmäßig. Folgen Sie mir auf LinkedIn für Updates.
Dennis Schwenker-Sanders ist PHP- und Symfony-Entwickler und verfolgt die PHP-Release-Zyklen für Agenturen und Entwicklerteams im DACH-Raum.