Mit der Geheimniskrämerei ist es vorbei: Seit Swift ein Open-Source-Projekt ist, verläuft die Entwicklung transparent. Dieser Beitrag fasst zusammen, wie Swift 3 voraussichtlich aussehen wird. Diese Pläne ändern sich laufend. Dieser Beitrag wird deswegen regelmäßig aktualisiert. (Erste Version 11.12.2015, letztes Update: 1.8.2016.)

PS: Die Liste der Änderungen hat inzwischen schon fast epische Ausmaße angenommen. Dieser Blogbeitrag ist eine Zusammenfassung der Neuerung, die mir am wichtigsten erscheinen, aber keine vollständige Referenz. Werfen Sie gegebenenfalls einen Blick auf die Seite https://github.com/apple/swift-evolution!

Die Basis: Swift 2.2

Seit Ende März 2016 ist Swift 2.2 verfügbar. Für dieses Blog habe ich einen ausführlichen Überblick über alle Neuerungen in Swift 2.2 verfasst. Der Vollständigkeit halber fasse ich die wichtigsten Punkte hier nochmals in Kurzform zusammen:

• keine klassische-for-Schleife mehr (deprecated in Swift 2.2, nicht mehr verfügbar in Swift 3)
• kein x++/x-- mehr (ebenso)
• neue Selektor-Syntax
• associatedtype-Schlüsselwort für generische Parameter von Protokollen (anstelle von typealias)
• keine var-Parameter mehr
• Swift-Schlüsselwörter dürfen als Parameternamen verwendet werden
• Tupel-Vergleiche

Diese Seite konzentriert sich im Weiteren auf die geplanten Neuerungen in Swift 3.0 relativ zu Swift 2.2.

Release Process / Zeitplan

Lange Zeit war unklar, wann Swift fertig werden würde. Eine Weile hieß es lediglich vage: late 2016. Apple wird aber auch mit Swift 3.0 den üblichen Release-Zyklus einzuhalten: Wenn es im Herbst neue iPhones gibt und iOS 10 fertig wird, dann wird auch Xcode 8 mit Swift ausgeliefert.

Die Entwicklung von Swift 3 wurde mit 27.7. abgeschlossen:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024424.html

Letzte Änderungen wurden noch bis 29.7. akzeptiert. Von nun an soll nur noch an der Stabilität gefeilt werden. Diese Deadline führt leider dazu, dass etliche Features für Swift 3, die offiziell beschlossen wurden, nun doch nicht in Swift 3 enthalten sein werden. Der Grund: Die Implementierung ist ausständig, es fehlt an der Zeit, die Features zu realisieren und zu testen.

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160725/002520.html

Bereits beschlossene Features werden teilweise in Swift 3.n nachgereicht (wenn dies die Kompatibilität vorhandenen Swift-3-Codes nicht beeinträchtigt); die restlichen Ideen werden aber auf Swift 4 verschoben oder müssen überhaupt neu evaluiert werden:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html

In der folgenden E-Mail bestätigt Chris Lattner, dass akzeptierte Proposals nicht automatisch auch implementiert werden. Wenn sich niemand innerhalb oder außerhalb von Apple findet, der den Vorschlag tatsächlich realisiert, dann war es eben nur eine Idee und nicht mehr:

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025672.html

Neben diesen tagesaktuellen Informationen aus der Swift-Entwickler-Mailinglist gibt es auch ein offizielles Dokument zum Release Process. Dieses ist aber schon lange nicht mehr aktualisiert worden:

https://swift.org/blog/swift-3-0-release-process/

Ausgesprochen hilfreich ist dagegen diese Seite, die den Status aller Swift-Proposals zusammenfasst:

http://apple.github.io/swift-evolution/

Swift 3.x und Swift 4: Swift 3 ist noch nicht fertig, aber Swift 3.x und Swift 4 sind schon in Planung. Im Frühjahr 2017 soll es Swift 3.x mit einigen kleineren Erweiterungen geben. Im Herbst 2017 folgt dann Swift 4. Den aktuellen Planungsstand fasst dieses Posting zusammen. Wichtigstes Ziel ist der Abschluss der ABI-Stabilität — also ein Ziel, das eigentlich schon Swift 3 verfolgte. So sollen Generics weiter verbessert und die Standardbibliotheken dann daran angepasst werden. Verbesserungen soll es auch beim Umgang mit Zeichenketten und bei der Speicherverwaltung geben. Schon jetzt auf Swift 5 (!) verschoben ist die Integration von Multitasking-Elementen in die Sprache (asynchrone Programmierung). Demnächst werde ich in diesem Blog eine eigene Seite einrichten, die sich mit Swift 4 auseinandersetzt.

Kompatibilität und Sprachstabilität

Auch Apple ist sich bewusst, dass die ständigen Änderungen in Swift für all jene, die schon produktiv mit Swift arbeiten, mühsam sind. Deswegen hatte Apple geplant, mit Version 3.0 möglichst viele Interna und Strukturen so weit zu fixieren werden, dass weitere Updates an der Sprache additiv durchgeführt werden können, also durch Ergänzungen/Erweiterungen, die vorhandenen Code nicht beeinflussen.

Bereits im Mai 2016 verkündete Chris Latter von Apple diesbezüglich den ersten Rückzieher: Es seien auch nach Swift 3.0 Änderungen an der Syntax denkbar (z.B. bei Generics), auch wenn man versuchen wird, diese zu minimieren und den Migrationsaufwand nach Swift 3 möglichst klein zu halten. Die ursprünglich anvisierte ABI-Stabilität war damit aber schon aufgeweicht. (ABI = Application Binary Interface, siehe ABI vs API auf Stackoverflow.)

https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html

Doch auch das ist Schnee von gestern. Wie oben ausgeführt, gelingt es nicht einmal, alle beschlossenen Änderungen tatsächlich in Swift 3 zu implementieren. Sie werden auf Swift 3.x bzw. Swift 4 verschoben.

Und wie lassen sich die Pläne für Swift 3.x und 4 mit der versprochenen Kompatibilität vereinen? Das Entwicklerteam greift hier zu einem Taschenspielertrick: Der Swift-Compiler soll so gestaltet werden,

• dass Code in einer beliebigen Versionsnummer ab 3.0 kompiliert werden kann
• und dass Komponenten (Bibliotheken), die mit unterschiedlichen Swift-Versionen ab 3.0 kompiliert wurden, zu einem gemeinsamen Programm vereint werden können.

Wie das im Detail funktionieren soll, war Ende Juli 2016 noch unklar:

https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160725/002520.html

Erste Details, die den Umgang mit Packages betreffen, verrät Proposal 0135.

Auf dem Papier hält Apple damit seinen Vorsatz ein, dass Swift-Code ab der Version 3.0 in Zukunft ohne Änderungen weiter kompiliert und ausgeführt werden kann. Aber wer sich erhofft hat, dass mit Swift 3.0 endlich eine gewisse Ruhe in die Sprachentwicklung einkehren würde, der wird enttäuscht. De-facto wird es wohl eher so aussehen, dass eigener Swift-Code weiterhin mit jeder neuen Xcode-Version an die dann aktuelle Swift-Version angepasst werden muss.

Naturgemäß ist das nicht nur für Entwickler, sondern auch für Blog/Web/Buch-Autoren unerfreulich: Jede Anleitung, jedes Rezept, jeder Lösungsvorschlag auf stackoverflow müsste eigentlich angeben, auf welche Swift-Version sie/es/er sich bezieht. Eine Anleitung, die für Swift 3.0 gilt, kann in Swift 3.1 schon wieder falsch sein. Tatsächlich ist das natürlich nicht der Fall und stiftet so viel Verwirrung. (Grundsätzlich gilt das auch für andere Programmiersprachen, allerdings ist das Tempo der Swift-Sprachentwicklung unglaublich hoch.)

Besonders problematisch ist die nur eingeschränkt gegebene Kompatibilität für die Linux-Version von Swift: Da es unter Linux kein Xcode gibt, fehlt der darin enthaltene Code-Migrator zur jeweils aktuellen Swift-Version. Ohne dieses Werkzeug lassen sich größere Code-Menge aber nicht vernünftig auf dem gerade aktuellen Stand von Swift halten.

Standard Library

Nicht nur Swift wird aktualisiert, sondern auch die Swift Standard Library, also die Sammlung von Klassen und Protokollen, die in jedem Swift-Programm (auch ohne Foundation!) zur Verfügung steht. Den aktuellen Zustand der Standard Library können Sie hier nachlesen:

• http://swiftdoc.org/
• https://developer.apple.com/reference/swift

Umgang mit Aufzählungen (Collections, Sequences)

Teil der Standard Library sind diverse Aufzählungsklassen. Deren Methoden index.successor(), index.predecessor(), index.advanced(by:) und index.distance(to:) werden in Zukunft nicht mehr auf das Index-Element angewendet, sondern direkt auf ein Objekt der Basisklasse, also beispielsweise in der Form mycollection.index(after: myindex). Der folgende Code stammt aus dem Proposal 0065:

// Swift 2.2
var i = c.index { $0 % 2 == 0 }
let j = i.successor()
print(c[j])

// Swift 3
var i = c.index { $0 % 2 == 0 }   // No change in algorithm API.
let j = c.index(after: i)         // Advancing an index requires a collection instance.
print(c[j])                       // No change in subscripting.

Ebenfalls beschlossen ist die Implementierung von zwei neuen Methoden zur Verarbeitung der Elemente einer Collection: mycollection.prefix(while:) und mycollection.drop(while:). Details: Proposal 0045

Verbessert wird auch der Umgang mit Slices, also mit Teilmengen von Aufzählungen. Laut Proposal 0093 kann über die neue Read-only-Eigenschaft base auf die zugrundeliegende Aufzählung zugegriffen werden, was in manchen Fällen effizientere Algorithmen ermöglicht.

Vollkommen neu ist die Methoden sequence, mit der auf eine sehr allgemeingültige Art und Weise lazy sequences gebildet werden können. Details: Proposal 0094

Verbesserte Schnittstellen zu externen Bibliotheken

Die Nutzung der für Objective C konzipierten Bibliotheken (z.B. Foundation) und diverser XxxKits unter Swift 2 ist sperrig, unübersichtlich und un-swift — das bemerkt jeder, der auch nur wenige Tage mit Swift programmiert. Auch in meinem Buch habe ich das mehrfach kritisch angemerkt.

Nicht einmal Apple kann deswegen alle Bibliotheken neu implementieren. Stattdessen wurde beschlossen, einfach die Schnittstellen zu den Bibliotheken speziell für Swift zu optimieren. Das ist ein relativ pragmatischer Ansatz, der zwar keine perfekte Lösung verspricht, aber zumindest eine große Verbesserung.

Details können Sie in Proposal 0005, Proposal 0006, Proposal 0023 sowie in der Big-three-Zusammenfassung von Erica Sadun nachlesen. Gewissermaßen die ultimative Referenz, wie Bibliotheken in Zukunft Swift-tauglich werden sollen, geben die API Design Guidelines.

In der Foundation-Bibliothek werden viele (aber nicht alle) NS-Präfixe abgeschafft. Detaillierte Regeln, unter welchen Umständen der NS-Prefix eliminiert und bei welchen Klassen er erhalten bleiben soll, können Sie im Proposal 0086 nachlesen.

In diesem Zusammenhang ebenfalls erwähnenswert ist der ebenfalls bereits akzeptierte Proposal 0033: Demzufolgen werden in Objective-C-Code deklarierte Konstanten in Swift als Enums oder Structs verfügbar gemacht. Das erhöht nicht nur die Lesbarkeit des Codes, sondern auch die Typensicherheit.

Ebenfalls bereits beschlossen ist eine neue Schnittstelle zur libdispatch-Bibliothek zur asynchronen Programmierung, siehe Proposal 0088. Welche Auswirkungen das hat, geht aus dem folgenden Listing hervor (übernommen aus dem Proposal):

// vorher
let queue = dispatch_queue_create("com.test.myqueue", nil)
dispatch_async(queue) {
    print("Hello World")
}

// nachher (Swift 3)
let queue = DispatchQueue(label: "com.test.myqueue")
queue.asynchronously {
    print("Hello World")
}

Core Libraries

Die Foundation-Bibliothek und die Bibliotheken libdispatch und XCTest sollen in Swift neu implementiert werden. Das primäre Ziel ist hier weniger die Optimierung der Schnittstelle zu Swift. Vielmehr sollen für Linux, Windows etc. zumindest Grundfunktionen zur Verfügung gestellt werden. Momentan ähnelt Swift unter Linux ja einer Insel in der Mitte des Pazifik: Sie können damit Algorithmen testen, aber nicht viel mehr. Jeder Zugriff auf Funktionen/Bibliotheken des Betriebssystem ist mit hohem (Code-)Aufwand verbunden. Indem dem Swift eine Open-Source-Version der Foundation-Bibliothek zur Seite gestellt wird, soll dieses Problem ein wenig gemindert werden. Weitere Informationen können Sie hier nachlesen. Wie weit die Arbeiten vorangeschritten sind, geht aus dieser Status-Seite hervor, die allerdings zuletzt im Dezember 2015 aktualisiert wurde.

Generics

Der Umgang mit generische Typen soll in Swift 3 perfektioniert werden. In der Swift-3-Entwicklerversion bereits implementiert ist die generische Erweiterung von typealias (Ankündigung in der swift.dev-Mailing-Liste, Proposal 0047):

typealias StringDictionary<T> = Dictionary<String, T>
typealias IntFunction<T> = (T) -> Int
typealias MatchingTriple<T> = (T, T, T)
typealias BackwardTriple<T1,T2,T3> = (T3, T2, T1)

Ebenfalls beschlossen ist die Neupositionierung der where-Klausel nach der Parameterliste: Swift bietet die Möglichkeit, Deklarationen mit where-Bedingungen für die generischen Typen zu versehen. Die where-Klausel wurde bisher vor der Parameterliste angegeben, in Zukunft danach. Das soll die Deklaration besser lesbar machen. (Wirklich gut lesbar wird eine mehrzeilige Deklaration aber nie werden …) Details: Proposal 0081, Beispielcode aus dem Proposal:

// aktuell (Swift 2)
func anyCommonElements<T : SequenceType, 
                       U : SequenceType where T.Generator.Element: Equatable,
                                              T.Generator.Element == U.Generator.Element>
  (lhs: T, _ rhs: U) -> Bool
{
    ...
}

// neu (Swift 3)
func anyCommonElements<T : SequenceType, 
                       U : SequenceType>(lhs: T, _ rhs: U) -> Bool 
  where T.Generator.Element: Equatable,
        T.Generator.Element == U.Generator.Element
{
    ...
}

Eine weitere Neuerung betrifft die Syntax protocol<A, B, C>, die durch A & B & C ersetzt wird, außerdem protocol<> durch Any. Details: Proposal 0095, Beispielcode aus dem Proposal:

protocol A { }
protocol B { }

// Existential
func firstFunc(x: A & B) { ... }

// Generic
func secondFunc<T : A & B>(x: T) { ... }

Zu den weiteren geplanten Neuerungen zählen rekursive Contraints. Eine recht detaillierte Zusammenstellung dessen, was hier für Swift 3.0 geplant ist, geben die beiden folgenden Beiträge/Diskussionen auf der der swift.evolution-Mailingliste:

• Swift 3 Generics (Dezember 2015)
• Manifesto — Completing Generics (März 2016)

In diesem Zusammenhang ist auch dieser Grundlagentext lesenswert. Er fasst die Konzepte der Generics-Implementierung auf der Basis von Swift 2 zusammen.

Sonstiges (geordnet nach Proposal-Nummer)

• Keine Curried-Funktionen mehr: Swift bietet momentan die Möglichkeit, Curried Functions zu bilden, also Funktionen, bei denen vorerst nur ein Teil der Parameter festgelegt wird und der Rest weiter als Funktion genutzt werden kann. Diese relativ komplexe Syntax, auf die ich in meinem Buch gar nicht eingegangen bin, soll in Swift 3 eliminiert werden. Links: Proposal 0002, Wikipedia, Introduction to Function Currying in Swift, Instance Methods are Curried Functions in Swift, Beschreibung im Swift-Buch von Apple

• Neue inout-Syntax: inout-Parameter werden in Zukunft so gekennzeichnet: f(paraname: inout Typename). Die bisherige Syntax lautete f(inout paraname: Typename). Details: Proposal 0031

• Playground-Literale: Im Playground können Literale für Farben, Bilder und Dateien aktuell z.B. in der Form [#Color(colorLiteralRed: red, green: green, blue: blue, alpha: alpha)#] dargestellt werden, also zwischen [# und #]. Die neue Syntax lautet #colorLiteral(...), #imageLiteral(...) und #fileLiteral(...). Details: Proposal 0039

• Attributparameter: Parameter von Funktionen/Methoden werden in der Form f(name:wert) übergeben, also z.B. f(a:1, b:2). Diese Syntax soll in Zukunft auch für Attribute gelten, also z.B. @availability(iOS, introduced: 2.0) anstelle von @availability(iOS, introduced=2.0). Details: Proposal 0040

• Mehr Flexibilität in switch/case let: Schon bisher ist es möglich, switch-Varianten mit Variablenzuweisungen zu kombinieren (case let). Swift 3 wird hier in meiner Ansicht nach recht exotischen Anwendungsfällen noch mehr Flexibilität bieten. Details: Proposal 0043

• Alle Parameter sind gleich: Momentan ist der erste Parameter einer Methode unbenannt, alle weiteren sind benannt. Die Funktion func f(a:Int, b:Int) wird also mit f(1, b:2) aufgerufen. In Swift 3.0 werden dagegen alle Parameter einheitlich behandelt. Die erwähnte Funktion f muss dann mit f(a:1, b:2) aufgerufen werden. Das ist wesentlich logischer, wird aber zu großen Umstellungsproblemen führen, vor allem in der Übergangsphase zwischen Swift 2.2 und 3.0, wenn Sie parallel Code für beide Swift-Versionen schreiben möchten. Details: Proposal 0046

• Warnung, wenn das Ergebnis einer Funktion/Methode ignoriert wird: In Swift 3 wird der Aufruf von non-void Funktionen/Methoden ohne Berücksichtigung des Ergebnisses zu einer Warnung führen. Dieses Verhalten kann schon jetzt mit dem Attribut @warn_unused_result erreicht werden. In Swift 3 können Sie die Warnung mit dem Attribut @discardableResult unterdrücken. Details: Proposal 0047

• Keine let-Parameter in Funktionen/Methoden: Aktuell können Parameter von Funktionen oder Methoden mit let gekennzeichnet werden, um darauf hinzuweisen, dass diese Parameter in der Funktion/Methode nicht geändert werden können (func f(let x:int)). Das gilt ohnedies per Default, weswegen das Schlüsselwort let in diesem Kontext eliminiert wird. Details: Proposal 0053

• Die Reihenfolge von default-Parametern muss eingehalten werden: Bisher konnten Parameter, für die Funktionen/Methoden einen Default-Wert definieren, beim Aufruf in beliebiger Reihenfolge angegeben werden. In Swift 3 muss die gleiche Reihenfolge wie bei der Deklaration eingehalten werden. Proposal 0060

• Funktionsdeklarationen erfordern immer Klammern: Bisher war es möglich, Funktionen mit genau einem Parameter in der Form Int -> Float zu deklarieren. Bei null oder mehr Parametern waren schon bisher immer Klammern notwendig (() -> Float oder (Int, Double) -> (Double)). In Zukunft sind auch bei einparametrigen Funktionen immer Klammern erforderlich, also (Int) -> Float. Details Proposal 0066

• Erweitertes Protokoll für Fließkommazahlen: Das Protokoll FloatingPoint war bisher sehr minimalistisch. In Swift 3 wird es deutlich erweitert und enthält nun wesentlich mehr Funktionen. Details: Proposal 0067

• Self in Werttypen: Das Schlüsselwort Self (groß geschrieben) konnte schon bisher in Klassen verwendet werden, um auf den Typ der Klasse zu verweisen. Das funktioniert jetzt auch in Strukturen bzw. ganz allgemein in Werttypen (value types). Ursprünglich schlug das Proposal 0068 auch vor, x.dynamicType durch x.Self zu ersetzen. Dieser Teil des Proposals wurde aber (vorerst) nicht akzeptiert — möglicherweise gibt es hierfür später ein neues Proposal.

• Fast alle Swift-Schlüsselwörter sind als Attributnamen zulässig: Swift-Schlüsselwörter durften bisher nicht zur Benennung von Enum-Elementen, sowie für Methoden und Eigenschaften von Strukturen/Klassen/etc. verwendet werden. In Zukunft ist dies erlaubt. Details: Proposal 0071

• Keine impliziten (automatischen) Typumwandlungen: In Swift 1 gab es automatische Typumwandlungen zwischen elementaren Swift- und Objective-C-Datentypen, z.B. beim Aufruf von Foundation-Funktionen/Methoden. In Swift 1.2 wurde dieser Automatismus reduziert: Seither erfolgt nur noch die Umwandlung von Swift-Typen in Objective-C-Typen automatisch (z.B. String --> NSString), nicht aber in die umgekehrte Richtung. Swift 3 wird auf alle automatischen Umwandlungen verzichten. Programmierer müssen also häufiger als bisher explizites Casting verwenden. Details: Proposal 0072

• Neue Syntax zur Formulierung der Operator-Priorität: Momentan bestimmen numerische Konstanten, in welcher Reihenfolge Operatoren verarbeitet werden. Das System ist simpel, aber inflexibel. Proposal 0077 schlägt deswegen vor, die Rangfolge relativ zu anderen Operatoren anzugeben. Dieser Vorschlag ist bereits akzeptiert, es soll aber noch Änderungen geben.

• Neue init-Funktionen für Zahlen: Für alle numerischen Typen gibt es neue Init-Funktionen der Form init?(exactly value: FromTyp), wobei FromTyp eine der folgenden Typen sein darf: Int, Int8, Int16, Int32, Int64, UInt, UInt8, UInt16, UInt32, UInt64, Float, Double und auf manchen Plattformen auch Float80. Details: Proposal 0080

• Teilweise Abschaffung des NS-Präfix: Viele NS-Präfixe werden eliminiert, wobei Proposal 0086 genaue Regeln definiert, unter welchen Umständen der NS-Prefix eliminiert und bei welchen Klassen er erhalten bleiben soll.

• Geänderte if-let-, guard- und where-Syntax: Aus if let a=b, c=d wird if let a=b, let c=d, und aus if let a=b where c==d wird if let a=b, c==d. Analog wurde auch die guard-Syntax geändert. Details: Proposal 0099

• Besserer Umgang mit NSError: Aktuell werden Objective-C-Funktionen und -Methoden mit einem NSError-Parameter in Swift mit throws abgebildet. Allerdings ist das Bridging zwischen NSError und dem ErrorProtocol suboptimal. Hier wird es diverse Verbesserungen geben. Unter anderem werden drei neue Protokolle eingeführt: LocalizedError, RecoverableError und CustomNSError. Außerdem soll ErrorProtocol einfach in Error umbenannt werden. Details: Proposal 0112

• Klarerer Protokollnamen für Literale: Die Protokolle XxxLiteralConvertible werden umbenannt in ExpressibleByXxxLiteral. Details: Proposal 0115

• Unterscheidung zwischen public und open: Bisher konnten öffentliche Klassen (public) gleichermaßen verwendet und abgeleitet werden. Wer seine Klasse als public deklarierte, erlaubt also nicht nur die Nutzung der Klasse, sondern auch ihre Verwendung als Basis für eigene, abgeleitete Klassen. In Zukunft erlaubt public nur die Nutzung der Klasse. Ist die Klasse auch als Basis für andere, vererbte Klassen vorgesehen, muss sie als open deklariert werden. Analog bedeutet public bei Methoden, dass die Methode aufgerufen werden kann. Darf die Methode auch überschrieben (überladen) werden, muss sie mit open deklariert werden. Details: Proposal 0117

• Umbenennung der Closure-Parameter in der Standardbibliothek: Diverse Parameter für Closures in der Swift-Standardbibliothek werden umbenannt, um eine bessere Lesbarkeit des resultierenden Codes zu erreichen. Ein besonders prägnantes Beispiel: aus words.sort(isOrderedBefore: >) wird words.sort(by: >). Details: Proposal 0118

• Weniger Comparable-Operatoren: Das Protokoll Comparable verlangte bisher außer den durch Equatable vorgegebenen Operatoren die Implementierung von acht weiteren Operatoren: Die Operatoren <, <=, > und >= mussten jeweils zweifach implementiert werden, einmal für den Typ T und einmal für den Optional-Typ T?. Die Optional-Varianten entfallen in Zukunft. Details: Proposal 0121

• Umbenennung von flatten zu joined: Aus flatten wird joined. Details: Proposal 0133

Das kommt nicht bzw. erst nach Swift 3

• Multithreading/Asynchrone Programmierung: Swift 3 wird keine inhärenten Funktionen zur nebenläufigen Programmierung erhalten. Swift greift hierfür auf Foundation-Klassen, pthreads, libdispatch etc. zurück. Eine Swift-interne Implementierung asynchroner Funktionen ist aber erst für Swift 5 angedacht.

• Property Behaviors: Property Behaviors sollen die Möglichkeit geben, Schlüsselwörter wie lazy oder delayedMutable sowie Property Observers (didSet, willSet) direkt als Swift-Code zu implementieren. Proposal 0030 ist zwar momentan rejected, Chris Lattner verspricht aber die Wiederaufnahme der Diskussion nach der Fertigstellung von Swift 3.

• Besserer Umgang mit self in Closures: Simplified notation for avoiding the [weak self]/strongSelf dance with closures, daraus wurde später der Proposal 0079

• Bibliotheken: Apple kann und will nicht alle iOS-, OS-X-Bibliotheken etc. neu implementieren. Die Foundation-Bibliothek ist eine Ausnahme, alle anderen Bibliotheken sollen im Wesentlichen bleiben wie sie sind. Allerdings wird es massive Änderungen geben, wie die Methoden der iOS- und OS-X-Bibliotheken von Swift aus genutzt werden können (siehe die Überschrift »Verbesserte Schnittstellen zu den Bibliotheken« weiter oben).

• Die Wunschlisten von Erica Sadun: Die in der swift.evolution-Liste sehr aktive Swift-Buchautorin Erica Sadun hat bereits im März 2016 eine Art private Wunschliste weiterer Änderungen zusammengestellt. Im Mai folgten der Playground-Wunschbrief an das Christkind und eine Liste von Features, die vermutlich auf Swift > 3 verschoben sind oder gar nicht realisiert werden. Alle drei Artikel sind lesenswert.

• Mehrzeilige Zeichenketten: Auf der swift.evolution-Liste wurde Ende April intensiv darüber diskutiert, ob es in Swift eine syntaktisch einfache Möglichkeit zur Formulierung mehrzeiliger Zeichenketten geben soll. Bisher gibt es dazu weder einen Konsensus noch ein konkretes Proposal.

• Sprachänderungen, die Apple ablehnt: Auf der Seite Commonly Rejected Changes finden Sie eine Zusammenstellung häufig vorgeschlagener Änderungswünsche, die wenig bzw. keine Aussicht auf Erfolg haben, weil sie von Apple festgelegten Sprachdesign-Richtlinien widersprechen. Dazu zählen die Veränderung des Ternary Operators, die Abschaffung geschwungener Klammen zugunsten einer syntaktisch vorgeschriebenen Einrückung (wie in Python), eine andere Definition der Closure-Syntax oder die Verwendung einfacher Apostrophe für Character-Literale (wie in Java).

Swift-Version feststellen

Um die aktuelle Swift-Version Ihrer Xcode-Installation festzustellen, führen Sie in einem Terminal-Fensters swift -version aus. Xcode 7.3 enthält die Swift-Version 2.2 (zuletzt getestet Anfang Juni 2016):

swift -version
  Apple Swift version 2.2 (swiftlang-703.0.18.5 clang-703.0.31)
  Target: x86_64-apple-macosx10.9

Der erste Beta von Xcode 8 enthält standardmäßig Swift 3:

cd /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
./swift -version
  Apple Swift version 3.0 (swiftlang-800.0.30 clang-800.0.24)
  Target: x86_64-apple-macosx10.9

Apps für iOS 10 können vorübergehend alternativ mit Swift 2.3 entwickelt werden, das weitgehend mit Swift 2.2 identisch ist.

Quellen

• https://github.com/apple/swift-evolution
• http://apple.github.io/swift-evolution (Proposal-Übersicht, geordnet nach Status)
• https://github.com/apple/swift-evolution/tree/master/proposals (Proposal-Übersicht geordnet nach Nummern; achten Sie auf die Status-Zeile im jeweiligen Proposal!)
• https://swift.org/core-libraries
• https://lists.swift.org/pipermail/swift-evolution-announce
• https://lists.swift.org/pipermail/swift-evolution
• https://lists.swift.org/pipermail/swift-dev
• http://ericasadun.com (laufende Berichterstattung über geplante Änderungen)
• https://swift.org/migration-guide/
• https://swift.org/documentation/api-design-guidelines/
• https://developer.apple.com/reference/swift
• https://github.com/apple/swift/blob/master/docs/ABI.rst