Swift 3.0 日本語化計画

https://developer.apple.com/swift/blog/ より。

2016年10月12日

Objective-C の id と Swift の Any

Swift 3 は、以前のバージョンよりも強力な方法で Objective-C API とインターフェイスします。例えば、Swift 2 は、通常、クラス型の値のみを保持することができる、Swift の AnyObject 型にObjective-C では id 型をマッピングしました。Swift 2 はまた、いくつかのブリッジされた値型を AnyObject への暗黙的な変換を提供しており、値型は String、Array、Dictionary、Set、及びいくつかの数字であり、ネーティブな Swift の型が Cocoa API で容易に容易に使えるように便利のためです。CoCoa API は、NSString、NSArray、または Foundation からの他のコンテナ・クラスを予想しています。これらの変換は、言語の残りの部分と矛盾しており、正確な AnyObject の使用を理解することを困難にし、それでバグが生じました。

Swift 3 では、Objective-C の内の id 型は今やクラス、列挙型、構造体、または他の全ての Swift の型かどうか、全ての型の値を記述する Swift 内の Any の型にマッピングされます。Swift で定義した値型はマニュアル"box" 型の必要性を排除し、Objective-C の API へ渡され、Swift の型として抽出することができるため、この変更は、Swift での Objective-C API を、より柔軟にします。これらの利点はまた、コレクションを拡張します：Objective-C のコレクション型 NSArray、NSDictionary、及び NSSet は、以前は AnyObject の要素を受け入れただけだが、現在は、Any の型の要素を保持できます。Dictionary や Set のようなハッシュ化されたコンテナについては、Swift の Hashable プロトコルに準拠した全ての型の値を保持することができる新しい型の AnyHashable があります。要約すると、型マッピングは Swift 2 から Swift 3 に以下のように変理ました。

多くの場合、あなたのコードは、この変化に応じて大幅に変更する必要はありません。Swift 2 で暗黙的に AnyObject に変換する値型に依存していたコードは Any として渡すことで、Swift 3 でそのまま動作し続けるでしょう。ただし、変数やメソッドの宣言された型を変更し、Swift 3 で最高の経験を取得する必要がある場所があります。また、あなたのコードが明示的に AnyObject を使用し、NSString、NSArray、NSDictionary のような Cocoa クラスを使用している場合、as NSString や as STring を使用して明示的なキャストを導入する必要があります。というのも、オブジェクトと値型の間の暗黙的な変換はもはや Swift 3 で許可されていないからです。Xcode の自動移植機は、Swift 2 から 3 に移行する時、コードがコンパイルされるようにする変更を最小にしますが、その結果は、常に最もエレガントなものではないかもしれません。この記事では、id を Any にあなたのコードを変更する利点や落とし穴を探し、それらを説明します。

メソッドのオーバーライドとプロトコルへの準拠

Objective-C のクラスをサブクラス化し、そのメソッドをオーバーライドし、または Objective-C のプロトコルに準拠する場合、メソッドの型シグネチャは、親メソッドが、Objective-C の id を使用したときに更新する必要があります。一般的な例としては、NSObject クラスのの isEqual: メソッドと、NSCopying プロトコルの copyWithZone: メソッドです。Swift 2 では、NSCopying　に準拠する NSObject のサブクラスは、以下のように記述します。

// Swift 2
class Foo: NSObject, NSCopying {
	override func isEqual(_ x: AnyObject?) -> Bool { ... }
	func copyWithZone(_ zone: NSZone?) -> AnyObject { ... }
}

Swift 3 では、copyWithZone(_:) から命名変更し、copy(with:) に変えて、また、AnyObject の代わりに Any を使用するようにこれらのメソッドのシグネチャを変更する必要があります：

// Swift 3
class Foo: NSObject, NSCopying {
	override func isEqual(_ x: Any?) -> Bool { ... }
	func copy(with zone: NSZone?) -> Any { ... }
}

型のないコレクション

プロパティリスト、JSON、およびユーザ情報辞書は Cocoa に共通しており、CoCoa は、ネイティブにこれらを型のないコレクションとして表します。Swift 2 では、値型を処理するための暗黙のブリッジ変換に頼って、この目的のために AnyObject または NSObject の要素を持つ Array、Dictionary、または Set をビルドする必要がありました：

// Swift 2
struct State {
	var name: String
	var abbreviation: String
	var population: Int

	var asPropertyList: [NSObject: AnyObject] {
		var result: [NSObject: AnyObject] = [:]
		// Implicit conversions turn String into NSString here…
		result["name"] = self.name
		result["abbreviation"] = self.abbreviation
		// …and Int into NSNumber here.
		result["population"] = self.population
		return result
	}
}

let california = State(name: "California",
					   abbreviation: "CA",
					   population: 39_000_000)
NSNotification(name: "foo", object: nil,
			   userInfo: california.asPropertyList)

代わりに、NSDictionary のような Cocoa のコンテナクラスを、使用できます：

// Swift 2
struct State {
	var name: String
	var abbreviation: String
	var population: Int

	var asPropertyList: NSDictionary {
		var result = NSMutableDictionary()
		// Implicit conversions turn String into NSString here…
		result["name"] = self.name
		result["abbreviation"] = self.abbreviation
		// …and Int into NSNumber here.
		result["population"] = self.population
		return result.copy()
	}
}
let california = State(name: "California",
					   abbreviation: "CA",
					   population: 39_000_000)
// NSDictionary then implicitly converts to [NSObject: AnyObject] here.
NSNotification(name: "foo", object: nil,
			   userInfo: california.asPropertyList)

Swift 3 では、暗黙的な変換がなくなっているので、上記のスニペットのどちらも動作しません。移行機は、このコードを動くように維持するため as 変換を使用して、各々の値を変換する事を示唆するでしょうが、よりよい解決策があります。Swift は今や Any および/または AnyHashable のコレクションを受け入れるよう Cocoa API をインポートするので、我々は使うコレクション型を [NSObject:AnyObject] または NSDictionary の 代わりに [AnyHashable:Any] に他のコードを変更せずに変更できます：

// Swift 3
struct State {
	var name: String
	var abbreviation: String
	var population: Int

	// Change the dictionary type to [AnyHashable: Any] here...
	var asPropertyList: [AnyHashable: Any] {
		var result: [AnyHashable: Any] = [:]
		// No implicit conversions necessary, since String and Int are subtypes
		// of Any and AnyHashable
		result["name"] = self.name
		result["abbreviation"] = self.abbreviation
		result["population"] = self.population
		return result
	}
}
let california = State(name: "California",
					   abbreviation: "CA",
					   population: 39_000_000)
// ...and you can still use it with Cocoa API here
Notification(name: "foo", object: nil,
			 userInfo: california.asPropertyList)

AnyHashable 型

Swift の Any 型は全ての型を保持できますが、Dictionary と Set は Hashable であるキーが必要なので、Any も一般的です。Swift 3 以降、Swift の標準ライブラリは、新しい型の AnyHashable を提供します。Any と同様に、それは全ての Hashable 型のスーパータイプとして振る舞うので、String、Int、および他のハッシュ可能の型は、暗黙的に AnyHashable の値として使用でき、また AnyHashable 内部の型は、is、as、またはas? 動的キャスト演算子で動的に確認できます。AnyHashable は、Objective-C から型のない NSDictionary または NSSet オブジェクトをインポートするときに使用され、また異種のセットや辞書をビルドするための方法として、純粋の Swift にも有用です。

ブリッジされない内容の明示的な転換

特定の限られた状況下では、Swift は C と Objective-C の構築物を自動的にブリッジできません。例えば、いくつかの C と Cocoa API は、"out" または"in-out" パラメータとして id* ポインタを使用し、Swift は、静的にポインタを使用する方法を決定できないので、メモリの値にブリッジする変換は自動的に実行できません。このような場合、ポインタはまだ UnsafePointer<AnyObject> として表示されます。これらのブリッジされない API の一つを使用する必要がある場合は、あなたのコード内で as Type、または as AnyObject を使用して明示的に記述された明示的なブリッジング変換を、使用できます。

// ObjC
@interface Foo

- (void)updateString:(NSString **)string;
- (void)updateObject:(id *)obj;

@end

// Swift
func interactWith(foo: Foo) -> (String, Any) {
	var string = "string" as NSString // explicit conversion
	foo.updateString(&string) // parameter imports as UnsafeMutablePointer<NSString>
	let finishedString = string as String

	var object = "string" as AnyObject
	foo.updateObject(&object) // parameter imports as UnsafeMutablePointer<AnyObject>
	let finishedObject = object as Any

	return (finishedString, finishedObject)
}

加えて、Objective-C のプロトコルは、まだ Swift ではクラスに制約されていますが、軽量の汎用的なクラスでは Objective-C プロトコルに直接準拠した構造体や列挙型を作ることはできません。これらのプロトコルや API を持つ、String as NSString、Array as NSArray などの、明示的な変換をする必要があります。

AnyObject メンバー検索

Any は、AnyObject と同じマジックのようなメソッドの検索動作を持っていません。これは、プロパティを検索したり、型のない Objective-C のオブジェクトにメッセージを送る Swift 2 のコードを破棄する可能性があります。例えば、この Swift 2 のコード：

// Swift 2
func foo(x: NSArray) {
	// Invokes -description by magic AnyObject lookup
	print(x[0].description)
}

このコードは、Swift 3 では description は Any のメンバーではないと文句を言います。x[0] as AnyObject で値を変換することができ、動的動作を取り戻す事ができます：

// Swift 3
func foo(x: NSArray) {
	// Result of subscript is now Any, needs to be coerced to get method lookup
	print((x[0] as AnyObject).description)
}

代わりに、期待する具体的なオブジェクトタイプに値を強制キャストします：

func foo(x: NSArray) {
	// Cast to the concrete object type you expect
	print((x[0] as! NSObject).description)
}

Objective-C での Swift の値型

Any を使用すると、言語で定義できる全ての 構造体、列挙型、タプル、または他の Swift の型を保持できます。Swift 3 での Objective-C のブリッジは順番に Objective-C に id 互換のあるオブジェクトとして全ての Swift の値を提示できます。これは、Cocoa のコンテナ、userInfo 辞書、およびその他のオブジェクトのカスタムの Swift 値タイプを格納する事をはるかに簡単にします。例えば、Swift 2 では、NSNotification にその値を取り付けるために、データ型をクラスに変更し、または手動でそれらをボックスするかのいずれかの必要があるでしょう：

// Swift 2
struct CreditCard { number: UInt64, expiration: NSDate }

let PaymentMade = "PaymentMade"

// We can't attach CreditCard directly to the notification, since it
// isn't a class, and doesn't bridge.
// Wrap it in a Box class.
class Box<T> {
	let value: T
	init(value: T) { self.value = value }
}

let paymentNotification =
	NSNotification(name: PaymentMade,
				   object: Box(value: CreditCard(number: 1234_0000_0000_0000,
												 expiration: NSDate())))

Swift 3 では、我々はボックスを廃止でき、また通知に直接オブジェクトを付けられます：

// Swift 3
let PaymentMade = Notification.Name("PaymentMade")

// We can associate the CreditCard value directly with the Notification
let paymentNotification =
	Notification(name: PaymentMade,
				 object: CreditCard(number: 1234_0000_0000_0000,
									expiration: Date()))

Objective-C では、CreditCard 値は、元の Swift 型のために存在している場合ス、Swift の Equatable、Hashable、および CustomStringConvertible の実装を使用して、id と互換性のある、NSObject -準拠の、isEqual:、Hash、および description を実装するオブジェクト、として表示されます。Swift から、値は動的に元の型に戻ってそれをキャストして取得できます。

// Swift 3
let paymentCard = paymentNotification.object as! CreditCard
print(paymentCard.number) // 1234000000000000

Swift 3.0 で、Swift と Objective-C の構造体のいくつかの共通した型が、慣用的な Cocoa オブジェクトとしてではなく不透明なオブジェクトとしてブリッジされるだろう、ということに注意してください。たとえば、Int、UInt、Double、と Bool は NSNumber へブリッジするのに対し、Int8、UInt16 型、のような他のサイズ付きの数値型だけが不透明なオブジェクトとしてブリッジされます。CGRect、CGPoint、および CGSize のような Cocoa の構造体は、オブジェクトとしてで動作するほとんどの Cocoa API はそれらを NSValue インスタンスでボックスに入レルにもかかわらず、不透明なオブジェクトとしてブリッジされます。unrecognized selector sent to _SwiftValue のようなエラーが表示された場合は、それは Objective-C のコードが不透明な Swift の値型のメソッドを呼び出そうとしていることを示し、 Objective-C コードが期待するクラスのインスタンスの値をボックスに手動で入れる必要があるかもしれません。

一つの特定の検索すべき問題は Optionals です。Swift は、Any は Optional を含めて 全ての物 を保持でき、API が nonnull id を取るように宣言されている場合であっても、それを最初に確認せずに Objective-C の API に、包まれた Optional を渡すことが可能となります。これは、コンパイル時エラーではなく _SwiftValue を伴う実行時エラーとして一般的に明らかになります。Xcode 8.1 ベータ版に含まれる Swift 3.0.1 は、NSNumber、NSValue、および Optional のブリッジングで上記の制約に対処するこれらの提案を実装することにより、数値型、Objective-C の構造体、および Optional を透明にし、処理します。

• SE–0139: 数値型をブリッジし、NSNumber 及び Cocoa 構造体を NSValue にブリッジする
• SE–0140: Optional を Any に変換する時と、Optional をその Payload または NSNull にブリッジする時に警告

前方互換性の問題を回避するために、_SwiftValue クラスの不透明なオブジェクトの実装の詳細に依存しないでください、というのも Swift の将来のバージョンでは、より多くの Swift 型が慣用的な Objective-C のクラスにブリッジすることを可能にするためです。

Linux の移植性

Swift のコアライブラリでの Linux 上で実行されている Swift プログラムは、ブリッジした Objective-C ランタイムなしで、ネイティブの Swift で書かれた Foundation のバージョンを使用しています。Objective-C の Foundation の実装を使用して、アップルのプラットフォーム上のコードとの互換性を維持しながら id と Any は、コアライブラリをネイティブな Swift の Any と標準ライブラリの値型を直接使用できます。Swift は、Linux 上の Objective-C との相互運用性はありませんので、string as NSString や value as AnyObject のような変換をブリッジするためのサポートはありません。Cocoa を横切って移植可能となら Swift コードと Swift のコアライブラリは、排他的に値型を使用する必要があります。

詳細を学ぶ

id と Any は、Swift の以前のバージョンとユーザーからのフィードバックに触発され、改善した Swift 言語の大きな例であり、オープンスな Swift の進化過程から精製されました。id とAny の背後にある動機と設計上の決定についての詳細を知りたい場合は、元の Swift の進化の提案は、Swift-evolution リポジトリでの GitHub 上で利用できます。

• SE-0072:Swift からの暗黙的なブリッジング変換を完全になくします
• SE-0116:Objective-C の id を Swift の Any 型としてインポート
• SE-0131:標準ライブラリに AnyHashable を追加します。

最終結果は、Swift が、より一貫性のある言語になり、Swift から使用されたときの Cocoa API はより強力になるということです。

2016年9月21日

Swift のプレイグラウンドでロボットをプログラムするのに iPad を使用する

WWDC 2016 で私達は Swift プレイグラウンドが、新しい iPad アプリのブランドとなる事をアナウンスし、Swift を使用して core コーディング概念を教えることを明らかにしました。Apple がアプリで提供する偉大なコンテンツに加えて、我々は Swift の開発者のコミュニティがビルドし、共有するかを見られることに興奮しています。我々は、複数のページ、常に実行しているライブビュー、とゴージャスなカットシーンで、iPad 用に独自の`.playgroundbook` ファイルを作成する方法を示す、Swift のプレイグラウンドの紹介 と題した WWDC での綿密なセッションを提示しました。

この WWDC のセッション中に、我々はまた、iPad で Swift のプレイグラウンドで駆動するステージ上の Sphero SPRK+ロボットを制御するのも実証しました。Swift プレイグラウンドのコードは CoreBluetooth フレームワークを含む iOS の SDK へのアクセス権を持っているため、完全にこれらのロボットのようなデバイスを制御することができるプログラムを書くことができます。それがどのように動作するか確認し、さらにあなたのロボットに新しいトリックを教えるために拡張することができルように、我々が WWDC で実証したプレイグラウンドを更新しました。プレイグラウンドは、この記事に含まれており、iCloud、AirDrop、電子メール、および多くの他の方法を使用して、iPad が Swift のプレイグラウンドを共有することができます。

あなたがプレイグラウンドの最初のページのコードを実行すると、部屋の周りの Sphero ロボットを手動で駆動するためのタッチインタフェースが表示されます。注意してください、それは本当に速いんです！プレイグラウンドの上部の次のページのグリフ(Next Page glyph) をタップすると、追加のページに移動します。ここでは、簡単にでロボットを正方形、８の字、または夢見れる他の形で動かす短いプログラムを描くのが簡単にできる、ロボットを制御するためのコードを使用できます簡単な API へのアクセスができます。

このプレイグラウンドを実行するには、64 ビットのチップで、iOS 10 を実行している Swift プレイグラウンドが必要になります。また、BB-8、または新しい SPRK+ のような BluetoothLE の可能な Sphero ロボットが必要になります。ロボットが近くにある限り、プレイグラウンドはそれを見つけ、あなたの iPad で Swifrt プレイグラウンドを使用してコントロールできます。

あなたは、App Store から Swift プレイグラウンド をダウンロードすることができます。

Sphero.playgroundbook

2016年9月12日

Swift 内での JSON の扱い

あなたのアプリが、Web アプリケーションと通信する場合は、サーバから返された情報は、多くの場合、JSON としてフォーマットされています。Dictionary, Array, String, Number, 及び Bool などの Swift データ型に JSON を変換するために、Foundation フレームワークの JSONSerialization クラスを使用できます。しかし、あなたのアプリが受信した JSON の構造または値を確認はできませんので、モデルオブジェクトが正しくデシリアライズするために挑戦できます。この投稿は、アプリ内で JSON を扱うときに取ることができるいくつかのアプローチについて説明します。

JSONから値の抽出

JSONSerialization のクラスメソッド jsonObject(with:options:) は、Any 型の値を返し、データが解析できなかった場合はエラーを throw します。

import Foundation

let data: Data // received from a network request, for example
let json = try? JSONSerialization.jsonObject(with: data, options: [])

有効な JSON は、単一の値のみを含むことができます が、Web アプリケーションからの応答は、通常、トップレベルのオブジェクトとしてオブジェクトまたは配列をコードします。optional の結合として使用でき、定数として既知の型の値を抽出するため if または guard 文で as? 型キャスト演算子を使用できます。JSON オブジェクト型から Dictionary 値を取得するには、条件付きで [String: Any] としてそれをキャストします。JSON の配列型からの Array の値を取得するには、条件付きで [Any] (または [String] のように、より具体的な要素型を持つ配列) として、それをキャストします。列挙型と一致するサブスクリプトアクセサまたはパターンとの型キャスト optional 結合を使用してインデックスによって、キーや配列の値によって dictionary の値を抽出できます。

// Example JSON with object root:
/*
	{
		"someKey": 42.0,
		"anotherKey": {
			"someNestedKey": true
		}
	}
*/
if let dictionary = jsonWithObjectRoot as? [String: Any] {
	if let number = dictionary["someKey"] as? Double {
		// access individual value in dictionary
	}

	for (key, value) in dictionary {
		// access all key / value pairs in dictionary
	}

	if let nestedDictionary = dictionary["anotherKey"] as? [String: Any] {
		// access nested dictionary values by key
	}
}

// Example JSON with array root:
/*
	[
		"hello", 3, true
	]
*/
if let array = jsonWithArrayRoot as? [Any] {
	if let firstObject = array.first {
		// access individual object in array
	}

	for object in array {
		// access all objects in array
	}

	for case let string as String in array {
		// access only string values in array
	}
}

Swift の組み込みの言語機能は、安全に抽出し、Foundation API で JSON データの複合を外部ライブラリやフレームワークを必要とせずに、作業をする事が容易になります。

JSON から抽出された値からモデルオブジェクトの作成

Swift アプリは モデル・ビュー・コントローラー デザインパターンに最も従うので、モデル定義内であなたのアプリのドメインに特異的なオブジェクトに JSON データを変換することは役に立つことが多いです。

たとえば、地元のレストランの検索結果を提供するアプリを書くときに、JSON オブジェクトとサーバーの /search 終点への HTTP 要求を行う型メソッドを受け取る、イニシャライザーを持つ Restaurant のモデルを実装する場合があり、その後、非同期的に Restaurant オブジェクトの配列を返します。

以下の Restaurant のモデルを考えてみましょう。

import Foundation

struct Restaurant {
	enum Meal: String {
		case breakfast, lunch, dinner
	}

	let name: String
	let location: (latitude: Double, longitude: Double)
	let meals: Set<Meal>
}

Restaurant は、String 型の name を持ち、位置座標ペアで表されるlocation、および入れ子になった Meal 列挙体の値を含む meals の Set として表されます。

ここでは、単一のレストランが、サーバの反応でどのように表されるかの例は以下のとおりです。

{
	"name": "Caffè Macs",
	"coordinates": {
		"lat": 37.330576,
		"lng": -122.029739
	},
	"meals": ["breakfast", "lunch", "dinner"]
}

optional の JSON イニシャライザを書く

Restaurant オブジェクトに JSON 表現から変換するには、プロパティに JSON 表現からデータを抽出しまた変換する Any 引数をとるイニシャライザーを記述します。

extension Restaurant {
	init?(json: [String: Any]) {
		guard let name = json["name"] as? String,
			let coordinatesJSON = json["coordinates"] as? [String: Double],
			let latitude = coordinatesJSON["lat"],
			let longitude = coordinatesJSON["lng"],
			let mealsJSON = json["meals"] as? [String]
		else {
			return nil
		}

		var meals: Set<Meal> = []
		for string in mealsJSON {
			guard let meal = Meal(rawValue: string) else {
				return nil
			}

			meals.insert(meal)
		}

		self.name = name
		self.coordinates = (latitude, longitude)
		self.meals = meals
	}
}

あなたのアプリが、モデルオブジェクトの単一の、一貫性のある表現を返さない一つ以上の Web サービスと通信する場合、可能性のある表現のそれぞれを処理するために、いくつかのイニシャライザーの実装を検討して下さい。

上記の例では、それぞれの値は、optional 結合を使用して as? 型キャスト演算子を使用して渡された JSON dictionary から定数に抽出しています。name プロパティの場合、抽出された name の値は、単純にそのまま代入されます。coordinate プロパティの場合、抽出された latitude と longitude の値は、代入前のタプルに結合されます。meals プロパティの場合、抽出された文字列値は、Meal 列挙値の Set を構築するために反復処理されます。

エラー処理で JSON のイニシャライザーを書く

前の例では、シリアル化復元が失敗した時 nil を返す optional のイニシャライザーを実装しています。その代わり、Error プロトコルに準拠した型を定義でき、シリアル化復元が失敗時はいつでも、その型のエラーを throw するイニシャライザを実装できます。

enum SerializationError: Error {
	case missing(String)
	case invalid(String, Any)
}

extension Restaurant {
	init(json: [String: Any]) throws {
		// Extract name
		guard let name = json["name"] as? String else {
			throw SerializationError.missing("name")
		}

		// Extract and validate coordinates
		guard let coordinatesJSON = json["coordinates"] as? [String: Double],
			let latitude = coordinatesJSON["lat"],
			let longitude = coordinatesJSON["lng"]
		else {
			throw SerializationError.missing("coordinates")
		}

		let coordinates = (latitude, longitude)
		guard case (-90...90, -180...180) = coordinates else {
			throw SerializationError.invalid("coordinates", coordinates)
		}

		// Extract and validate meals
		guard let mealsJSON = json["meals"] as? [String] else {
			throw SerializationError.missing("meals")
		}

		var meals: Set<Meal> = []
		for string in mealsJSON {
			guard let meal = Meal(rawValue: string) else {
				throw SerializationError.invalid("meals", string)
			}

			meals.insert(meal)
		}

		// Initialize properties
		self.name = name
		self.coordinates = coordinates
		self.meals = meals
	}
}

ここでは、Restaurant の型は入れ子になった SerializationError 型を宣言していますが、欠落しているか、または無効のプロパティの関連する値で列挙型の case を定義しています。むしろ nil を返すことで失敗したことを示すよりも JSON イニシャライザーの throw するバージョンでは、エラーが特定の障害を通信するために throw されます。また、このバージョンは、JSON で指定された meals のそれぞれの名前が meals 列挙型の case に対応する有効な地理座標ペアを表す、その coordinates を確実にするために、入力データの検証も実行します。

フェッチした結果の型メソッドを書く

Web アプリケーションは、多くの場合、単一の JSON の反応で複数のリソースを返すのが目的です。たとえば、/search の目的は、要求された照会パラメータに一致し、他のメタデータと一緒にそれらの表現を含むゼロ個以上のレストランを返すことにあります。

{
	"query": "sandwich",
	"results_count": 12,
	"page": 1,
	"results": [
		{
			"name": "Caffè Macs",
			"coordinates": {
				"lat": 37.330576,
				"lng": -122.029739
			},
			"meals": ["breakfast", "lunch", "dinner"]
		},
		...
	]
}

対応する要求オブジェクトに query メソッドのパラメータを変換し、Web サービスへの HTTP 要求を送信する Restaurant 構造体の型メソッドを作成できます。このコードはまた、応答を処理する責任があり、JSON データをシリアル解除し、"results" 配列で抽出された dictionary のそれぞれから Restaurant オブジェクトを作成し、非同期的に完了ハンドラでそれらを返すための責任があります。

extension Restaurant {
	private let urlComponents: URLComponents // base URL components of the web service
	private let session: URLSession // shared session for interacting with the web service

	static func restaurants(matching query: String, completion: ([Restaurant]) -> Void) {
		var searchURLComponents = urlComponents
		searchURLComponents.path = "/search"
		searchURLComponents.queryItems = [URLQueryItem(name: "q", value: query)]
		let searchURL = searchURLComponents.url!

		session.dataTask(url: searchURL, completion: { (_, _, data, _)
			var restaurants: [Restaurant] = []

			if let data = data,
				let json = try? JSONSerialization.jsonObject(with: data, options: []) as? [String: Any] {
				for case let result in json["results"] {
					if let restaurant = Restaurant(json: result) {
						restaurants.append(restaurant)
					}
				}
			}

			completion(restaurants)
		}).resume()
	}
}

ユーザーが一致するレストランでテーブルビューを埋めるために検索バーにテキストを入力したときに、ビューコントローラは、このメソッドを呼び出すことができます。

import UIKit

extension ViewController: UISearchResultsUpdating {
	func updateSearchResultsForSearchController(_ searchController: UISearchController) {
		if let query = searchController.searchBar.text, !query.isEmpty {
			Restaurant.restaurants(matching: query) { restaurants in
				self.restaurants = restaurants
				self.tableView.reloadData()
			}
		}
	}
}

このように、懸念を分離すると、Webサービスの変更に関する詳細を実装する時も、ビューコントローラからレストランのリソースにアクセスするための一貫したインタフェースを提供します。

反響に反映

異なるシステム間で通信するために、同じデータの表現間の変換は、ソフトウェアを書くために、必要にもかかわらず、面倒な作業です。

これらの表現の構造は非常に似ているので、これらの異なる表現の間で自動的にマッピングするための高レベルの抽象化を作成するのは魅力的です。たとえば、入力(type) は Mirror などの Swift の反映 API を使用して、JSON からモデルを自動的に初期化するために snake_case の JSON のキーと camelCase のプロパティ名との間のマッピングを定義できます。

しかし、私たちは、これらの種類の抽象化は、Swift 言語機能の従来の使用法に対して大きな利点を提供せず、代わりに問題をデバッグし、境界例を処理するのをより困難にする傾向があることがわかりました。上記の例では、イニシャライザは JSON から値を抽出およびマッピングするだけでなく、複雑なデータ型を初期化し、ドメイン固有の入力検証を行います。反映をベースにしたアプローチは、これらすべてのタスクを達成するために非常に長い道のりを行かなければならないでしょう。独自のアプリで利用可能な戦略を評価する際には、このことを覚えておいてください。複製の少量のコストは、正しくない抽象化を選ぶよりも著しく小さいでしょう。

2016年6月20日

Swift 3 と Xcode 8

Swift 3 ベータ版はちょうど Xcode 8 ベータ版の一部としてリリースされ、数多くの機能強化、オープンソースコミュニティによる多くの寄与が含まれます。Swift 3 の第一の目標は、将来のリリースのためにはるかに安定な構文に結果する、Swift が全体で一貫性のある言語として合体できるようにするための最後の主要なソースの必要な変化を実装することです。

Swift 3 における Swift の構文と API の名前の変更は、この言語をより自然に感じ、また Cocoa フレームワークを呼び出すときに、Swift の経験をさらに多く提供します。人気のフレームワークの Core Graphics と グランドセントラルディスパッチは Swift 内に新しい、さらにクリーンなインターフェイスを持っています。また、このリリースでは、ビルドのパフォーマンスを改善し、それをより楽しく、毎日使えるようになるよう多くの小さな修正を含んでいます。

Xcode 8 ベータ版 では、Swift 3 に、既存のコードの移動を助けるために Swift のファイルやプレイグラウンドのの移行ツールを含んでいます。

Swift 2.3

Swift 3 に加えて、Xcode 8 は Swift 2.3、MacOS Sierra、iOS 10、tvOS 10、および watchOS 3 用の新しいSDKをで動作するようにビルドされた Swift 2.2 言語へのマイナーアップデートでの開発をサポートしています。これは、開発者をこれらの最新の SDK に移動できるようにに意図されており、まだ Swift 3 に移行できず、Swift 2.2 で開発が遅れているプロジェクトのためでもあります。Xcode 8 は、主に最新の SDK に追加された NULL 値を許容するかどうかの明確さに関連して、新しい Swift 2.3 の変更に、コードを移行できます。例えば：

新しい SDK の NULL 値を許容するかどうかの定義なしの Swift 2.2 Core Image コード：

let image = CIImage(MTLTexture: texture, options: options)

Swift 2.3 コードは失敗可能イニシャライザがより明確にします：

if let image = CIImage(MTLTexture: texture, options: options)

または

let image = CIImage(MTLTexture: texture, options: options)!

Swift 3 は、Xcode 8 内でサポートされる主な開発言語であり、Swift 2.3 を引き続き使用することを選択した場合いくつかの注意があります。まず、Swift 2.3 および Swift 3 は、バイナリ互換性がありませんので、アプリ全体のコードベースが Swift の一つのバージョンを選択する必要があります。両方のバージョンを完全にコンパイラ、SDK、およびデバッガがサポートしていますが、IDE の他の機能は Swift 2.3 で動作しない可能性があります。例えば、Xcode でのプレイグラウンドは Swift 3 で飲み動作し、また iPad 用のプレイグラウンドも、Swift 3 を使用します。Xcode プロジェクトテンプレートはすべて Swift 3 を使用し、すべての文書も Swift 3 に適した形式で表示されます。

Xcode 8 は今年後半 GM をしたら、Swift 3.0 または 2.3 のいずれかで記述された App Store にアプリを提出できるようになります。Swift 3 の変化は Swift 言語の未来を表し、私たちはあなたが Swift のコードを 3 に移行するよう強く勧めます。しばらくの間最初 Swift 2.3 に移行する場合でも、Swift 2.0 から Swift 3 へ移行するために後で Xcode 8 移行ツールを実行することができます。

2016年2月8日

インタラクティブなプレイグラウンド

Xcode 7.3 ベータ3 は、インタラクティブな iOS と OSX のプレイグラウンドを追加し、あなたがクリック、ドラッグ、タイプできるようにし、そうでなければ、プレイグラウンドにあなたがコードしたユーザインタフェースと対話します。これらのインターフェースは、ちょうど完全なアプリケーションの中と同じように、反応します。インタラクティブなプレイグラウンドは、アプリケーションをすばやく試作し、ビルドし、単にあなたのコードと対話するための別の素晴らしい方法を提供するのに役立ちます。

XCPlaygroundPage の LiveView プロパティに割り当てられている全てのビューまたはビューコントローラは自動的にインタラクティブに作られ、それがプレイグラウンド内で実行できるので、すべての通常のプレイグラウンドの結果を得られます。ジェスチャー認識装置で実験でき、ITableView が、作成し、スクロールするとセルから待ち行列を解除するのを確認し、または SceneKit で複雑な 3D シーンと対話できます。

プレイグラウンドのサンプル

以下は、あなたのデスクトップのための完璧な、完全にインタラクティブでカスタマイズ可能な ニュートンのゆりかご を作成するために、UIKit Dynamics を使用した iOSのプレイグラウンドです。

2015年12月3日

Swift はオープンソースとなった

スウィフトは今や、オープンソースとなりました。今日 Apple はオープンソース Swift コミュニティを立ち上げ、驚くような新しいツールやリソースなどを開始し、それは以下のものを含んでいます：

• Swift.org - オープンソース・Swift コミュニティの専用サイト
• github.com/apple での公開ソースコードリポジトリ
• 簡単に共有でき、コードビルドのための新しい Swift パッケージマネージャプロジェクト
• 標準ライブラリ上の高いレベルの機能を持つ Swift のネイティブ・コア・ライブラリプロジェクト
• すべての Appleプラットフォームのプラットフォーム・サポートだけでなく、Linux も。

今や誰もがコードや開発中のビルドをダウンロードして、チームが向かっているのが何か確認できます。プロジェクトへの貢献に興味を持っている、より高度な開発者は、独自の修正と機能拡張をし、より良い Swift を作り上げ、コミュニティに参加します。App Store の開発が常に使う製品は、Xcode に含まれる Swift の安定版リリースを使い、これはアプリの提出要件のままです。

Swift.org

Swift.org は、オープンソース Swift の専用の全く新しいサイトです。このサイトでは、Swift の進化に役立ちたい開発者のコミュニティのためのリソースをホストし、修正を貢献し、そして最も重要なのは、互いに相互作用します。Swift.org はホストします：

• バグ報告と追跡システム
• メーリングリスト
• Swift のエンジニアリング専用のブログ
• コミュニティのガイドライン
• チュートリアルを開始します
• 役に立つ指示
• Swiftのドキュメント
• 開発者および API の設計ガイドライン

Swift.org は、毎日エンジニアリング作業が行われる場所の開発者のコミュニティであり、新しいプラットフォームに Swift がもたらす新機能を追加して共に作業し続け、継続的に私たちのお気に入りの言語を進化させるためにあります。

ソースコード

Apple では、Swift プロジェクトのすべてのソースコードを見つけることができる github.com/apple にある GitHub の上に新しいホームがあります。パブリックなリポジトリは Swift コンパイラ、LLDB デバッガと REPL、標準およびコアライブラリ、パッケージマネージャ、およびその他のサポートのプロジェクトを含みます。

GitHub は、すでに協力する開発者のための非常に人気のある場所です。すぐウェブサイト上でソースコードを表示できるし、すぐにコードをあなたのマシン上でチェックすることは簡単です。貢献するためのパッチがある時、私たちは、プルリクエストを受け付けます。

Swift パッケージマネージャ

今日、我々はまた、全く新しいプロジェクトを立ち上げました：Swift パッケージマネージャです。この初期段階のプロジェクトは、最初からオープンに開発されています。リポジトリは、非常に初期の状態であり、一緒に我々は、偉大なパッケージマネージャが何をすべきかを定義し、我々がどう直感的に使用できるようにするか、そして、Swift が成功し、多くのプラットフォームに渡って、拡張できる力を与えます。

コアライブラリ

Apple は長い間、一般的にソフトウェアの様々な全体で必要とされる、より高いレベルの機能を提供するフレームワークの豊富なコレクションを提供してきました。Foundation のようなフレームワーク、libdispatch、および XCTest などは、はるかに簡単に、複雑なプログラムを書くことを容易にし、そして我々は、それらが新しいプラットフォームへの Swift のスキルを必要として、開発者がそれらの同じ利点を得ることを確認頂きたかったです。iPhone や Mac 用のアプリを書くにしても、または Linux 上の新しい cloud サービスを構築する西ても、Swift コアライブラリは、あなたが頼れるビルディングブロックを提供します。

プラットフォーム

オープンソース Swift は、Mac 上で動作し、OS X、iOS、watchOS、および tvOS のためのアプリをビルドすることが可能です。Swift.org は、パッケージマネージャのサポート、LLDB デバッガ、および REPL を含む、Linux のツールセットを完備した、Swift の Linux 版も提供しています。私たちは、仲間たちがさらにより新しい場所に Swift を持って行くのを見て興奮しています。学生や専門家が、Swift でプログラムすることを学ぶように、それぞれの新しいプラットフォームと用途は、テクノロジー業界全体の彼らのための新しい機会を開きます。

始める

始めるのは簡単です。Swift.org は、Apple と Linux プラットフォーム用のコンパイラとコマンドラインツールのバイナリダウンロードをホストしており、あなたは起動してすぐに実行できるようにしています。Xcode の最新バージョンは、Xcode の中から最新のオープンソースの、Swift のビルドを具体的に試す事ができるように設計されており、代替ツールチェインオプションをサポートしています。そして Swift.org は、オープンソースの Swift で動作するように環境を設定するための手順のガイドを始める偉大な一歩を歩き出しました。

2015年10月7日

プレイグラウンドのリテラル

Xcode 7.1 の新しい点は、プレイグラウンドのコード内に、ファイル、画像、およびカラーリテラルを埋め込む機能です。リテラルは、直接 Xcode のエディタ内で、そのネイティブ形式で表される、データの実際の値です。ちょうど、Finder からイメージをドラッグして、実際のイメージがインラインでコードに表示されるように - 例えば、エディタで"myImage.jpg" を入力する必要がないように。色を示すために、RGB 値を示す代わりに、プレイグラウンドは、色見本をレンダリングします。プレイグラウンドのリテラルは、通常の Swift コードのコードのようにば手作者でコードされ、動作しますが、はるかに便利な方法でレンダリングされます。

格好いいのに加えて、リテラルははるかに高速にリソースを編集することもできます。すぐにパレットから別の色を選択するカラーピッカーを使用できます。あなたのプレイグラウンドコードに Finder からファイルをドラッグ＆ドロップフして、すぐに使用を開始できます。[エディタ(Editor)] > [挿入(Insert)] を選択して、ファイルや画像、またはカラーリテラルを、現在のカーソル位置にリテラルを追加できます。リテラルをダブルクリックすると、簡単に別の値を選択できます。

必要に応じて、プレイグラウンドのリソースのディレクトリにリソースがコピーされるので、あなたのプレイグラウンドに必要なすべてのものは、ドキュメント内に含まれています。リテラルは、コードの一部であるため、あなたはまた、任意のソースコードとまったく同じように、コピー、ペースト、移動、そして削除することができます。

Swift コードのリテラル

プラットフォーム固有の型にリテラルを変換すると、デフォルトは、以下のように記載した通りです：

リテラルの完全なインライン・プレゼンテーションの体験を取得するのは、プレイグラウンド内でなければなりません。ただし、コピーして主な Swift ソースコードにリテラルを使用したコードをペースとすると、ペーストされたコードは期待通り動作し、Xcode は、プレーンテキストとしてリテラルを単にレンダリングします。

リテラルを始めるために、我々は、このブログの記事での非常に短いプレイグラウンドを用意しました。このプレイグラウンド を試してみるために、最新の Xcode 7.1 ベータ版 をダウンロードしてください。

追加のドキュメント

ドキュメントを伴う Xcode 7.1 ベータ 3 は、リテラルに新しいコンテンツを含むプレイグラウンドの多くの強力な機能の新しい情報で更新された プレイグラウンドのヘルプドキュメント を含んでいます。ここでは、関連するサブページへの直接リンクを挙げます：イメージのリテラルの追加、カラーリテラルの追加、および ファイルのリテラルの追加 です。

以下は、リテラルが Xcode 7.1 内にどのように表示されるかを示すスクリーンショットです：

2015年9月21日

Swift ２アプリが App Store に

Swift ２は、世界の準備ができています。これで、guard、新しいエラー処理モデル、および利用性の制御を含む、コードをより読みやすく強力にする Swift ２で最新の機能を活用できるアプリを提出することができます。

OS X El Capitan の GM 種子と iOS 9 と watchOS2 の最終バージョンと Xcode 7 でテストをしてアプリをビルドすることを確認して下さい。

Xcode 7 と OS X El Capitan

OS X El Capitan は Swift 2 を含んでいるが、システムの整合性保護 (SIP)、アプリ軽量化、ネイティブサポートだけでなく、最新の SDK を含んでおり、Xcode 7 が必要です。Xcode 7 を実行すると、構文の変更が Swift 1.2 コードに適用される必要があるのは数多くある事に気づくでしょう。Swift ２への移行を支援するために、Xcode 7 は、あなたのために、古い Swift コードを再度書くための便利なツールを含んでいます。最新の Swift API と構文にあなたのコードを移行するには、[編集(Edit)] > [転換(Convert)] > [最新の Swift 構文に(To Latest Swift Syntax)] とメニュー項目をただ選択して下さい。

あなたのコードが、開発の後期段階にあり、しばらくの間、Xcode 6 内にいなければならない場合、あなたの開発 OS として OS X ヨセミテを使用するのを継続する必要があります。OS X El Capitan と Xcode 6 の組み合わせは、基礎となるアーキテクチャの大幅な変更のため、App Store への提出のためにはサポートされていません。あなたが別のパーティションまたは外付けハードドライブに OS X ヨセミテをインストールする必要がある場合、あなたは、App Store から OS X ヨセミテをダウンロードしてインストールする これらの手順に従う ことができます。また、Xcode 7 は OS X El Capitan とヨセミテの両方でサポートされていることに注意してください。

2015年8月12日

Swift-er SDK

Xcode 6.3 では、Objective-C のための新しい NULL可能注釈 (nullability annotation) 言語機能を追加しました。この機能は、Objective-C に Optionals が Swift に提供するヌルと非ヌルの API の契約と同じ種類を表現する方法を与えました。Xcode 7 は、Objective-C のための軽量で汎用的 (generics) モデルを導入することにより、Objective-C と Swift との間の通信をより自然に行い続けています。汎用モデルは２つの言語を安全に理解し、要素の特定の種類を含むコレクションを共有する事を可能にします。

これらの機能は、Swift と Objective-C のコードの両方を含んでいるアプリを書いている誰にでも有用です。しかし、アプリの開発者が毎日使用する Objective-C のコードのはるかに大きなコレクションがあります:アップルの SDK を構成するフレームワーク。Swift や Objective-C と作業する経験をよりよくするために、我々の SDK のヘッダーにこの情報を提供するために、全社的な取り組みを行いました。Xcode 7 では、ほぼすべての共通フレームワークは、今ではそれらの API とそれらのコレクション型の要素の null 可能性 (nullability) を指定したことをほぼ見つけるでしょう。これは、以下の物から Swift のインタフェースを持ち上げます。

class UIView : UIResponder {
	init!(frame: CGRect)

	var superview: UIView! { get }
	var subviews: [AnyObject]! { get }
	var window: UIWindow! { get }

	// ...

	func isDescendantOfView(view: UIView!) -> Bool
	func viewWithTag(tag: Int) -> UIView!

	// ...

	var constraints: [AnyObject]! { get }

	// ...
}

以下の物へと変えます：

class UIView : UIResponder {
	init(frame: CGRect)

	var superview: UIView? { get }
	var subviews: [UIView] { get }
	var window: UIWindow? { get }

	// ...

	func isDescendantOfView(view: UIView) -> Bool
	func viewWithTag(tag: Int) -> UIView?

	// ...

	var constraints: [NSLayoutConstraint] { get }

	// ...
}

パズルの最後のピースは、あなたのコードを Swift 2 へと変換する Xcode 7 のツールです。このツールは Xcode の[編集(Edit)]メニューの下に棲んでおり、[変換(Convert)] > [最新の Swift 構文に]のところです。このツールは、Swift 1.2 を使用していて、必要な編集を適用したプロジェクトを、有効な Swift ２のコードに変換します。これらの変更は、改善されたヘッダ情報も属しています。例えば、そのパラメータと結果の型がより正確なメソッドをオーバーライドしている場合、移行ツールは一致するようにメソッドを更新します。

Objective-C への改善は、WWDC で詳述された Swift と Objective-C の相互運用性 は、14時30分に始まりました。_Nullable を使用する Xcode 7 の更新された構文とは対照的に、このビデオは Xcode 6.3 で __nullable を使った構文を使用していることに注意してください。NULL 可能注釈の詳細については、ブログ投稿の NULL 可能性と Objective-C を参照してください。Swift ２と Objective-C の軽量汎用性の詳細については、Xcode 7 リリースノート を参照してください。

2015年7月23日

Swift 2 での String

Swifty は、その標準ライブラリの一部として、高性能な、ユニコード対応の文字列の実装を提供します。Swift 2 では、String 型は、もはや CollectionType プロトコルに準拠せず、そこでは String は、配列の様に、以前 Character 値の集合でした。今や、String は、文字の集合ビューを公開する Character プロパティを提供します。

なぜ変更したか？それは文字の集まりとして文字列をモデル化するのは、自然に見えるかもしれませんが、String 型は、Array、Set、または Dictionary のような集合型とは全く異なる動作をします。これは常に真ですが、Swift 2 にプロトコル拡張を加えて、これらの違いは、それがいくつかの基本的な変更を加えるのが必要なことにしました。

その部分の合計よりも異なる

集合に要素を追加するときは、集合は、その要素を含んでいることを期待されます。つまり、配列に値を追加する際に、配列はその値が含むようになります。同じことは、dictionary や set に適用されます。しかし、文字列に組み合わせたマーク文字を追加した時には、文字列自体の内容が変更されます。

文字列の cafe を、考えてみましょう:これは４つの文字 c、a、f および e から成ります：

合成アキュートアクセント文字 U+0301 ´ を追加すると、文字列はまだ 4 文字のままですが、最後の文字が é になります。

文字列の character のプロパティは、元の小文字の e を含んでいません。また、ちょうど追加された合成アキュートアクセント ´ を含みません。代わりに、文字列は今や、アキュートアクセントを伴う小文字の "e" の é を含んでいます。

他の集合のような文字列を処理する場合は、この結果は、それが UIColor.redColor() と UIColor.greenColor() をセットに追加すると UIColor.yellowColor() を含むセットになると報告するのと同じくらい驚くべきことであろう。

その文字の内容によって判断

文字列と集合のもう一つの違いは、それらが同一性を決定する方法です。

• 両方が同じ数を持っていて、インデックスに対応した各要素のペアが等しい場合にのみ２つの配列は等しいです。
• 両方が同じ数を持っていて、第一のセットに含まれる各要素が、第２に含まれている場合にのみ２つのセットは等しいです。
• 2つの辞書は、それらが同じセットのキーと値のペアを持っている場合にのみ等しいです。

しかし、String は 正準等価性 に基づいて等価性を決定します。それらが舞台裏異で異なる Unicode スカラから構成された場合でも、同じ言語的意味と外観を持っている場合は、文字は正準等価です。

個々の子音と母音を表す 24 文字、または 字母 で構成された韓国文字システムを、考えてみましょう。書き出された場合、これらの文字は、各音節の文字に結合されます。例えば、文字 "가" ([ga]）は文字 "ᄀ" ([g]) と "ᅡ" [a] で成り立っています。Swift では、それらが分解や合成済み文字の並びから構成されているかどうかに関係なく、等しいと見なされます：

繰り返しますが、この動作は Swift の集合型のいずれとも大きく異なります。これは、配列として 値 🐟 と 🍚 が 🍣 に等しいと見なされると同じくらい驚きでしょう。

あなたの視点に依存します

文字列は集合ではありません。しかし、それらは CollectionType に準拠する View を提供します。

分解した文字 [c,a,f,e] および ['] で構成される単語 "café"、の前に挙げた例を取ると、ここでは様々な文字列ビューが以下の文字で構成されています：

• characters プロパティは、テキストを 拡張書記素クラスタ に分割し、これらはユーザ知覚文​​字 (この場合 c,a,f および e) の近似値です。文字列は、リニア O (n) 時間で実行された、このプロパティにアクセスし、文字の境界を決定するために、(各位置は、コードポイントと呼ばれます)、全体の文字列内のそれぞれの位置を反復する必要があるためです。人間が読めるテキストを含む文字列を処理する場合、そのような localizedStandardCompare(_ :) メソッドと localizedLowercaseString プロパティで使用されるような高レベルのロケールに依存する Unicode のアルゴリズムは、文字単位の処理に好まれます。


• unicodeScalars プロパティは、文字列に格納されている基礎となるスカラー値を公開します。元の文字列が分解した e と ´ の代わりに合成済み文字 é で作成された場合、これは、Unicode スカラービューによって反映されます。文字データの低レベルの操作を実行している場合は、この API を使用してください。
• utf8 と utf16 のプロパティは、それぞれ、UTF-8 と UTF-16 表現のためのコード·ポイントを提供します。これらの値は、特定のエンコードに書き込んだり読み込んだりして翻訳ファイルに書き込まれる実際のバイト数に対応しています。UTF-16 コード単位は、文字列の長さ及びオフセットを表すために Cocoa と Cocoa Touch を通じて使用されているのに対し、UTF-8 コード·ユニットは、多くの POSIX 文字列処理 API で使用されています。

Swift で文字列と文字の使用方法の詳細については、Swift プログラミング言語 と Swift 標準ライブラリリファレンス を参照してください。

2015年7月8日

Swift 2.0

本日 WWDC で、我々は Swift 2.0 を発表しました。この新しいバージョンでは、さらに優れたパフォーマンス、新しいエラー処理 API、および可用性のチェックのためのファーストクラスのサポートをします。そして、プラットフォーム API で、Apple の SDK の強化で Swift にさらなる自然な感じをもたらします。

オープンソース

新機能に加え、大きなニュースは、Apple が今年後半 Swift をオープンソースにしようとしているということです。我々すべては、このことについて非常に興奮しており、オープンソースのリリースが近づくにつれて、あなたに、より多くの情報を与えることを楽しみにしています。ここでは、これまでにあなたに伝えることができるものです。

Swift が、我々の業界のためにオープンソースに作成されたこの機会に興奮しています。焼き込まれた、優れたスピードと組み合わされた安全機能、それは劇的に C ベースの言語を使用するのに対して、ソフトウェアを改善する機会になる事を意味します。Swift は、書くことが楽しく、現代的な機能が満載され、我々は、それが多くの場所で使われると信じています。我々と先にエキサイティングな道を一緒に行きましょう。

新機能

Swift 2.0 は、また新しい言語機能や改良をたくさん含んでいます。ブログの記事を見ていると、より深く特徴を見れられるし、WWDC のセッションを見るとその週にあるこれらのトピックをカバーするようにしてください。新機能のいくつかは：

エラー処理モデル

Swift 2.0 の新しいエラー処理モデルは、おなじみの try , throw そして catch キーワードで、すぐに自然な感じを受けます。本当に良いことに、それは Apple の SDK および NSError で完全に動作するように設計されました。実際には、NSError は Swift の ErrorType に準拠しています。間違いなくそれについての詳細を聞くために WWDC のセッションの What's New in Swift を見たいと思うでしょう。

利便性

最新の SDK を使用すると、新しい機能とプラットフォームの変更についての情報へのアクセスを得られる事を保証します。しかし、時にはまだ古い OS をターゲットにする必要があり、そうするのは Swift はとても簡単かつ安全です。Swift のコンパイラは、あなたのターゲット OS のためには新しすぎる API を使用した場合、今やエラーを表示し、#available ブロックは安全に正しい OS のバージョンでのみ実行するコードの行を折り返します。

プロトコル拡張

Swift は非常にプロトコル指向の開発に焦点を当てています - WWDC 2015 でのトピックのセッションもあった事だ。Swift 2.0 はプロトコルの拡張機能を追加し、標準ライブラリ自体が広範囲にそれを使用します。グローバル関数を使用するために使用する場所では、Swift 2.0 は今や一般的な型にメソッドを追加し、関数が自然に連鎖し、コードがより一層読みやすくなります。

Swift 屋の SDK

Swift 2 は、アップルの SDK でよく動作するので、Objective-C の二つの新しい機能に感謝。つまり、null 可能性注釈と汎用。SDK は、optional を使用する頻度ができるだけ少ないように、nil を返すことができない API に注釈を付けるように更新されました。SDK によって使用される、真の汎用システムでは、より頻繁に Swift 2 コード内で詳細な型情報を保持することができます。

もっと詳しく知る

これは Swift 2 の何が新しいかのほんの味見です。iBooks ストアから Swift プログラミング言語 の最新バージョンをダウンロードして、WWDC のセッションのライブストリームを必ず見て、週を通して、ビデオで見られます。続きを読むには、http://developer.apple.com/swift を訪問して下さい。

2015年4月24日

メモリ安全性：保証値は、使用前に定義されています

Swift を設計するのは、プログラミング·モデルのメモリ安全性を向上させるのが主な焦点でした。メモリ安全性の側面には多くの事があるので、この記事ではゆっくりスタートし、簡単なケースをカバーします：それらが使用される前に、変数が値で初期化されていることを確認する方法です。

Swift のアプローチ

変数は、あるコードがそれにアクセスしようとする前に、使用する準備ができていて有効な値が存在することを開発者が確認することができたときに、"安全" とみなされます。言語は、この種の安全性に、アプローチをいくつかの異なる種類で取ります。ある種類は、C のように、安全なプログラミング技術を採用することがプログラマに完全に負担をかけ、一つの強力なアプローチは、リスクだらけ - です。C++ と Objective-C は、いくつかの必須パターンを強制することによって状況を改善し、他の言語は、定義の時点で初期化を要求することにより、極端な措置を講じます。

Swift によって採用された主な技術は、コードのデータフロー解析を実行するために私たちの高度なコンパイラを使用することです。コンパイラは、それが使用される前に、各変数は、決定的な初期化 として知られている戦略で初期化されることを強制します。Java や (とりわけ) C＃などの言語も、この技術を使用することが知られています。Swift は、変数の広い範囲のためこのアプローチの拡張バージョンを使用しています。

ローカル変数の決定的な初期化

Swift は、多くの状況で決定的な初期化のルールを適用しますが、最も簡単な使用法は、ローカル変数のためです。決定的な初期化は "暗黙のデフォルトの初期化" ルール (下記参照) よりも高い柔軟性を提供し、あなたはこのコードを記述できます：

var myInstance : MyClass  // Uninitialized non-nullable class reference

if x > 42 {
	myInstance = MyClass(intValue: 13)
} else {
	myInstance = MyClass(floatValue: 92.3)
}

// Okay because myInstance is initialized on all paths
myInstance.printIt()

ここでは、if 文の両側は、メソッドの呼び出しが、初期化されていないメモリを使用することはできないことを証明して、myInstance を、初期化することが保証されています。

決定的な初期化は強力なアプローチですが、それは信頼性が高く、予測可能である場合にのみ、本当に便利です。以下のように例えば、より複雑な制御フローがある場合、これは驚きにつながります。

var myInstance : MyClass

if x > 10 {
	myInstance = MyClass(intValue: 13)
}
// ...
if x > 42 {
	myInstance.printIt()
}

この場合、コンパイラはあなたに教えてくれます："変数 myInstance が初期化前に使われています" printit() への呼び出し前に。これは、コンパイラが if 条件の述部との間の相関関係を追跡しないためです。私たちはこのように、個々の具体的なケースを処理するようにコンパイラに教えることができますが、すべてのケースを処理することは不可能なので、我々は単純で予測可能なコンパイラのルールを維持することにしました (こうする事は 停止問題 と等価です)。

Swift は、非常に簡単に変数を初期化することができます。事実、初期化されていない変数 var x : Int を宣言するよりも、変数に初期値 0 を与えて var x = 0 として変数を宣言した方が、短いです。Swift は、初期化を明示する方をいつでも可能なら好みます。init() を使用した呼び出しの状況では、変数を初期化するためのより強力な方法もあります。総合的な情報のためには、スウィフトプログラミング言語の章の "初期化" を読んで下さい。

他のアプローチ

決定的な初期化に加えて、Swift は、言語の集中した範囲で追加のアプローチも採用しています。他の言語でこれらの技術を使用しているかもしれませんので、この記事では簡単にそれらをカバーしました。それぞれがいくつかの欠点を持っているので、Swift の主要なアプローチとしては使用されていません。

プログラマに安全性を託す：C の普及率を考えると、単に開発者にまで安全性を残す長所と短所を理解することが重要でした。残念ながら、C 言語で初期化されていない値の使用は、多くの場合、実行時爆発にしばしば至る、未定義の動作 を生成します。C　は、プログラマが間違いを決して犯さないように依存しています。私たちの目標は、Swift は "デフォルトで安全に" 作ることだったことを考えると、このアプローチはすぐに一般的な使用のためには廃棄しました。しかし、UnsafePointer などの API を使用すると、この力は絶対に必要である場合に、安全でない方に明示的に選択させます。

暗黙のデフォルトの初期化：値は、例えば Objective-C がインスタンス変数にするように "ゼロ値" に設定する事によって、または C++ でのように、デフォルトのイニシャライザを実行して、それらをコンパイラが暗黙的に初期化したことにより、安全なことを確保することができました。我々は、深さで、このアプローチを検討したが、最終的にはその広範な使用のため、反対を決めました。というのも：

• これは、法定の初期値を持たない場合、機能しません、例えば init() の要求がないプロトコルと、Swift で普及しているクラスへの null でない可能性の参照。


• でも、整数のようなプリミティブ型にとって 0 は、多くの場合、間違った値です。つまり、Swift で初期値を設定するのは非常に簡単だと言う一つの理由からです。これは、コードを維持するだけでなく、省略の潜在的なエラーを定義して、コードをもっとわかりやすくし、例えば -1 は使用するのに正しいセンチネル (タグ) です。

nil にデフォルトの初期化するのは明らかに Optional と ImplicitlyUnwrappedOptional 型のすべての値が自動的にデフォルトで nil に初期化する null可能性値に対する正しい答えであることに注意してください。

定義でイニシャライザが必要。 常に変数は定義時に初期値を提供するために、開発者に負担をかける、つまり var x : Int はイニシャライザなしでは違法になります。これは関数型言語の間では一般的な手法ですが、我々はそれが自然なパターンを表現する邪魔になる、非常に厳格なプログラミングスタイルを強制するので、これは重すぎる必要条件と考えられました。

2015年4月9日

動的ディスパッチを減らす事によってパフォーマンスの向上

他の多くの言語と同様に、Swift は、そのスーパークラスで宣言されたメソッドとプロパティをオーバーライドするクラスを可能にします。これは、プログラムがメソッドやプロパティが参照されている実行時に決定しなければならず、その後間接呼び出しまたは間接的にアクセスを行う必要があることを意味します。動的ディスパッチ と呼ばれるこの技術は、各々の間接使用のための実行時のオーバーヘッドの一定量のコストで、言語表現力を向上させます。パフォーマンスに敏感なコード、このようなオーバーヘッドは望ましくないことが多いです。このブログの記事は、このようなダイナミズムを排除することによってパフォーマンスを向上させる、３つの方法を紹介しています：final、private およびモジュール全体の最適化です。

次の例を考えてみます。

class ParticleModel {
	var point = ( 0.0, 0.0 )
	var velocity = 100.0

	func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

var p = ParticleModel()
for i in stride(from: 0.0, through: 360, by: 1.0) {
	p.update((i * sin(i), i), newV:i*1000)
}

書かれているように、コンパイラは、動的なディスパッチの呼び出しへの発行をします。

1. p で update を呼び出します。
2. p で updatePoint を呼び出します。
3. p のプロパティ point のタプルを取得します。
4. p のプロパティ velocity を取得します。

これは、このコードを見たときに期待されるものではないかもしれません。ParticleModel のサブクラスが point を上書きしたり、velocity を計算されたプロパティで、また updatePoint() を上書きしたり、 update() を新しい実装で上書きしたりするため、動的な呼び出しは必要です。

Swift では、動的なディスパッチの呼び出しはメソッドテーブルから関数を検索した後、間接呼び出しを実行することによって実現されています。これは、直接呼び出しを行うよりも遅くなります。また、間接的な呼び出しは、より高価な物となっていて、多くのコンパイラ最適化を防ぎます。パフォーマンスのクリティカルなコードでは、それがパフォーマンスを向上させるために必要とされないときは、この動的な動作を制限するために使用できるテクニックがあります。

宣言を上書きする必要がない場合、final を使用します

final のキーワードは、宣言が上書できないことを示す、クラス、メソッド、またはプロパティの制限です。これは、コンパイラが安全に動的ディスパッチを間接にするのを省けます。例えば、以下の point および velocity は直接アクセスされ、オブジェクトの格納されたプロパティと updatePoint から負荷を介して直接関数呼び出しによって呼び出されます。一方、update() はまだカスタマイズされた関数で update() をサブクラスが上書きすることができ、動的ディスパッチを介して呼び出されます。

class ParticleModel {
	final var point = ( x: 0.0, y: 0.0 )
	final var velocity = 100.0

	final func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

クラス自体に属性を付加することによって、final として、クラス全体をマークすることが可能です。これは、クラスのすべての関数とプロパティを、同様に final であることを意味し、クラスをサブクラス化するのを禁止します。

final class ParticleModel {
	var point = ( x: 0.0, y: 0.0 )
	var velocity = 100.0
	// ...
}

private キーワードを適用した、一ファイル内で参照された宣言の final 推論

宣言に private キーワードを適用すると、宣言の可視性を現在のファイルに制限します。これで、コンパイラが、すべての潜在的な上書き宣言を見つけられます。そのような上書き宣言がない事は、メソッドとプロパティにアクセスするための間接呼び出しを削除し、自動的に final キーワードをコンパイラが推測できるようになります。

現在のファイルで ParticleModel を上書きするクラスが存在しないと仮定すると、コンパイラは、動的なディスパッチの呼び出しを全て直接呼び出しと private 宣言での呼び出しで置き換えることができます。

class ParticleModel {
	private var point = ( x: 0.0, y: 0.0 )
	private var velocity = 100.0

	private func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

前の例と同様に、point と velocity は直接アクセスされ、updatePoint() が直接呼び出されます。繰り返しますが、update() は update() が private でないため、間接的に起動されます。

ただ、final と同じように、クラスの宣言それ自体に private の属性を適用するのは可能で、したがって、クラスのすべてのプロパティとメソッドだけでなく、クラスが private になります。

private class ParticleModel {
	var point = ( x: 0.0, y: 0.0 )
	var velocity = 100.0
	// ...
}

internal 宣言を final に推定するために、モジュール全体の最適化を使用してください

internal アクセス (何も宣言されていない場合のデフォルト) での宣言は、それらが宣言されているモジュール内でのみ見えます。Swift は、通常、個別にモジュールを構成するファイルをコンパイルするため、コンパイラは、internal の宣言が別のファイルで上書きされているかどうかを確認することができません。しかし、モジュール全体の最適化が有効になっている場合は、モジュールのすべてが同時に一緒にコンパイルされます。これは、コンパイラがモジュール全体についての推論を同時に行い、目に見える上書きがない場合は、internal で宣言された物を final に推測することができます。

元のコードスニペットに戻って、今度は ParticleModel に、いくつか public キーワードを追加しましょう。

public class ParticleModel {
	var point = ( x: 0.0, y: 0.0 )
	var velocity = 100.0

	func updatePoint(newPoint: (Double, Double), newVelocity: Double) {
		point = newPoint
		velocity = newVelocity
	}

	public func update(newP: (Double, Double), newV: Double) {
		updatePoint(newP, newVelocity: newV)
	}
}

var p = ParticleModel()
for i in stride(from: 0.0, through: times, by: 1.0) {
	p.update((i * sin(i), i), newV:i*1000)
}

モジュール全体の最適化で、このスニペットをコンパイルする場合、コンパイラは、プロパティの point、velocity、およびメソッド呼び出し updatePoint() に final を推測できます。これとは対照的に、update() は public のアクセスがあるため、 update() は final とは推測できません。

2015年3月17日

新しいプレイグラウンドパート2 - ソース

Xcode 6.3 ベータ 3 版は最近のベータ版で導入された新しいプレイグラウンド形式にさらに多く追加します。Xcode のプロジェクトナビゲータは、追加した Swift のコードを含む新しいソースフォルダーにアクセスできるだけでなく、リソースフォルダに簡単にアクセスできます。

プレイグラウンドとプロジェクトナビゲータ

プレイグラウンドは、クリックしたときはリソースおよびソースフォルダを表示する三角形をバンドルする物として Xcode 内で今は表現されています。これらのフォルダは、プレイグラウンドのメインの Swift コードから簡単にアクセスすることができる、追加コンテンツを含んでいます。これらのフォルダを表示するには、[View(表示)] > [Navigators(ナビゲーター)] > [Show Project Navigator(プロジェクトナビゲータを表示)] を選択します(または単にコマンド-1 を押してください)。

Resources(リソース) フォルダに画像やその他のコンテンツをドラッグ·アンド·ドロップするのは簡単です。(最新の Xcode 6.3 ベータ3 を使用して) 前に戻って、これらのリソースが格納され、使用されている方法の他の例を、前のブログ記事 から DemoNewFormat.playground ファイルを見てみたいでしょう。

ソースフォルダ

ソースフォルダは、6.3 ベータ 3 の新機能です。このフォルダは、メインのプレイグラウンドコードがアクセスしやすいように、追加の Swift のソースファイルを含んでいます。Sources(ソース) フォルダに、サポートする .swift ファイルを置くと、プレイグラウンドをきれいで読みやすく維持するのが簡単になります。ソースフォルダ内のコードは、このコードが 1回コンパイルされるだけなので、大きなパフォーマンス上の利点を獲得し、メインのプレイグラウンドのコードと同じく対話的に実行されません。これは、目に見えるコードは読者のため近づきやすいまま、カリキュラムとサンプルコードの作者をさらに対話的でエキサイティングなプレイグラウンドを作成できるようにします。

マンデルブローの例

ここで、複雑で美しいマンデルブロー集合を計算するプレイグラウンドの例を挙げます。このプレイグラウンドは、ソースフォルダーを使って、それが可能にする力および追加したパフォーマンスを実証します。このプレイグラウンド の内部動作を確認するには、ソースフォルダ内のコードを調べて下さい。

2015年3月12日

Null の可能性と Objective-C

Swift の素晴らしい点の一つは、透過的に Objective-C のコードと、あなたのアプリでの Objective-C とコードで記述された両方の既存のフレームワークとの相互運用が可能ということです。しかし、Swift には optional と非オプションの参照、例えば NSView と NSView? の間には強い区別がありますが、Objective-C では、NSView* として、これらの２つの型両方共表しています。Swift コンパイラは、特定の NSView* が optional であるかどうかを確認できませんので、型は NSView! の、暗黙のうちに開封された optional として、Swift にもたらされます。

以前の Xcode のリリースでは、それらの API が正しい Swift の optional に明らかになるように、いくつかの Apple のフレームワークは、特別監査を受けていました。Xcode 6.3 は、新しい Objective-C 言語機能を持つあなた独自のコードのためにこれをサポートしています：NULL の可能性のある注釈

核心部：__nullable と __nonnull

この機能の中核には、２つの新しい型の注釈がある：__nullable と __nonnull 。ご想像のとおり、__nullable ポインタは NULL または nil の値を有し、 __nonnull ポインタは有していない。ルールを破ろうとした場合、コンパイラは教えてくれます。

__nullable と __nonnull を、通常の C の const キーワードを使用できるところならほとんどどこでも使用できますし、もちろん、それらはポインタ型に適用しなければなりません。しかし、一般的な場合には、これらの注釈を書くための非常に良く方法があります：メソッド宣言の中では開き括弧の直後にアンダースコアを付けない、nullable と nonnull の形式で使用可能であり、型が単純なオブジェクトであるか、ブロックポインタである場合に限り。

そしてプロパティの場合、プロパティの属性リストに注釈を移動することで同じくアンダースコアを付けないスペルを使用できます。

アンダースコアを付けない形式は、アンダースコアを付けたものよりもよりよいですが、まだヘッダー内のすべての型に適用する必要があります。そのジョブを簡単にするために、ヘッダーをより明確にするには、監査された領域を使うことになるでしょう。

監査された領域

新しい注釈の採用を容易にするために、Objective-C のヘッダファイルの特定の領域を、null の可能性について監査された としてマークできます。これらの領域内では、全ての単純なポインタ型を nonnull であると仮定できます。これは、以前の例をはるかに簡単なものにまとめます。

安全のため、このルールにはいくつかの例外があります：

エラー処理プログラミングガイド でこれについての詳細を読むことができます。

互換性

Objective-C のフレームワークは、既存のコードは、それに対して書かれている場合はどうなります？それはちょうどこのようにあなたの型を変更しても安全ですか？はい、そうです。

一般的には、nullable と nonnull は、大きく分けて、現在のアサーションまたは例外を使用する方法であると見ることが出来ます：契約に違反するのは、プログラマのエラーです。具体的には、戻り値は、あなたがコントロールするものなので、それは下位互換性のためでない限り、あなたが null が可能でない戻り値の型に nil を返してはいけません。

Swift に戻る

今や、私たちは Objective-C ヘッダに null の可能性のある注釈を追加したので、Swift からそれを使ってみましょう：

Objective-C に注釈を付ける前は：

注釈を付けた後は：

Swift コードがより綺麗になりました。それは微妙な変化ですが、あなたのフレームワークを使う事をより快適するでしょう。

C と Objective-C のための Null 可能性のある注釈は、Xcode 6.3 から利用可能です。詳細については、Xcode 6.3 リリースノート を参照してください。

2015年2月24日

新しい Playground

Xcode 6.3 ベータ 2 は著者のための素晴らしい機能を備えた Swift の Playground に大幅な改善を含んでいます。プロジェクトに含めるドキュメント、チュートリアル、またはサンプルのための完璧な ーそれは今やリッチでインタラクティブな Playground を作成することがさらに簡単になりました。

新しい Playground は、教育者のために特に有用です。インタラクティブな Swift のコードと一緒に追加のマテリアルに段落見出し、図、リンクを持つ豊かな教育コンテンツを挿入することができます。

Xcode 6.3 の新機能の、Playground には以下のものがあります。

リソースフォルダ は直接 Playground 内の画像やその他のコンテンツをバンドルします。これらのリソースは、Swift コードから、または Playground 内の豊富なコメントからアクセスできます。(注：Xcode 6.3 ベータ 2 で Finder 「パッケージの内容を表示する」を使用すると、Playground のリソースフォルダにファイルをドラッグします。)

最新の Xcode 6.3 ベータ版 は、新しい Playground のオーサリング機能を含みます。これらの機能はまだ進化しているので、リリースノート を読んで、私たちに あなたが発見した全てのバグを教えてください。ここで、開始できるように、デモの Playground です。

注： ここのリンクをクリックするとデモの Playground がダウンロードできるようになっています。ただし、再配布禁止だろうから、ダウンロード出来ないようにしておきました。

---

2015年2月18日

as! 演算子

Swift 1.2 以前では、as 演算子が、変換する式の型とそれが変換される型に応じて、変換する２つの異なる種類を実行するために使用できます。

Swift 1.2 は、２つの別個の演算子への保証された変換と強制された変換の概念を分離します。保証された変換は、まだ as 演算子として行われるが、強制された変換は、as! 演算子を使うようになります。! は、変換が失敗する可能性があることを示します。この方法では、変換により、プログラムがクラッシュする可能性があり、一目でわかります。

以下の例は変更を説明しています。

接尾辞演算子の ! と ? 、及び as! と as? の変換演算子の類似性に注意して下さい。

Swift におけるこれらの演算子のためのパターンを覚えておく最も簡単な場合があり、! なら、「これはトラップするだろう」 を意味し、? なら「これはnilかもしれません」 と示します。

2015年2月9日

Swift 1.2 と Xcode 6.3 beta

今日 Swift 1.2 は Xcode 6.3 ベータ版の一部としてリリースされました。このベータリリースには、Swift 言語そのもので大幅に強化された Swift コンパイラと同様に、新機能が含まれています。変更の完全なリストについては、リリースノート をお読みください。このブログの記事は、ハイライトに焦点を当てます。

コンパイラの改善

Swift 1. 2コンパイラは、より安定しており、かつあらゆる面でパフォーマンスを向上させるように設計されました。Xcode で Swift で作業する場合、これらの変更は、より良い体験を提供するでしょう。最も目に見える改善の一部を以下に示します。

新しい言語の機能

Swift 1.2 では、言語はさらに安全で、予測可能な動作を保証するため洗練されています。また、Swift と Objective-C の間の相互作用を改善し続けます。より注目すべき変更内容の一部を以下に示します。

Objective-C には以下のようにインポートします：

これは以下の様なパターンを可能にします：

変異が起こらないにもかかわらず、これは以前は、var の使用を必要としました。プロパティは、イニシャライザと同様にその意味を簡単にするために、このモデルに折り畳まれています。

結論

私たちは、あなたが提出したバグのすべてを感謝し、最も一般的な問題の多くは、このベータ版で修正されていることを期待しています。Swift 1.2 は、言語やツール両方の大きな前進です。これは、Xcode 6.3 がプロセスの自動化を支援するための移行を含んでいるように、コードの更新を必要とするいくつかのソース互換性のない変更を、含んでいます。移行を開始するには、[Edit] メニューをクリックして、その後 Convert> To Swift1.2...を選択します。

2015年1月28日

iTunes U 上で利用可能な新しい Swift 開発コース

iTunes U はトップの学校や著名な団体からの無料の教育コンテンツの世界最大のオンラインカタログです。教育機関の数千人は、芸術、科学、健康と医療、教育、ビジネス、ソフトウェア開発などを包含する、公開およびプライベートコースをホストしています。これらのコースは、キャンパス内クラスと同じカリキュラムを提供し、多くの場合、講義ビデオを含んでいます。

スタンフォード大学には、120 万回以上ダウンロードされている iTunes U 上の、最も人気のある iOS 開発コースの一つがあります。今、このコースでは、Swift を使用するように更新されました。新しい 「iOS 8 アプリを Swift で開発」 クラスからの最初の２講演が今ライブとなり、彼らが教えられていたように追加のレッスンが追加されます。英国で プリマス大学 などのように他の国際的に認められた大学からの Swift のコースが、他のトップの教育機関からすぐに来るでしょうし、iTunes U でも利用できます。

2015年1月23日

Swift REPL ですべてを再定義

REPL での私たちの最初のエントリ では、Swift 言語を学ぶ際にこの言語を実験して REPL を使用する方法を示し、基本だけをカバーしました。この投稿は、REPL を開発する際にあなたに新しい力を与えるために、REPL では通常のコーディングルールを曲げることの一つの方法を探ります。

識別子の再定義

Swift のコンパイラは、同じ識別子を二度定義することから生じる意図的でない曖昧さを含む、幅広いプログラムミスから自動的に守ります：

非対話型エディタでコーディングするときにはこれは理にかなっているが、REPL の対話型環境では、容易に変更を加えることができて便利です。REPL は、この種の利便性を念頭に置いて、はっきりと設計されました：

新しい定義は、その後のすべての参照の既存の定義を置き換えます。上記に示したように、定義の型でさえもその手順で変更することができます。これは、反復的な改良を通じて、広い範囲の実験を可能にします。たとえば、関数の再帰的な実装から始めましょう：

これは、この関数を記述するまさに一つの方法です。異なるアルゴリズムと API を試して、コードを試すことができます。 REPL は、簡単に新しく、かつ改良した実装を定義することができます。

REPL で同じ式を入力すると、今度は新しい実装を実行します。これは単純な例ですが、REPL は容易にするために設計されたことを繰り返し実験実験した事を示している。

再定義かオーバーロードか？

定数、変数、および型を、すべて直感的に働くように再定義し、そして、上記で参照できるように、関数を再定義することも可能です。これは明白な疑問を提起します：どうしてこれは関数のオーバーロードで相互に作用しないのでしょうか？上記のフィボナッチの例のように、それは同じ名前と署名を持つ場合にのみ、REPL は既存の定義を置き換えます。同じ名前の関数が、すでに存在する別の署名を持つ場合、それはまさに新しいオーバーロードを定義します。Swift は２つの署名が彼らの戻り値の型でのみ異なる場合でも、関数がオーバーロードを可能にする点に注意してください。例えば：

上記の宣言は、使用可能なオーバーロードの一方のみが、互換性のある型を返すように推測できる方法で、呼び出さなければならない２つの異なる関数を定義しています。

キャプチャの定義

識別子を再定義する機能は強力ですが、それは識別子のその後の使用にのみ適用されます。すでに REPL でコンパイルされたコードの全ての行は、以前の定義への参照を保持します。新しい定義が古いものを覆い隠すが、それを完全に除去しないかのようにです。これは実際にどのように機能するかを次に示します。

一度に例の文の１行目から、歩いて行くのは、ここで何が起こっているかを理解するのに役立ちます。30 行目は、挨拶に message という名前の変数を宣言します。行 31-33 は、30 行目に宣言された変数の内容を出力する printMessage() と言う関数を宣言しています。34 行目は、メソッドを呼び出して、期待される結果を生成しています。これまでのところ、それは非常に簡単です。

微妙な違いは、30 行目で宣言された変数に新しい値を代入する 35 行目で始まり、36 行目では予想通り新しい値を出力します。一方、37 行目では、同じ名前の新しい変数を宣言しています。これは、事実上すべての後続のコードから元の変数を隠しますが、38 行目上の呼び出しは、再定義の前にコンパイルされた関数を呼び出します。関数は、その本来の意味を保持し、新たに宣言された変数の値ではなく元の変数を出力します。39 行目では、予想通りに新しいコードにより、新しく定義された変数は、参照することができることを示している。

これらは関数、変数、または型を再定義するかどうか、再定義はすべて、この方法で動作します。REPL は、前の参照は所定の位置にある強い意味検査でコンパイルされたのに対し、制限なしの識別子を再定義するための自由を付与します。上記の例の message 識別子は、変数の代わりに、型として再定義された場合に何が起こるのでしょうか？printMessage() 関数は、もはやコンパイルしないでしょう。このような無限の潜在的な境界例をソートするのに開発者に依頼するのではなく、REPL は常に自己矛盾である世界観に一貫しています。

2014年12月12日

NSMethodSignature に何が起こった？

Swift に Cocoa フレームワークをもたらすことは私たちに新鮮な視点と私たちの API を見るユニークな機会を与えました。我々は Swift の目標にフィット感を感じていなかったクラスを見つけ、しばしば優先するために、安全性に与えます。例えば、動的なメソッド呼び出しに関連するいくつかのクラスは Swift の、名前を挙げれば NSInvocation と NSMethodSignature では公開されていません。

我々は最近、これがない事に気づいた開発者からバグ報告を受けました。この開発者は、メソッドの引数の型をイントロスペクトするために Objective-C で NSMethodSignature を使用しており、Swift にこのコードを移行するプロセスにおいて、NSMethodSignature が利用できないことに気づきました。コードは、以下のような様々な署名の HTTP ハンドラを受け入れることができるように移行されています：

Objective-C では、NSMethodSignature は第1のメソッドの API は [String: String] 引数を必要とすることを決定するために使用でき、第二のメソッドは JSON 値を必要とします。しかし、Swift は強力な言語であり、NSMethodSignature を使用せずに、容易にこのシナリオを扱うことができ、コンパイラは型やメモリ安全性のために提供しているヘルプを損なわない方法で、できます。

Swift で同じ問題を解決する別の方法は、次のとおりです。

まず、このインタフェースを介して私たちの、HTTPRequest を処理しようとしている物を何でも定義するためにプロトコルを使用します。このプロトコルは、一つのメソッドで処理でき、非常に簡単です。

なぜ HTTPHandler のクラスをサブクラスする代わりに、ここでプロトコルを使うのか？プロトコルは、このコードのクライアントまでの実装の詳細を離れる柔軟性を与えるからです。我々は HTTPHandler のクラスを作るとしたら、我々はそれらに参照型の意味を強制し、またクラスを使用するようにクライアントに要請します。しかし、プロトコルを使用して、クライアントは、それがクラス、構造体、あるいは列挙型であるかどうか、彼らのコードで使用する自分自身のために適切な型を決定することができます。

次に、私たちの HTTPServer のクラスには、パラメータとして HTTPHandlerType を受け入れる汎用メソッドがあります。ハンドラの関連する型を用いることで、このハンドラが要求を処理する機会が与えられるべきであるかどうかを決定するために args パラメータの条件付きダウンキャストを実行することができます。ここでは、プロトコルとして HTTPHandlerType を定義することの利点を見ることができます。HTTPServer はそのハンドラが要求に どのように 反応しているかを知る必要はありませんし、また、ハンドラそれ自体の性質を気にする必要もありません。それが知っている必要があるすべては値が要求を処理できるということです。

私たちの HTTPServer が要求を受信すると、そのハンドラを繰り返し処理し、すべての要求に対応できるかどうかを確認します。

私たちは簡単に引数の型を変化させ、HTTPServer に登録して、カスタムの HTTPHandlerType を作成できます。

プロトコルと汎用の組み合わせにより、我々は Swift のコードを書いて、様々な型の HTTP ハンドラをエレガントに作成、登録できるようになりました。このアプローチは、コンパイラ保証型の安全性を、動作時の優れた性能を確保しつつ、保証できます。

• Request.playground

2014年11月11日

Swift REPL の導入

Xcode 6.1 は、インタラクティブな PrintLoop の読む評価、または REPL の形で Swift を実験するさらに別の方法を紹介します。インタプリタ言語に精通している開発者は、このコマンドラインの環境で快適になり、さらに経験豊富な開発者は、いくつかのユニークな機能を見つけるでしょう。開始するには、Terminal.app (/Applications/Utilities の中にあります) を起動し、OS X マーベリックスでは "xcrun swift"と入力し、OS X ヨセミテではプロンプトに"swift"と入力して下さい。そうすると、Swift REPL になるでしょう：

する必要があるのは Swift 文を入力する事だけで、REPL はすぐにコードを実行します。変数と定数宣言の両方の結果であるとして、式の結果は自動的にフォーマットされ、その型で表示されます。コンソール出力は、インタラクティブセッションの中で自然に流れます：

一行目の結果は、式の結果が明示的に何にも割り当てられていないにもかかわらず、REPL によって名前が与えられていることに注意してください。その後の文で、それらの値を再利用するために、これらの結果を参照することができます。

Swift コンパイラは不完全なコードを認識し、必要なときには追加の入力を求めるプロンプトが表示されます。Xcode と同じように、コードは自動的にインデントされます。たとえば、関数を開始しましょう。

継続行のためのプロンプトは、コードフラグメントを完成するために求められているときにあなたに一目で伝えることができますので、新しい文を示している角括弧の代わりに、ピリオドが続く行番号です。この時点で、メソッドの残りの行を入力し続けることができます。

ここに、３つの注目すべき点があります：最初は、その 6 行目は、もともとインデントされていましたが、閉じカッコを入力すると REPL は自動的にインデントを解除します。第二は、関数が、我々が宣言するのを忘れたパラメータを参照し、戻り値の方を必要とし、宣言に両方を追加する必要があると言う事です。最後は、最後の行の後に Return キーを押した後であっても、それを修正するには遅すぎないということです。

コードはコンパイラに提出されると、また、些細な間違いを修正するなり REPL 履歴に記録されます。上記の不完全な関数宣言の最後にリターンを押した場合、次のメッセージが表示されたでしょう：

大部分の実装の履歴と同様に、プロンプトから上向き矢印を押すことによって、最後のエントリを呼び出すことができます。REPL は、私たちの例では３行すべてを思い出させ、そしてカーソルを最後に置きます。これで、次のセクションで説明するように、間違いを修正するためのコードの編集に進むことができます。

あなたの履歴は、セッション間で保持され、数百のコードフラグメントを記録します。一番上の行から上に移動する度に、以前の履歴エントリに移動します。エントリーの一番下の空の行から下に移動する度に、より多くの最近の履歴のエントリに移動します。次のエントリに移動する前に開く、空の行は、以下の理由のために便利です。

REPL は、従来のラインエディタと同じように動作しますが、また、ほとんどのクラスまたは関数の宣言のように、複数行の入力を処理するための便利な機能を提供します。上記の例では、最後の行でリターンを押す前に、上向き矢印を押してカーソルを宣言の行に移動し、左向き矢印を使用してパラメータリストの開き括弧の後にカーソルを移動します。

パラメータ宣言を入力し、閉じ括弧を超えて移動し、戻り値の型を入力して下さい。

あなたがテキストブロックの真ん中にいるので、この時点では宣言を完了するために、リターンキーを押すことができません。ここでリターンを押すと、開業を挿入し、関数やメソッド本体内に追加の行を挿入しようとしている場合に役立ちますが、ここでしたいのは宣言の最後に移動することです。そこに行くのに二回の下向き矢印を押すか、または Emacs のシーケンス ESC>(閉じ角括弧が続くエスケープキー)を使用できます。それが使用可能な状態ですので、最後の行の末尾でReturnキーを押すと、新たに宣言された関数をコンパイルします：

文の完了の自動検出はあなただけのコードを入力することができ、REPL が時間の大半を正しいことに使うことを意味します。しかし、それは、相互依存性を持っているので、同時に複数の宣言を提出する必要な機会が、存在します。次のコードを考えてみます。

一行ずつ上記のすべてを入力すると、３行目が完成して、最初の関数をコンパイルしようとすると、もちろん、これはエラーになります。

リターンを押したときに起こる自動補完検出を得るために、両方の関数を一行で宣言することもできますが、よりよい解決策があります。前述の第3行を入力した後、手動で4行目を作成するのに移動するために下向き矢印キーを押して、通常は残りを入力することができます。 ２つの宣言は、相互再帰の所望の目標を達成するため、一緒にコンパイルされます。

始めるのに役立つ、最も一般的に使用される編集とナビゲーションのキーの一部と便利なチャートを用意しました：

Arrow Keys		カーソルを左／右／上／下／に移動
Control+F		カーソルを右に一文字移動、右向き矢印と同じ
Control+B		カーソルを左に一文字移動、左向き矢印と同じ
Control+N		カーソルを次の行の終わりに移動、下向き矢印と同じ
Control+P		カーソルを前の行の終わりに移動、上向き矢印と同じ
Control+D		カーソルの下にある文字を削除
Option+Left		カーソルを前の単語の最初に移動
Option+Right		カーソルを次の単語の最初に移動
Control+A		カーソルを現在の行の最初に移動
Control+E		カーソルを現在の行の最後に移動
Delete			カーソルの左にある文字を削除
Esc <			カーソルを最初の行の初めに移動
Esc >			カーソルを最後の行の終わりに移動

2014年10月20日

Failable イニシャライザ

Swift バージョン 1.1 は Xcode 6.1 の新機能で、それには新機能が導入されています：failable イニシャライザ。初期化は、class または struct の保存されたプロパティのそれぞれに初期値を提供するオブジェクトの不変条件を確立するプロセスです。いくつかのケースでは、初期化が失敗する可能性があります。たとえば、オブジェクトを初期化することは、ファイルからイメージをロードするようにリソースへのアクセスが必要です。

ファイルが存在しない、または何らかの理由で読み取れない場合は、NSImage の初期化が失敗します。Swift バージョン 1.1 では、このような障害は failable イニシャライザを使用して報告することができます。failable イニシャライザを使用してオブジェクトを構築する場合、(初期化が成功した場合)オブジェクトが含まれているか、(初期化に失敗した場合)には nil が含まれている結果はオプションです。そのため、上記の初期化は直接オプションの結果を処理する必要があります。

init で定義されたイニシャライザは、init の後に ? または ! を追加することによって failable となるることができ、そのイニシャライザを持つオブジェクトを構築することによって生成される、optional の形を示しています。例えば、String からの変換を実行しようとする Int に failable イニシャライザを追加することができます。

failable イニシャライザでは、return nil は初期化に失敗したことを示します。他の値は返されません。この例では、文字列が整数として解析できなかった場合に、障害が発生します。そうでなければ、self は解析された値に初期化されます。

failable イニシャライザは、以前にこのオブジェクトを構築するときの障害を報告するための唯一の方法だった Swift におけるファクトリメソッドの、最も一般的な理由を排除します。例えば、生の型を持つ列挙型は、オプションの列挙型を返すファクトリメソッド fromRaw を提供します。さて、Swift コンパイラは生の値をとり、列挙ケースのいずれかにマップしようとして failable イニシャライザを synthesize します。たとえば、次のように：

failable イニシャライザを使用すると、イニシャライザとファクトリメソッド間の混乱や重複を排除することで、言語を簡素化し、Swift の統一した構文の、より一層の活用を可能にします。failable イニシャライザの導入に伴い、Swift は今や より多くの Cocoa の、NSError の引数を持つファクトリメソッドを扱えます - オブジェクト構築のための、より均一な体験を提供するイニシャライザとして。

Swift プログラミング言語 で failable イニシャライザの詳細を読むことができます。

2014年10月7日

初めて Swift のアプリをビルドした時のビデオ

これまでのところ、Swift のブログは Swift 言語の設計原理を含む高度なプログラミングのトピックに焦点を当てて来ました。初めて Swift を使用するプログラマや、Xcode を初めて使う人のためのコンテンツを提供するのは役立つだろうと思いました。みんなのためにそれをより親しみにするために、私たちは１０分以内に、最初から iOS アプリをビルドする方法を示す非常に短いビデオをまとめました。

2014年9月25日

assert()を Swift でビルドする(２)：__FILE__ と __LINE__

C の、時折便利な機能が２つ、__FILE__ と __LINE__ 魔法マクロです。これらはプリプロセッサに組み込まれ、そして C のCパーサーが実行される前に展開されます。プリプロセッサを持っていないにも関わらず、Swift は、同様の名前を持つ、非常に似た機能を提供しますが、Swift はカバーの下ではまったく異なる動作をします。

組み込み識別子

Swift プログラミングガイド で説明したように、Swift は __FILE__、__LINE__、__COLUMN__ を含め、また __FUNCTION__ などの組み込み識別子を沢山持っています。これらの式は、どこでも使用することができ、ソースコード内の現在位置に対応する文字列または整数リテラルへのパーサによって展開されます。これは手動でのロギングなどのために非常に便利で、すなわち終了する前に現在位置をプリントアウトします。

しかし、これは assert() を実装するための私達の探求で助けてはくれません。以下のように assert を定義した場合：

上記のコードは、assert() を実装するファイル名/行位置（）自体を出力し、発信者からの場所は出力しません。これは役に立ちません。

Swift は、D 言語から巧妙な機能を借用しました：デフォルトの引数リストで評価した場合、これらの識別子は、発信者の位置に展開します。この動作を有効にするため、assert() 関数は、以下のように定義されています：

Swift の assert() 関数の２番目のパラメータは、指定できるオプションの文字列であり、第３および第４引数は、呼び出し元のコンテキスト内の位置であることを怠っています。これは、デフォルトでは、呼び出し元のソースの位置を asset() がピックアップするのを可能にし、assert の上に独自の抽象化を定義したい場合は、その呼び出し元から位置を伝えて貰うことができます。簡単な例として、ログに記録し、次のように assert 関数を定義することができます：

これは適切に assert() の実装まで logAndAssert() 呼び出し元のファイル名/行の位置を伝播します。StaticString は、上記のコードに示すように、文字列リテラルを保存するために使用される単純な文字列のような型の、__FILE__ によって生成されるもので、メモリ管理オーバーヘッドではないことに注意してください。

assert() のために有用であることに加えて、この機能は、より高いレベルの XCTest フレームワークの Swift の実装で使用され、独自のライブラリに、同様に有用でしょう。

2014年9月9日

Swift は 1.0 になりました

2014年6月2日に WWDC で、Swift のチームは最終的に、私たちが何年も取り組んできていたものを説明しました。それは私たち、また世界中の開発者のための大きな興奮の大きな一日でした。今は、第二の重大な段階に達しました。

Swift バージョン 1.0 が今、GM になりました。

これで、App Store に Swift を使用したアプリを提出することができるようになりました。あなたのアプリが Swift を使って、小さな機能または完全なアプリケーションを作っていても、今は世界中でアプリを共有する時です。あなたの新しい作品で皆をびっくりさせるのはあなたの番です。

OS X のための Swift

今日は、iOS の Swift のための GM の日です。私たちは、また Mac のためのもう一つの GM の日があります。OS X 用の Swift は、現在、OS X ヨセミテの SDK を必要とし、今度の晩秋ヨセミテ船が出稿し、Swift は、Mac 上の GM になります。それまでの間、あなたは Xcode の 6.1 のベータ版 をダウンロードして、Swift で、Mac のアプリを開発し続けることができます。

前方に続く道

私たちが「最終」ではなく「GM」と言う単語を使っていることに注意して下さい。Swift は、新機能、パフォーマンスの向上、そして洗練された構文と共に進んで行くからです。実際には、ヨセミテの発売に間に合うようにいくつかの改善が間に合うように Xcode 6.1 で実現できることを期待できます。あなたのアプリは今、Swift の GM ランタイムのバージョンを埋め込んでいるので、それらは将来もうまく実行できます。

2014年9月3日

パターンのプレイグラウンド

Swift では、パターンは特定のルールに基づいて、値のセットを記述し、一致させる方法です。以下のように：

下記リンクでプレイグラウンドについて学習すると、実行するために埋め込まれたドキュメントや実験が含まれています。あなた自身のアプリのパターンを使用してあなたのジャンプスタートを与えるインタラクティブな体験のためにダウンロードしてみてください。

このプレイグラウンドは、OS X のマーベリックスまたは OS X のヨセミテ・ベータ上の Xcode 6 の最新ベータ版が必要です。

Patterns.playground

ここには勿論 Patterns.playground を zip 圧縮したものが置いてある。当然のことながら再配布等が禁止されているだろうから、developer.apple.comでダウンロードしてほしい。

2014年8月26日

Optionals のケーススタディ:valuesForKeys(キーの値)

この投稿は optionals が Swift 内で強力な型の安全性を維持する助けとどのようになるかを検討します。私たちは、Objective-C の API の Swift バージョンを作成している所です。Swift は本当はこの API を必要としませんが、それは楽しい例えとなります。

Objective-C では、NSDictionary には -objectsForKeys:notFoundMarker: メソッドがあり、キーとして NSArray を取り、対応する値の NSArray を返します。ドキュメントから:"返された配列内の N 番目のオブジェクトは、[入力パラメータ]キー内の N 番目のキーに対応しています。"それでは第三のキーは辞書に実際にはない場合はどうすれば？ここが、notFoundMarker のパラメータの登場です。配列の三番目の要素は、辞書からの値ではなくこのマーカーオブジェクトになります。Foundation フレームワークは、使用する別のものを持っていない場合であっても、この場合のクラスが用意されています:NSNull。

Swift は、Dictionary の型は objectsForKeys と同等のものを持っていません。この練習では、valuesForKeys として Swift での '価値'の共通化を踏まえてー私たちは拡張機能を使用して、一つを追加します。

Swift での新しい実装は Objective-C とは異なる所です。Swift は、より強力な類型化は要素の唯一のタイプを含むように結果の配列に制限します ー 私たちは、文字列の配列で NSNull を配置することはできません。しかし、Swift は、より良いオプションが用意しています：私たちは optionals の配列を返せます。すべての値が optionals に包まれ、NSNull の代わりに、nil を使用します。

注意： 皆さんの中には、Swift の Dictionary がこの API を必要としない理由を推測し、すでに以下のようなものを想像した人がいらっしゃるでしょう。

これは、上記の命令型のバージョンと完全に同じ効果がありますが、決まり文句のすべてが map するコールに直接ラップされています。これは直接 map を呼び出すことは簡単なので Swift のタイプは、多くの場合、小さな API の側面を持っているという理由の良い例です。

さあ、いくつかの例を試してみましょう。

ネストされた Optionals

さあ、それぞれの結果の last (最後) の要素を尋ねたら？

奇妙だー私たちは最初のケースで optionals の２つのレベルがあり、第２のケースでは Optionals(nil) 。どうなってるの？

last (最後)のプロパティの宣言を忘れないでください。

last (最後)のプロパティの型は配列の要素の型の Optional のバージョンであることをこれは述べています。この 場合には、要素型は、optional(String?) です。そこで、二重にネストされた optional のタイプの String?? で終わります。

それでは Optional(nil) は何を意味するのでしょうか？

Objective-C でプレースホルダとして NSNull を使おうとするところを思い出してください。これらの３つの呼び出しの Objective-C のバージョンは、次のようになります。

Swift と Objective-C のどちらの場合も、nil の戻り値は"最後の要素がないので、配列が空です"を意味します。Optional(nil) の(または Objective-C の NSNull の中)の戻り値は"この配列が存在し、その最後の要素、だが、それは存在しないことを表します。"Objective-C は、これを行うのに、プレースホルダオブジェクトに依存する必要がありますが、Swift は、型システムでそれを表現することができます。

デフォルトの提供

締めくくりには、辞書になかった場合何をデフォルトの値としてを提供して欲しかったのか？まあ、それは十分に簡単です。

Objective-C では、これを行うには、プレースホルダオブジェクトに依存する必要がありますが、Swift は型システムでそれを表現し、optional の結果を​​処理するための豊富な構文上のサポートを提供します。

2014年8月19日

アクセス制御と protected

Swift でアクセス制御のためのサポートに対する応答は、非常にポジティブでした​​。しかしながら、"Swift は protected のようなものを持っていないのはなぜ？"と何人かの開発者は尋ねます。他の多くの開発言語は、求めてきた他の多くのプログラミング言語は、サブクラス以外の場所からアクセスされる事から特定のメソッドを制限するアクセス制御オプションがあります。

Swift でアクセス制御レベルを設計する場合、主要な使用目的を２つ検討しました。

これらはそれぞれ、アクセス・レベルの private と internal に対応します。

これとは対照的に、protected は継承と共にアクセスを融合し、そのための理由に全く新しい制御軸を追加します。サブクラスは常に新しいパブリックメソッドやプロパティを介して"保護された"API を公開することができますので、それは実際には、本当の保護を提供しません。新しいオーバーライドがどこからでも来ることができるので、これは、いずれかの追加の最適化の機会を提供していません。それは不必要に制限的で、何かにアクセスするには、サブクラスのヘルパーのいずれかではなく、サブクラスを許可します。

一部の開発者が指摘したように、Apple のフレームワークは、サブクラスで使用するための API の部分の切り離しを時折実行します。ここで protected が有用ではありませんか？検査時には、これらのメソッドは一般に２つのグループのいずれかに分類されます。一つは、サブクラスの外にあり、メソッドは実際に有用ではなく、保護(protection)が重要でない(そして、上記のヘルパーケースを思い出して下さい)場合。第二に、オーバーライドされるように設計されているメソッドは、呼ばれないことがあります。例えば、drawRect(_:) で、確かに UIKit フレームのコードベース内で使用されますが、UIKit の外では呼ばれません。

protected は、拡張機能と対話する方法も明らかになっていません。クラスへの拡張機能は、そのクラスの保護されたメンバへのアクセスを持っていますか？サブクラスへの拡張機能は、スーパークラスの保護されたメンバへのアクセス権を持っていますか？拡張機能はクラスと同じモジュール内で宣言されている場合はそれが違いを生むでしょうか？

Objective-C の開発者の Apple の内側と外側の両方の既存の慣行：現在の設計に私たちを導いた他の一つの影響がありました。Objective-C のメソッドとプロパティは、一般的にパブリックヘッダ(.h)ファイルで宣言されますが、実装(.m)ファイル内のクラス拡張機能で追加することができます。public クラスの一部が別の場所のフレームワークの中ではなく外での使用を目的としていた場合、開発者は、クラスの"internal"ビットで第２のヘッダファイルを作成します。アクセスのこれらの３つのレベルは、Swift 内で public、private、および internal に対応しています。

Swift は、相続関係のない、単一の分かりやすい軸に沿ったアクセス制御を提供します。クラス内またはフレームワーク内に実装される、詳細を分離します：私たちは、このモデルは単純であり、アクセス制御を、それが最も頻繁に必要とされる方法で提供していると信じています。それはあなたが以前に使用したものとは異なる場合がありますが、それを試してみることをお勧めします。

2014年8月15日

値とリファレンスのタイプ

Swift のタイプは二つのカテゴリの一つに分類される：まず、"値のタイプ"、各インスタンスがそのデータの唯一のコピーを保持し、通常、構造体、列挙型、 または tuple として定義されるもの。二つ目は、"リファレンスのタイプ"、インスタンスがデータの単一のコピーを共有し、この型は、普通はクラス として定義されます。この記事では、値とリファレンスのタイプの利点を探索し、どのようにそれらを選択すればよいかを探ります。

何が違うの？

値型 の最も基本的な特徴は、そのコピーで、割り当て、初期化、および引数の受け渡しの影響ですー、そのデータの独自の一意のコピーを持つ独立したインスタンスを作成します。

リファレンスタイプのコピーは、一方、暗黙のうちに共有インスタンスを作成します。コピーした後、2つの変数はその後でデータの単一のインスタンスを参照しているため、オリジナルのものに影響を与える第二の変数にデータを変更します。

安全面での変異の役割

リファレンスタイプの上に値型を選択する主な理由の一つは、コードをより簡単にコードにする事ができるからです。常にユニークな、コピーされたインスタンスを取得する場合、アプリの他の部分ではカバーの下のデータを変更していないと信頼できます。マルチスレッド環境では、別のスレッドがあなたの下からデータを変更できる場合、これは特に便利です。これは、デバッグが非常に困難な厄介なバグを作り出します。

差異がデータを変更したときにどう定義されているか、という点のため、値とリファレンスのタイプが重複する一つのケースがあります：インスタンスに、書き込み可能なデータがないとき。変異がない場合、値とリファレンスはまったく同じように作用します。

クラス が完全に不変である場合、価値があると考えても良いかも知れない。これは値のセマンティクスの利点を維持しながら、Cocoa の NSObject のオブジェクトを使用するのが簡単になるだろう。今日では、Swift で不変のクラスを書く事ができ、任意の状態を変更できる API を公開するのを避けることによって不変の格納されたプロパティを使用する事ができます。実際、NSURL などの多くの一般的な Cocoa のクラスは、不変クラスとして設計されています。しかし、Swift は、クラス に不変性を強制する全ての言語メカニズム(サブクラス上でなど)が struct や enum のための不変性を強制する方法を提供していません。

どのように選択したらいい？

新しいタイプをビルドしたいのであれば、どちらの種類を作るかどう決めるのですか？Cocoa で作業しているときは、多くの API は、NSObject のサブクラスを期待するので、クラス を使用する必要があります。その他の場合は、ここでいくつかのガイドラインを示します。

値型を使用するのはこんな時：

リファレンスタイプを使用する(例えば、クラス を使用する)のはこんな時：

Swift では、配列、文字列、および Dictionary は、すべての値のタイプです。それらは、C 言語での単順な int の値のように振る舞い、そのデータの唯一のインスタンスとして動作します。あなたは特別なことをする必要はありませんー明示的なコピーを作成するようなー背中の後で他のコードを改変するようなことから防ぐために。重要なことは、同期することなく、スレッド間で変数を安全に渡すことができます。安全性向上の精神では、このモデルでは Swift で、より予測可能なコードを書くのに役立ちます。

2014年8月8日

バルーン

WWDC で Swift を紹介する際、私たちがバルーンのプレイグラウンドについて多くの人が尋ねてきました。バルーンは、コードを書くことが、インタラクティブで楽しく、プレイグラウンドのいくつかの優れた機能を提示しています。今、あなたは"Balloons.playground"の学習的バージョンで特別な効果がされる事を学び、これは実験のためのドキュメントや示唆提案を含みます。

このプレイグラウンドは SpriteKit の新機能を使用し、Xcode 6 と OS X のヨセミテの最新のベータバージョンが必要です。

Balloons.playground

ここには勿論 Balloon.playground を zip 圧縮したものが置いてある。当然のことながら再配布等が禁止されているだろうから、developer.apple.comでダウンロードしてほしい。

2014年8月5日

ブール値

Swift ではブール値 bool 型を原始的な機能の多くの基礎とし、それを単純型としてビルドする方法の興味深いデモを作っています。この投稿では、Swift に組み込まれ、設計され実装されている Bool 型に非常に類似している、新しい MyBool タイプの作成を見て行きます。私たちは、単純な Swift 型のデザインを通じて、この散歩は、この言語がどのように機能するかを理解するのに役立つことを願っています。

基本的な定義から始めましょう。MyBool タイプは列挙型の完全な二つの異なるケースをモデルにしています：

この記事の混乱を減らすために、このケース を myTrue と myFalse と名付けました。私たちは、MyBool() が偽の値を生成するため、および init メソッドを提供することによって、そうすることができます。

Swift の列挙宣言が暗黙的にそれらの体にそれらの列挙子をスコープし、コンテキストタイプが利用できるようになっても、私たちに MyBool.myFalse や .myFalse さえ参照できるようにします。しかし、私たちの型が原始的な true と false の文字通りのキーワードで動くようにしたい。この作業を行うためには、MyBool にこのような BooleanLiteralConvertible プロトコルに準拠させることができます。

このセットアップによって、私達の基本的なタイプができますが、私たちはまだそれで多くを行うことはできません。ブール値は、if 条件内でテスト可能である必要があります。Swift は、これを BooleanType プロトコルとしてモデルにし、任意のタイプを論理条件として使用することができます：

また、MyBool にキャストできるので BooleanType に準拠する何かをしたいので、追加します：

イニシャライザ引数リスト内の_ の使用は MyBool(v:x) を要求する代わりに MyBool(x) の構文を使用することが可能になるキーワード引数を無効にします。

今、私たちは基本的な機能を持っていますが、== 演算子を皮切りに、これで動作するようにいくつかの演算子を定義してみましょう。(MyBool のような)関連するデータを持たない単純な列挙型は、コンパイラによって自動的に Equatable (同等)に作られているので、追加のコードは必要ありません。ただし、Equatable プロトコルに準拠し、== 演算子を実装することで、任意のタイプを同等とすることができます。MyBool が既に Equatable でなかった場合、これは次のようになります。

ここでは、これを処理するために、switch ステートメントで、一致するいくつかの単純なパターンを使用しています。MyBool は今 Equatable なので、私たちは ！= 演算子のフリーな実装をする事ができます。二項演算を追加しましょう：

代わりに、基本的な演算子では、同様に有用な単項および化合代入演算子のさまざまな実装ができます。たとえば：

&= 演算子は、それへの読み書き、およびその効果は、オペレータのユーザに見えなければならないため、&= 演算子は、inout の左オペランドを取ります。Swift ではあなたが、enum や struct などの値型に対する操作の可変性を完全に制御できます。

これにより、単純な MyBool タイプは、基本的な操作と演算子のすべてを持っています。うまくいけば、この投稿はあなたに、より高いレベルの型を定義する際に、独自のコードに適用できるいくつかのヒントを提供するでしょう。

2014年8月1日

ファイルと初期化

今では、あなたたちのほとんどは、小さな Swift のアプリを書いた事があるか、プレイグラウンドで実験を行った事があるだろう。別のファイルにプレイグラウンドからコードをコピーして、エラーが起こったのを経験して、「何が起こったのだろう、プレイグラウンドのファイルと他の Swift のソースファイルの使っているのだろう」と、不思議に思っただろう。この投稿は、どのように Swift がプロジェクト内のファイルを扱い、どのようにグローバルデータが初期化されるか説明します。

アプリ内のファイル

Swift アプリは、ファイル、それに伴う関数、クラス、およびその他の宣言とで成り立ち、各々構成される数は任意です。あなたのアプリのほとんどの Swift のファイルは、順序に依存せず、その意味は、それが定義される前に、型を使用することができ、ファイルの一番下にあっても、モジュールをインポート(けれども Swift スタイルが推奨されるものではない)することができます。

しかし、トップレベルのコードは、あなたの Swift のソースファイルのほとんどでは許可されません。明確にすると、すべての実行文は、関数本体内に記述されず、クラス内か、そうでなければ、トップレベルと考えられるカプセル化されています。トップレベルのコードが、すべてのファイルで許可された場合、どこからプログラムを始めるかを決定するのは難しいので、私たちは、このルールを持っている。

プレイグラウンド、REPL、トップレベルのコード

以下のコードがプレイグラウンドで完璧に動作するのを疑問に思うかもしれません。この例は、全くカプセル化されていないので、トップレベルのコードでなければなりません。

上記の一行のプログラムは動作しますー追加のコードでまったくなしでープレイグラウンドのファイルはトップレベルのコードの実行をサポートするから。プレイグラウンドファイル内のコードは、順序依存で、トップダウンの字句順に実行されます。例えば、それを定義する前に、型を使用することはできません。もちろん、Swift のプレイグラウンドファイルも関数、クラス、およびその他の法的な Swift コードを定義できますが、する必要はありません。これにより、簡単に Swift 言語を学ぶ事ができ、始めるために多くのコードを書くことなく、新しい API を試してみることができます。

プレイグラウンドに加えて、スクリプトとして Swift のファイルを起動するときに、トップレベルのコードには、REPL(読み取り評価出力ループ:Read-Eval-Print-Loop)で実行する事もできます。スクリプトで Swift を使用するには、Swift ファイルを“#!/usr/bin/xcrun swift”で開始することによって、骨組みスタイルの起動を使用するか、ターミナルで“xcrun swift myFile.swift”とタイプします。

アプリのエントリポイントと"main.swift"

以前、私たちが、トップレベルのコードは、アプリのソースファイルのほとんどで許可されていないと言っていたことに気づくでしょう。例外は、多くのプレイグラウンドのファイルと同じように動作する、"main.swift"という名前の特別なファイルですが、あなたのアプリのソースコードでビルドされています。"main.swift"ファイルは、トップレベルのコードを含めることができ、順序依存の規則も同様に適用されます。実際には、"main.swift"で実行するためのコードの最初の行が暗黙的にプログラムのためのメインエントリポイントとして定義されています。その行が"main.swift"にある限りーこれは、最小限の Swift プログラムが一行にすることができる事です。

Xcode では、Mac のテンプレートのデフォルトでは"main.swift"ファイルを含んでいますが、iOS のアプリ では、新しい iOS のプロジェクトテンプレートのデフォルトを通常の Swift ファイルに @UIApplicationMain を追加することです。これは iOS アプリの main エントリ·ポイントを synthesize するようにコンパイラを引き起こし、"main.swift"ファイルが不要になります。

別の方法として、Objective-C で書かれた main の実装に、一般的に段階的に Objective-C から Swift へとプロジェクトを移行するとき、リンクさせることができます。

グローバル変数

アプリの実行を開始する場所を Swift が決定する方法を考えると、どのようにグローバル変数が動作するか考えさせられますね？次のコード行で、初期化する実行はいつですか？

単一ファイルのプログラムでは、コードは、関数内の変数の挙動のように、トップダウンで実行されます。非常にシンプルです。複雑なアプリの答えはそれほど明白ではなく、私達は３つのオプションを考えました：

1. C がそうであるように、単純な定数式であることが、グローバル変数の初期化子を制限します。
2. C++ が行うように、アプリのロード時に静的コンストラクタとして実行するすべての初期化子を、許可します。
3. 遅れて初期化、それは、Java と同様に、参照されるグローバルを最初に初期化子を実行します。

C が行うようには、Swift は定数式を必要としないので、最初のアプローチは、除外されました。Swift では、定数は一般的に(インライン化した)関数呼び出しとして実装されます。そして、例えば、複雑な初期化子を使用するには十分な理由があるシングルトンを設定したり、辞書を割り当てます。

第２のアプローチは、大規模なシステムのパフォーマンスでは悪いため、アプリが起動する前にすべてのファイル内の全ての初期化子が実行する必要があるため、除外されました。異なるファイルでの初期化の順序が指定されていないので、また予測不可能であるため。

Swift は、第３のアプローチを使用し、すべての世界の最良です：それは、カスタム初期化子、Swift での起動時間がグローバル初期化子がないのでそれを遅くしていないか、実行順序は完全に予測可能であるためです。

グローバル変数の遅い初期化子(これも構造体と列挙型の静的メンバなので)は、グローバルがアクセスされた時最初に実行され、初期化が爆発的であることを確認する dispatch_once として起動されます。ただ初期化子でグローバル変数を宣言し、それが private とマークし、これは、コード内で dispatch_once を使用する、クールな方法を可能にします。

要約

Swift はプレイグラウンドで実験するか、すぐにスクリプトを作成することが簡単なように設計されています。完全なプログラムコードを１行で書くことができます。もちろん、Swift はまたあなたが夢見ることができる最も複雑なアプリにも拡張できるように設計しました。"main.swift"を使用すると、初期化を完全に制御を取ることができるか、@UIApplicationMain に iOS の上であなたのためにスタートアップ作業をやらせることもできます。

2014年7月28日

C のポインタとの相互作用

Objective-C と C の API は、多くの場合、ポインタの使用が必要な場合があります。Swift のデータ型は、ポインタベースの Cocoa の API を使用する際、自然に感じるように設計されており、Swift は、自動的に引数としてポインタを最も一般的な利用する場合のいくつかを処理します。この記事では、C 言語でのポインタパラメータを Swift の変数、配列、または文字列として使用する方法を見ていきます。

イン/アウトのパラメータとしてのポインタ

C と Objective-C は、複数の戻り値をサポートしていないので、Cocoa の API は頻繁に、関数から追加データを渡す方法としてポインタを使用しています。Swift は、同じ & 構文を使用して、ポインタを引数として var への参照を渡すことができるようにポインタパラメータは、inout パラメータのように扱えます。例えば、UIColor の getRed(_:green:blue:alpha) メソッドは、カラーの成分を受信するために４つの CGFloat* のポインタを取ります。私たちは、ローカル変数にこれらのコンポーネントを収集するために & を使用えます：

別の一般的なケースは、Cocoa の NSError イディオムです。多くのメソッドが失敗した場合にエラーを保存するために NSError** パラメータを取ります。例えば、NSFileManager の contentsOfDirectoryAtPath(_:error:) メソッドを使って、ディレクトリの内容をリストアップでき、NSError? 変数に直接潜在的なエラーを保存できます。

安全のために、Swift は & に渡される前に変数を初期化する事を必要とします。それはメソッドがそれに書き込む前にポインタから読み取ろうとしているかどうかを知ることができないためです。

配列パラメータとしてのポインタ

ポインタは、C の配列と複雑に絡み合っており、Swift はポインタ引数として使用する Array を可能にすることにより、配列をベースにした、C API での作業を容易にします。不変の配列の値が const ポインタとして直接渡すことができ、可変配列はちょうど inout のパラメータと同様に、& 演算子を使用して、non-const ポインタ引数として渡すことができます。たとえば、２つの配列 a と b を加え、Accelerate フレームワークから vDSP_vadd 機能を利用して３番目の結果の配列に結果を書き込むことができます。

文字列パラメータとしてのポインタ

C 言語は、文字列を周りに渡すための主要な方法として const char* ポインタを使用しています。Swift String (文字列)は NULLで終わる文字列、UTF-8 でエンコードされた表現で、関数にポインタを渡す const char* ポインタとして使用できます。たとえば、標準 C および POSIX ライブラリ関数に直接文字列を渡すことができます：

ポインタ引数の変換の安全性

Swift は、安全性のいくつかのレベルを提供しながら、C ポインタの利便性との相互作用が、Cocoa 内での普及により、一生懸命働きます。しかしながら、C のポインタとの相互作用は、あなたの他の Swift のコードに比べて本質的に危険です。具体的には：

これらのガイドラインに従わないポインタ·ベースの API と連携する必要がある、または、ポインタパラメータを受け入れる Cocoa メソッドをオーバーライドする必要がある場合は、Swift でのは安全でないポインタを使う生メモリを直接操作できます。今後の記事で、より高度なケースを見ていきます。

2014年7月23日

アクセス制御

Xcode ６ベータ４では、Swift には、アクセス制御のサポートが追加されています。これは、あなたのコードの一部が、単一のファイル内でアクセスできて、あなたのプロジェクト全体で使用可能な、またはあなたのフレームワークをインポートする人のための API として公開されているかを完全に制御できます。このリリースに含まれる３つのアクセスレベルは次のとおりです：

• private の性質は、それらが定義されているソースファイル内からのみ利用できます。


• internal の性質は、定義(例えばアプリやフレームワークのターゲット)が含まれる、モジュール全体で使用できます。


• public の性質は、API としての使用を意図しており、モジュールをインポートする任意のファイル、たとえばプロジェクトのいくつかで使用されるフレームワークとしてアクセスできます。



デフォルトでは、すべての性質は、Internal アクセスを持っています。これにより、アプリ開発者は、アクセス制御を主に無視することができ、ほとんどの、既に書かれた Swift のコードは変更せずに動作します。あなたのフレームワークのコードは、あなたのフレームワークが提供する公開されたインターフェースの完全なコントロールを与える、public APIを定義するためにアップデートする必要がありません。




private アクセスレベルは最も制限されており、簡単に他のソースファイルから実装の詳細を隠すことができます。適切にあなたのコードを構造化することで、安全に、プロジェクトの残りの部分にそのコードを公開せずに拡張機能やトップレベルの関数などの機能を使用することができます。




彼らのプロジェクトの全体を通してフレームワークをビルドする開発者は、API を public としてマークする必要があります。(以前のブログ記事で述べたように)サードパーティのバイナリのフレームワークの配布および使用は推奨されませんが、Swift はソース形式で建設やフレームワークの配布をサポートしています。




全体の宣言にアクセスできる仕様を可能にすることに加えて、Swift は、プロパティの get がその set よりもアクセスできるようになります。ここでは、フレームワークの一部であるクラスの例を挙げます：





public class ListItem {
       // Public properties.
       public var text: String
       public var isComplete: Bool
       // Readable throughout the module, but only writeable from within this file.
       private(set) var UUID: NSUUID
       public init(text: String, completed: Bool, UUID: NSUUID) {
               self.text = text
               self.isComplete = completed
               self.UUID = UUID
       }
       // Usable within the framework target, but not by other targets.
       func refreshIdentity() {
               self.UUID = NSUUID()
       }
       public override func isEqual(object: AnyObject?) -> Bool {
               if let item = object as? ListItem {
                       return self.UUID == item.UUID
               }
               return false
       }
}





Objective-C と Swift が混在する場合、フレームワークのために生成されたヘッダは、フレームワークの public の Objective-C インターフェイスの一部であるため、唯一の宣言である public が生成された Swift のフレームワークのヘッダーに表示されるマークです。アプリでは、生成されたヘッダーは、public と internal の宣言を含んでいます。




詳細については、 Swift プログラミング言語 と、Cocoa と Objective-C での Swift の使用の本は、アクセス制御をカバーするために更新されています。完全な Xcode ６ベータ４リリースノートはここに。




---




2014年7月18日




assert()を Swift でビルドする(1):遅延評価



更新： Xcode 6 ベータ 5 の変更を反映するために、この記事は @auto_closure を @autoclosure に改め、LogicValue を BooleanType に改めました。




Swift を設計するとき、私たちはバグを排除し、コードの理解がはるかに容易になり、C プリプロセッサを廃止するための重大な決定をしました。これは開発者にとって大きな勝利であるが、それはまた、Swift が、新たな方法でいくつかの古い機能を実装する必要があることを意味します。これらの機能のほとんどは明白(インポートモジュール、条件付きコンパイル)ですが、おそらく最も興味深いものは、Swift が assert() のようなマクロをサポートする方法です。




C 言語でのリリースでビルドする場合は、全ての引数を評価していないため、assert() マクロは、実行時のパフォーマンスに影響を与えません。C 言語における、ある一般的な機能は次のようになります：






#ifdef NDEBUG
#define assert(e) ((void)0)
#else
#define assert(e)    \
       ((void) ((e) ? ((void)0) : __assert (#e, __FILE__, __LINE__)))
#define __assert(e, file, line)    \
       ((void)printf ( "%s:%u: failed assertion `%s'\n", file, line, e), abort())
#endif





Swift の assert に似た物は、プリプロセッサを使用せずに、ほとんどすべての C 言語の assert の機能をよりクリーンな方法で提供します。それでは、Swift のいくつかの興味深い特徴に飛び込んで行き、知りましょう。




引数の遅延評価




Swift 内の assert() を実装するとき、私たちが遭遇する最初の課題は、関数を評価せずに式を受け入れるための明白な方法がないことです。例えば、私たちが使おうとしたとしましょう：





func assert(x : Bool) {
       #if !NDEBUG
               /*noop*/
       #endif
}





アサーションが無効になっている場合でも、アプリは、式を評価するので、パフォーマンスは打撃を受けるでしょう：





assert(someExpensiveComputation() != 42)





私たちがこの問題を解決できた一つの方法は、閉鎖するように assert の定義を変更することです：





func assert(predicate : () -> Bool) {
       #if !NDEBUG
               if !predicate() {
                       abort()
               }
       #endif
}





これは私たちが望むような assertion が、有効になっている間だけ式を評価しますが、それは不幸な呼び出し構文を私たちに残します：





assert({ someExpensiveComputation() != 42 })





私たちは、Swift で @auto_closure 属性を使用してこれを修正することができます。自動閉鎖属性は、飾り気のない式が暗黙的に関数を閉じるようにラップする必要があることを示すために、関数に引数で使用できます。この例では、以下のようになります：





func assert(predicate : @autoclosure () -> Bool) {
       #if !NDEBUG
               if !predicate() {
                       abort()
               }
       #endif
}





これは、以下のように、自然に呼び出すことができます：





assert(someExpensiveComputation() != 42)





あなたが条件付きで、式を評価することを何度も評価し、閉鎖属性を使用することができる任意の方法で bound の式を使用することができるので、自動閉鎖属性は強力な機能です。自動閉鎖属性は、同様に Swift の他の場所でも使用されています。例えば、短絡論理演算子の実装は以下のようになります：





func &&(lhs: BooleanType, rhs: @autoclosure () -> BooleanType) -> Bool {
       return lhs.boolValue ? rhs().boolValue : false
}





自動閉鎖属性などの式の右辺をとることにより、Seift はその部分式の適切な遅延評価を提供します。




自動閉鎖属性




C 言語のマクロと同様に、自動閉鎖属性は、その引数の評価が影響を受けるため、発信者側の適応がないため、慎重に使用する必要があり、非常に強力な機能です。自動閉鎖属性は、意図的にのみ、空の引数リストを取る事に限定されており、あなたは、制御フローのように感じる場合には、それらを使用しないでください。それらは人々が(おそらく「未来の」API の)期待するだろうが、自動閉鎖属性に、中括弧を最適化するだけの目的で利用しないようにし、便利な意味を提供する際に使用してください。




これは Swift での assert の実装の一つの特殊な側面をカバーしていますが、多くの将来性があります。





---




2014年7月15日




Xcode ６ ベータ３での Swift 言語の変更




Swift プログラミング言語は、新機能、構文の拡張、および行動の改良など、それぞれの新しい Xcode ６ ベータ版で前進し続けています。 Xcode ６ ベータ３は、いくつかの重要な変更をしており、そのうち強調すべきいくつかが組み込まれています。



• 配列は完全に辞書(Dictionary)と文字列(String)の動作と一致するように、完全な値の意味を持つように再設計されました。今の let 配列は完全に不変であり、var の配列は完全に変更可能です。


• 配列および辞書の構文「sugar」は変更されました。配列は、[Int] を Array<Int> の略に使って Int[] の代わりに使って宣言します。同様に、辞書では、Dictionary<Key, Value> の代わりに [Key: Value] を使います。
• 半開範囲演算子が変更され、.. から.. < に、それをより明確にするため、また閉鎖範囲について... 演算子を使って下さい。

Xcode ６ベータ版は、登録された Apple の開発者には無料で、Xcode ダウンロードページでダウンロードできます。これらの事を完全に知るには Xcode ６ベータ３のリリースノートについてをお読みください。

(注意：ここの部分 リンクがあるが、すでに使命を終えたリンクである。あえてリンクを張りませんでした。)

2014年7月11日

互換性

私たち(アップルがは WWDC で聞いた最も一般的な質問の一つは、「スイフトの互換性についての話はないですか？」だった。これは素晴らしい最初のトピックスのように思える。

アプリの互換性

あなたが今日 Swift アプリを書いて、iOS 8 と OS X ヨセミテがリリースされるこの秋 App Store に、提出した際に、簡単に言えば、あなたのアプリは、将来にわたってうまく動作することを信頼することができます。実際に、その同じアプリで OS X マーベリックスまたは iOS 7 に戻って、それらをターゲットにすることもできます。Xcode は、アプリのバンドル内には小さな Swift の実行環境ライブラリを埋め込むので可能だからです。ライブラリが埋め込まれているため、あなたのアプリは、過去、現在、未来の OS リリース上で動作する Swift の一貫したバージョンを使用できます。

バイナリ互換性とフレームワーク

アプリの実行時の互換性を確保しつつ、Swift 言語自体は進化し続け、バイナリインタフェースも変更されて行きます。安全のために、あなたのアプリのすべてのコンポーネントは、それらが一緒に動くことを確認するため、Xcode と Swift とで同じバージョンのコンパイラでビルドする必要があります。

これは、フレームワークは慎重に管理する必要があることを意味します。例えば、あなたのプロジェクトが、組み込み拡張子とコードを共有するためにフレームワークを使用した場合、あなたは一緒にフレームワーク、アプリ、および拡張機能をビルドしたいと思うでしょう。特にサードパーティから、Swift を使用する、バイナリのフレームワークに依存するのは危険でしょう。Swift が変化すると、これらのフレームワークは、アプリの残りの部分と互換性がなくなります。バイナリのインタフェースは、１年や２年で安定したら、Swift の実行環境は、ホスト OS の一部となり、この制限はもはやなくなるでしょう。

ソース互換性

Swift は、ブランドの新しいアプリにしたり、実績のある Objective-C のコードと一緒に、今日使用できます。私たちは、構文の改良、および強力な新機能を含む、Swift 言語のための大きな計画があります。Swift が進化するのに会わせて、私たちは Xcode でのツールを提供し、あなたのソースコードが進化する移行するようにお手伝いします。

私たちは、あなたがビルドしたものを見るのが待てない！

Swift のブログへようこそ

この新しいブログは、あなたに舞台裏の最新のニュースをもたらす事に加えて、それを作成した Swift のエンジニアにより Swift の言語を設計するのを見せ、生産的な Swift のプログラマになれるようヒントを与えます。

すべての登録された Apple の開発者に利用できるようになった Xcode 6 ベータ版 を無料でダウンロードすることで、スウィフトを始めましょう。Swift Resource タブには沢山のビデオ、ドキュメント、書籍、サンプルコードがあり、あなたを世界初の Swift のエキスパートの一人になれるよう、補助します。コーディングするためのこれ以上のより良い時間があったことはないでしょう！

- Swift チーム