swift-evolutionメーリングリストの先日のポストで，Swiftを開発したChris Lattner氏は，Swift 3を定義する上で指針となるいくつかの基準について概説すると同時に，互換性のない変更が取り入れられる予定であることを明らかにした。
新機能の設計や実装の本質に不明な点がいくつもある以上，Swift 3が最終的にどのようなものになるかを予測するのが難しいのは事実だが，Latter氏は主な目標や，それを実現するための手段に注目している。
Swift 3 […] は，もっと多くの人たちにSwiftを採用してもらうための，次の原動力となるものです。これがうまくいけば，Linux(および他のプラットフォーム)上でCorelibs + Swiftが実現します。SwiftPM [Swift Package Manager]が独自の存在に成長して，Swift言語もさらに完成度を高めることで，新たなオーディエンスの参加を期待できると思っています。
Swift 3のスコープの明確な定義に加えて，Lattner氏は，多くの“グッドアイデア”についても，それがコアモデルに影響しない範囲で言語を大きく拡張するものであるならば，将来のために確保しておきたい，と述べている。
Swift 3では首尾一貫したアプローチを取ってきたつもりです。基本言語のコア部分での欠点の修正，実装上の問題の修正，ABIの安定性に影響するレジリエンス機能の設計を，最小限の言語拡張で実現することに焦点を絞ってきました。
Swift 3では見送られる可能性の高い機能はフレキシブルなメンバ初期化(flexible memberwise initialization)などだ。それに対して，lazyや@MSManagedなどの実装に関わるコンパイラマジックを一掃する上で有効なプロパティビヘイビア(property behaviours)などが，Swift 3で要望の多い機能としてあげられている。
その一方でSwift 3には，Cocoaメソッドをより“Swift風”にするための名称変更を中心とした，大きな仕様変更も予定されている。
Cocoaの名称変更が実施されるため，Swift 2からSwift 3への移行で，コードの互換性が損なわれることは避けられないでしょう。高度なマイグレーション技術が改めて開発されることになると思います。
Cocoaメソッドの名称変更に伴って，いくつかの変更も行われることになるはずだ。
-
ストリーミングメソッドの名称から，期待される引数の型を指定するための不要な単語が削除される。例えば，
let content = listItemView.text.stringByTrimmingCharactersInSet(NSCharacterSet.whitespaceAndNewlineCharacterSet())は，次のように変更される。
let content = listItemView.text.trimming(.whitespaceAndNewlines) -
Foundation APIの
NSプレフィックスが削除される。例えばvar NSDateComponentUndefined: Int { get }は，var dateComponentUndefined: Int { get }になる。 -
options,attributes,infoといった名称の付いたメソッド定義に対して，null指定可能な末尾引数ならばnil, 配列やディクショナリでは[]および[:]のようなデフォルト引数が追加される。
Swift 3がソース非互換になるというLattner氏の発言に対しては，いくつかの不満の声も上がっている。氏自身，“開発者目線”でのSwiftの変更を長く続けられないことは認識しており，Swift 3からSwift 4への移行は今回よりも簡単なものになることを望んでいる，と述べている。さらにAppleは，移行のためのスイッチ(-swift3-migration)を用意して，Swift 2.2からSwift 3に移植作業を容易にすることも計画している。