Das Team wirft einen Blick in Richtung Swift 4 und setzt sich mit der ABI-Stabilität ein altbekanntes Ziel

Swift 4 und der Open-Source-Einfluss
Kommentare

Noch ist Swift noch nicht einmal in Version 3 erschienen, schon gibt es einen Ausblick auf die darauffolgende Version Swift 4. Chris Lattner zieht seine Lehren aus der bisherigen Entwicklung und wagt einen vorsichtigen Blick in die Zukunft.

Mit Swift schickte Apple sich einst an, dass in die Jahre gekommene Objective-C mit einer neuen und modernen Sprache abzulösen. Beinahe logisch schien es, als man sich dazu entschloss, Swift Open Source zu stellen. Nun, da alle Welt gespannt auf den Release von Swift 3 wartet, schickt sich Chris Lattner an, sich Gedanken über einen möglichen Release-Plan für Swift 4 zu machen. Und das mit gutem Grund.

Swift 4

Natürlich ist es kein Leichtes, sich über Swift 4 Gedanken zu machen, wenn Swift 3 aktuell in der Version Preview 4 vorliegt und der Weg zum finalen Release der kommenden Major-Version noch nicht einmal zu Ende gegangen ist. Auf der anderen Seite hat das Team mittlerweile zahlreiche Erfahrungen sammeln können, die sich auf künftige Entwicklungen auswirken können.

From our experience with Swift 3, we know we need to pick and choose what we’re going to tackle. For Swift 4, the primary goals are to deliver on the promise of source stability from 3.0 on, and to provide ABI stability for the standard library.

Gerade beim Thema ABI-Stabilität dürfte bei vielen Mitgliedern der Community die Alarmglocken schrillen – war das doch das angestrebte Ziel für Swift 3.0.

Problemfall ABI-Stabilität

Die Stabilität des Application Binary Interface ist ein wichtiges Ziel – damit soll es Entwicklern ermöglicht werden, Binary-Libraries zu veröffentlichen, die unabhängig von der Swift-Version, in der sie kompiliert wurden, verwendet werden können. Veröffentlicht ein Entwickler beispielsweise eine Library, die in Swift 4 kompiliert wurde, können andere Entwickler sie ohne Bedenken in Swift 4.1 oder Swift 5 verwenden.

Diese ABI-Stabilität war ursprünglich das erklärte Ziel für Swift 3; wurde dann aber aufgrund zahlreicher Unwägbarkeiten verschoben, was von der Community mit gemischten Gefühlen aufgenommen wurde. Denn so dürften zwar nur die wenigsten Entwickler daran interessiert sein, Libraries in Binärform auszuliefern, allerdings könnte eine fehlende ABI-Stabilität auch auf eine gewisse API-Instabilität hindeuten. Fakt ist, dass das Core-Team mehr Wert darauf zu legen scheint als ein Großteil der Entwickler.

The 2 Stages of Swift 4

Um möglichen Probleme aus dem Weg zu gehen, hat sich das Team entschlossen, bei der Entwicklung von Swift 4 einen neuen Ansatz zu wagen und sie in zwei Stages anzugehen.

Im ersten Schritt will sich das Team einzig und alleine um die Stabilität des ABI und des Sources der Sprache kümmern. Das bedeutet auch, dass in diesem Schritt nur neue Features in Angriff genommen werden, die Änderungen an einem der beiden Bereiche beinhalten.

In dieser Phase will das Team auch ein paar Neuerungen angehen, wie beispielsweise ein von Rust inspiriertes Memory-Ownership-Modell, das eine vorhersagbare und deterministische Performance bieten soll. Außerdem hat man es sich zum Ziel gesetzt, den Typ String zu überarbeiten; man wolle, so Lattner, im String-Processing besser sein als Perl.

Im zweiten Schritt dann sollen – je nachdem, wie viel Zeit dem Team noch bleibt – neue Features umgesetzt werden. Darunter würden unter anderem auch Verbesserungen im Bereich der Generics, neue Scripting-Features oder Syntax-Sugar fallen.

Die Pläne en Detail – zumindest mehr oder weniger – findet man in einer überaus umfangreichen Mail in der Mailing-List.

Swift 3 – die Retrospektive

Man kann es nicht oft genug sagen: Noch ist Swift in Version 3 noch gar nicht erschienen; dennoch wirft Lattner bereits einen Blick zurück.

So war es für ihn und das Team eine komplett neue Erfahrung, Swift als Open-Source-Projekt zu entwickeln. Vor allem eine gewisse Unvorhersagbarkeit was Features und vor allem ein fixes Releasedatum angeht, seien zu Beginn ein Problem gewesen. Das Endergebnis jedoch sei wesentlich besser, was all die Tradeoffs mit Leichtigkeit in Vergessenheit geraten lasse.

Am Ende jedoch bleibt eine unumstößliche Erfahrung, die wohl jeder schon gemacht hat, der in Open-Source-Projekten mitwirkt:

Open source is pretty great.  It has been incredible to see such a vibrant community working so well together, and to see you come together practically overnight.  It is really fantastic to work with such a talented and enthusiastic group of people!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -