Warum PHP keine nativen Generics hat

Im Review kommt in PHP-Projekten immer wieder dieselbe Frage auf. Wann kommen endlich native Generics?

Meistens genau dann, wenn ein mixed-Rückgabewert wieder eine unnötige Diskussion auslöst.

Die kurze Antwort ist unbequem. Nicht weil niemand den Nutzen sieht, sondern weil die vollständige Umsetzung in PHP technisch sehr teuer ist.

Warum Generics überhaupt so wichtig sind

Ich will mit Generics keine Theorie gewinnen. Ich will im Alltag weniger Fehler und klarere Verträge.

Wenn ich Collections, Repositories oder Mapper typisiert beschreiben kann, dann wird sofort klarer:

• was eine API erwartet,
• was sie zurückgibt,
• welche Fehlannahmen schon beim Review auffallen.

Genau deshalb ist der Wunsch absolut nachvollziehbar.

Wo die eigentliche Schwierigkeit liegt

PHP ist keine klassisch kompilierte Sprache, die alle Typentscheidungen einmalig vor dem Start auflöst. Viele Dinge passieren zur Laufzeit.

Und genau dort wird es bei nativen Laufzeit-Generics teuer.

1) Typprüfung zur Laufzeit

In kompilierten Sprachen können Generics stark in die Compile-Phase verlagert werden. In PHP muss die Laufzeit deutlich mehr Arbeit leisten.

Das bedeutet mehr Overhead an genau der Stelle, an der die Sprache heute schnell bleiben soll.

2) Generische Objektinstanzen sind aufwendig

Ein Konstrukt wie new Repository<BlogPost>() klingt einfach. In einer dynamischen Laufzeit braucht das aber zusätzliche Typinformationen am Objekt und konsistente Prüfungen über den gesamten Ablauf.

Das ist keine kleine Syntaxfrage, sondern ein Architekturthema im Kern der Sprache.

3) Typinferenz ist in dynamischen Systemen teuer

Damit Generics im Alltag nicht unlesbar werden, brauche ich gute Typinferenz. Gerade in einem flexiblen, dynamischen Umfeld ist robuste Inferenz schwer und rechenintensiv.

Ohne gute Inferenz wird die Sprache sperrig. Mit aggressiver Inferenz wird sie schnell langsam.

4) Untypisierte Variablen erhöhen die Komplexität

PHP lässt viel Freiheit bei Variablen und Datenstrukturen. Diese Freiheit ist praktisch, macht aber strenge generische Garantien im Kernsystem anspruchsvoller.

Warum Union Types die Lage verschärfen

Union Types sind sinnvoll. Die Kombination mit generischen Compound Types macht das Problem aber deutlich komplexer.

Ein Beispiel wie Repository<BlogPost|User|Event> erzeugt in der Typauflösung schnell viele Pfade. In einer Laufzeitumgebung kann das starke Performance-Kosten verursachen.

Deshalb ist es realistisch, dass genau diese Kombination lange ein Grenzbereich bleibt.

Der realistische Weg, Compile-time-first statt Laufzeit-Zauber

Für mich ist der spannendste Ansatz ein pragmatischer Kompromiss. Mehr Typsicherheit in der Analyse und Planung, ohne die Laufzeit unnötig zu belasten.

Also nicht sofort volle Laufzeit-Generics überall, sondern schrittweise stärkere compile-time-orientierte Prüfungen.

Das bringt einen großen Teil des Nutzens, ohne die Sprache zu verbiegen.

Wie ich heute schon typsicher arbeite

Ich warte in Projekten nicht auf ein perfektes Sprachfeature. Ich nutze die Werkzeuge, die jetzt verlässlich funktionieren.

Der Standard ist für mich:

• PHPStan oder Psalm in CI-Läufen,
• klare @template-Definitionen,
• Typgrenzen mit @template T of ...,
• präzise Verträge wie class-string<T>.

Ein minimales Beispiel:

/**
 * @template T of object
 */
interface Repository
{
    /**
     * @param class-string<T> $type
     * @return T|null
     */
    public function findById(string $type, string $id): ?object;
}

Das ist nicht identisch mit nativen Generics. Aber es reduziert bereits heute viele Fehlerklassen in echten Projekten.

Drei Dinge, die ich Teams dazu immer rate

1) Nicht auf den großen Sprachsprung warten

Wer auf das perfekte Feature wartet, verschenkt Jahre an Qualitätsgewinnen.

2) Typsicherheit als Prozess betrachten

Es reicht nicht, Tools zu installieren. Ich brauche klare Regeln, CI-Gates und konsequente Reviews.

3) Den Nutzen am Risiko messen

Ich starte dort, wo falsche Typannahmen teuer sind, also bei Domänenobjekten, Repositories und Integrationsgrenzen.

Fazit

Native Generics in PHP sind keine Frage von gutem Willen. Sie sind eine schwierige Balance zwischen Ausdrucksstärke und Laufzeitkosten.

Ich gehe deshalb pragmatisch vor. Heute arbeite ich mit starker statischer Analyse und klaren Typverträgen, morgen übernehme ich Sprachverbesserungen, sobald sie stabil und wirtschaftlich sind.

Wenn du magst, kannst du mit dem Projekt-Check prüfen, wie robust eure Architektur-, Test- und Typsicherheitsbasis aktuell ist.