PHP 8.6 erscheint am 19. November 2026, und ich weiß jetzt schon, mit welchem Feature jeder Konferenz-Talk aufmachen wird: Partial Function Application. Du schreibst str_replace(' ', '-', ?) und bekommst ein Callable, bei dem das letzte Argument offen bleibt — bereit, direkt in den Pipe-Operator zu wandern. Das ist wirklich schön, und nach Jahren voller fn($x) => Wrapper-Closures, die unsere Collection-Pipelines zumüllen, nehme ich das dankbar an. Aber meine eigentliche These lautet: PFA ist das Feuerwerk, nicht die Baustelle. Die Teile von 8.6, die in drei Jahren am meisten zählen werden, sind die, die heute langweilig aussehen — die reservierten Wörter, die Deprecations und eine Polling-API, die ganz bewusst ohne das ausgeliefert wird, was alle haben wollen.

Fangen wir bei den Bezeichnern an, vor denen PHP dich jetzt warnt: let, is, namespace als bestimmte Namen, readonly als Funktionsname und der einsame Unterstrich _. Eine Sprache sperrt Wörter wie let und is nicht zum Spaß ab. Da reserviert das Core-Team Parkplätze für künftige Syntax — Pattern Matching ist bei is die naheliegende Vermutung — und zwar eine ganze Major-Version im Voraus, damit der spätere RFC nicht das halbe Packagist zerlegt. Wenn du je zugesehen hast, wie eine Sprache versucht, ein Keyword nachträglich einzubauen, weißt du, wie viel Schmerz dieser stille Schachzug erspart.

Die neue Polling-API erzählt dieselbe Geschichte. Sie gibt den PHP-Internals — PHP-FPM, Signal-Handling, ZTS — eine ordentliche Abstraktion über epoll und WSAPoll, und sie ist in Userland verfügbar, damit ReactPHP und Amp ihre stream_select()-Verrenkungen in Rente schicken können. Entscheidend: Sie liefert kein async/await und keinen Event-Loop. Ich habe erlebt, dass Leute das als Zaghaftigkeit lesen. Ich lese es als Reihenfolge: Du gießt nicht am selben Nachmittag den Beton und hängst die Rigipsplatten auf. Wenn PHP jemals erstklassiges Async bekommt, wird es auf genau dieser unglamourösen Rohrleitung stehen — und Anwendungen mit hoher Concurrency skalieren schon jetzt besser.

Die Deprecation-Liste liest sich mit etwas Abstand genauso. Das return aus dem finally — dieser kleine Fußschuss, bei dem ein return [] im finally-Block das return $value im try still verschluckt — steht endlich auf der Abschussliste. Konstruktoren und Destruktoren, die Werte zurückgeben, was nie irgendetwas bedeutet hat, sind jetzt offiziell deprecated. Reflection wird strenger: Properties auf fremden Objekten setzen und statische Methoden über Instanzen aufrufen sind beide zur Entfernung markiert. Jeder dieser Punkte schließt eine Tür, um die irgendein künftiges Feature sonst herumschleichen müsste. Und ja, is_double(), is_integer(), is_long() und doubleval() fliegen zugunsten von is_float(), is_int() und floatval() raus; wenn das deine Codebase zerlegt, war deine Codebase ohnehin überfällig für einen Rector-Lauf.

Lass mich das stärkste Gegenargument einräumen, denn es ist ein gutes: Für Entwickler im Alltag zahlt das sofort Nützliche die Rechnungen, und davon hat 8.6 reichlich. clamp($value, 0, 100) ersetzt die max(0, min(100, $value))-Beschwörungsformel, die wir alle schon vertippt haben, und funktioniert mit Strings, DateTime, allem Vergleichbaren. Readonly-Properties können jetzt Default-Werte tragen. Reflection bekommt isReadable() und isWriteable(), was Framework-Autoren mit Property Hooks und privaten Settern vom ersten Tag an nutzen werden. ReflectionParameter::getDocComment() legt Annotationen direkt neben den Parameter, den sie beschreiben. Enums bekommen __debugInfo(), damit var_dump()-Output aufhört, Archäologie zu sein. Wenn deine Definition eines guten Releases 'Dinge, die ich in diesem Sprint benutze' lautet, nimmt 8.6 die Latte ganz ohne meine architektonische Romantik.

Aber ich bleibe bei meiner Position, und die Session-Defaults sind der Grund. session.use_strict_mode = 1, session.cookie_httponly = 1, session.cookie_samesite = Lax — out of the box. Niemand wird atemlos über ini-Defaults bloggen, und doch wird diese eine Änderung still eine ganze Klasse von Session-Fixation- und Cookie-Diebstahl-Bugs in tausenden Apps töten, deren Maintainer den Changelog nie lesen. Genau das ist das Muster, auf das ich zeige: Die unsexy Entscheidungen verzinsen sich. Das SortDirection-Enum ist ein weiteres Indiz — ausgeliefert, bevor die Core-Sortierfunktionen es überhaupt akzeptieren, einzig damit sich das Ökosystem jetzt standardisieren kann und die Sprache später nachzieht. Da plant ein Projekt in Jahrzehnten, nicht in Release-Zyklen.

Praktische Konsequenz für dein Upgrade: Behandle 8.6 nicht wie ein Feature-Buffet, an dem du irgendwann mal grasen kannst. Lass es in der Woche des Releases in der CI laufen, mit Deprecations als Build-Fehlern. Die finally-Returns, die Legacy-Typ-Helfer, die Reflection-Tricks in diesem einen uralten Serializer, den du 2019 vendored hast, spl_object_hash()-Aufrufe, mysqli::stmt_init() — jeder Fund, den du jetzt fixt, ist eine Migration, die du nicht unter Druck erledigen musst, wenn PHP 9 kommt. Und prüfe, ob irgendetwas in deinem Stack davon abhängt, dass Cross-Site-POSTs Sessions treffen oder JavaScript Session-IDs lesen kann, denn die neuen Cookie-Defaults beißen genau solche Setups zuerst.

Und hier will ich Widerspruch, denn ich weiß, dass in diesem Raum Leute sitzen, die anderer Meinung sind. Beurteilt man ein Release am besten danach, was es dich heute schreiben lässt — oder danach, was es in drei Jahren möglich macht? Anders gefragt: Welche Änderung aus 8.6 wird 2029 noch zählen — PFA und der Pipe-Operator, oder der Tag, an dem PHP das Wort is reserviert hat? Sag mir in den Kommentaren, dass ich falsch liege; bring Code mit.