Automatic Reference Counting¶ 自動参照カウント¶

How ARC Works¶ ARCは、どのように働きますか¶

Every time you create a new instance of a class, ARC allocates a chunk of memory to store information about that instance. This memory holds information about the type of the instance, together with the values of any stored properties associated with that instance. あなたがクラスの新しいインスタンスをつくるたびに、ARCはメモリのある量を割り当てて、そのインスタンスに関する情報を格納します。このメモリは、インスタンスの型に関する情報を、そのインスタンスと結びつけられるあらゆる格納プロパティの値と共に持ちます。

Additionally, when an instance is no longer needed, ARC frees up the memory used by that instance so that the memory can be used for other purposes instead. This ensures that class instances don’t take up space in memory when they’re no longer needed. その上に、インスタンスがもはや必要でないとき、ARCはそのインスタンスによって使われるメモリを開放します、それでメモリが代わりに他の目的のために使われることができます。これは、クラスインスタンスが、それらがもはや必要でない時に、メモリ上で場所を取らないことを確実にします。

However, if ARC were to deallocate an instance that was still in use, it would no longer be possible to access that instance’s properties, or call that instance’s methods. Indeed, if you tried to access the instance, your app would most likely crash. しかし、ARCがまだ使用中だったインスタンスの割り当て解除をすることになったならば、そのインスタンスのプロパティにアクセスすることや、そのインスタンスのメソッドを呼ぶことは、もはや可能でないでしょう。実はそれどころか、あなたがそのインスタンスにアクセスしようとするならば、あなたのアプリはたぶんクラッシュするでしょう。

To make sure that instances don’t disappear while they’re still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance. ARC will not deallocate an instance as long as at least one active reference to that instance still exists. それがまだ必要な間にインスタンスが消えないことを確実にするために、ARCは、どれくらいのプロパティ、定数、および変数が目下のところ各クラスインスタンスに言及しているかを追跡します。ARCは、そのインスタンスへの少なくとも１つの活発な参照がまだ存在する限り、インスタンスの割り当て解除をしません。

To make this possible, whenever you assign a class instance to a property, constant, or variable, that property, constant, or variable makes a strong reference to the instance. The reference is called a “strong” reference because it keeps a firm hold on that instance, and doesn’t allow it to be deallocated for as long as that strong reference remains. これを可能にするために、あなたがクラスインスタンスをプロパティ、定数、または変数に代入するときはいつでも、そのプロパティ、定数、または変数はそのインスタンスへの強い参照を作ります。この参照が「強い」参照と呼ばれるのはそれがそのインスタンスに対する堅い支配力を保つからです、そしてその強い参照が残る限りは、そのインスタンスがメモリ割り当て解除されるのを許しません。

ARC in Action¶ ARCの動作¶

Here’s an example of how Automatic Reference Counting works. This example starts with a simple class called Person, which defines a stored constant property called name: 自動参照カウントがどのように働くかの例は、ここにあります。この例は、Personと呼ばれる単純なクラスから始めます、それは、nameと呼ばれる格納定数プロパティを定義します：

The Person class has an initializer that sets the instance’s name property and prints a message to indicate that initialization is underway. The Person class also has a deinitializer that prints a message when an instance of the class is deallocated. Personクラスは、インスタンスのnameプロパティを設定して、初期化が進行中であることを示すためにメッセージを出力するイニシャライザを持ちます。Personクラスはまた、クラスのインスタンスが割り当て解除されるとき、メッセージを出力するデイニシャライザを持ちます。

The next code snippet defines three variables of type Person?, which are used to set up multiple references to a new Person instance in subsequent code snippets. Because these variables are of an optional type (Person?, not Person), they’re automatically initialized with a value of nil, and don’t currently reference a Person instance. 次のコード断片は、型Person?の３つの変数を定義します、それは、以降のコード断片の中のある１つの新しいPersonインスタンスへの複数の参照を準備するために使われます。これらの変数がオプショナル型（Personではなく、Person?）であることから、それらは自動的にnilの値で初期化されて、今はPersonインスタンスに参照をつけません。

You can now create a new Person instance and assign it to one of these three variables: あなたは、いま新しいPersonインスタンスを作成して、それをこれらの３つの変数のうちの１つに代入することができます：

Note that the message "John Appleseed is being initialized" is printed at the point that you call the Person class’s initializer. This confirms that initialization has taken place. あなたがPersonクラスのイニシャライザを呼んだ時点で、メッセージ"John Appleseed is being initialized"が出力されるという点に注意してください。これは、初期化が起こったことを確認します。

Because the new Person instance has been assigned to the reference1 variable, there’s now a strong reference from reference1 to the new Person instance. Because there’s at least one strong reference, ARC makes sure that this Person is kept in memory and isn’t deallocated. 新しいPersonインスタンスがreference1変数に代入されたので、現在は強い参照がreference1から新しいPersonインスタンスまで存在します。少なくとも１つの強い参照があるので、ARCはこのPersonがメモリの中に保たれて割り当て解除されないことを確実にします。

If you assign the same Person instance to two more variables, two more strong references to that instance are established: あなたが同じPersonインスタンスをさらに２つの変数に代入するならば、そのインスタンスへのさらに２つの強い参照が確立されます：

There are now three strong references to this single Person instance. 現在この１つのPersonインスタンスへの３つの強い参照があります。

If you break two of these strong references (including the original reference) by assigning nil to two of the variables, a single strong reference remains, and the Person instance isn’t deallocated: あなたが変数のうちの２つにnilを代入することによってこれらの強い参照のうちの（最初の参照を含む）２つを壊すならば、１つの強い参照が残ります、そしてPersonインスタンスは割り当て解除されません：

ARC doesn’t deallocate the Person instance until the third and final strong reference is broken, at which point it’s clear that you are no longer using the Person instance: ARCは、Personインスタンスの割り当て解除を３番目で最後に残ったの強い参照が壊れるまで行いません、その時点では、あなたがもはやPersonインスタンスを使っていないことは明白です：

Strong Reference Cycles Between Class Instances¶ クラスインスタンス間の強い参照循環¶

In the examples above, ARC is able to track the number of references to the new Person instance you create and to deallocate that Person instance when it’s no longer needed. 上の例で、ARCはあなたがつくる新しいPersonインスタンスへの参照の数を追跡して、そのPersonインスタンスをそれがもはや必要でないとき割り当て解除することができます。

However, it’s possible to write code in which an instance of a class never gets to a point where it has zero strong references. This can happen if two class instances hold a strong reference to each other, such that each instance keeps the other alive. This is known as a strong reference cycle. しかしながら、あるクラスのあるインスタンスが、強い参照を１つも持たない状態になることが決してないコードを書くことは、可能です。２つのクラスインスタンスが強い参照にお互いを守らせるならば、これは起こることができます、各インスタンスが他を生かしておくようなものです。これは、強い参照循環として知られています。

You resolve strong reference cycles by defining some of the relationships between classes as weak or unowned references instead of as strong references. This process is described in Resolving Strong Reference Cycles Between Class Instances. However, before you learn how to resolve a strong reference cycle, it’s useful to understand how such a cycle is caused. あなたは、クラス間の関係の一部を強い参照としてでなくて弱い、または非所有参照として定義することによって強い参照循環を解消します。この過程は、クラスインスタンス間の強い参照循環の解消で記述されます。しかし、あなたが強い参照循環を解消する方法を学ぶ前に、そのような循環がどのように引き起こされるか理解することは役に立ちます。

Here’s an example of how a strong reference cycle can be created by accident. This example defines two classes called Person and Apartment, which model a block of apartments and its residents: 強い参照循環がどのように偶然に作られることができるかの例は、ここにあります。この例はPersonとApartmentと呼ばれる２つのクラスを定義します、それは、アパートの１区画とその居住者をモデル化します：

Every Person instance has a name property of type String and an optional apartment property that’s initially nil. The apartment property is optional, because a person may not always have an apartment. あらゆるPersonインスタンスは、型Stringのnameプロパティと初期時にはnilであるオプショナルのapartmentプロパティを持ちます。人は必ずしもアパートを持つわけではないので、apartmentプロパティはオプショナルです。

Similarly, every Apartment instance has a unit property of type String and has an optional tenant property that’s initially nil. The tenant property is optional because an apartment may not always have a tenant. 同じように、あらゆるApartmentインスタンスは、型Stringのunitプロパティを持って、初期時にはnilであるオプショナルのtenantプロパティを持ちます。アパートには常に賃借人がいるわけではないので、tenant（テナント、賃借人）プロパティはオプショナルです。

Both of these classes also define a deinitializer, which prints the fact that an instance of that class is being deinitialized. This enables you to see whether instances of Person and Apartment are being deallocated as expected. これらのクラスの両方ともデイニシャライザを定義します、それは、そのクラスのインスタンスがデイニシャライズされているという事実を出力します。これは、あなたに期待されるようにPersonとApartmentのインスタンスが割り当て解除されているかどうか知ることを可能にします。

This next code snippet defines two variables of optional type called john and unit4A, which will be set to a specific Apartment and Person instance below. Both of these variables have an initial value of nil, by virtue of being optional: この次のコード断片はjohnとunit4Aと呼ばれるオプショナルの型の２つの変数を定義します、それは、特定のApartmentとPersonインスタンスに以降で設定されます。オプショナルである利点によって、これらの変数の両方とも、nilの初期値を持ちます：

You can now create a specific Person instance and Apartment instance and assign these new instances to the john and unit4A variables: あなたは、今や特定のPersonインスタンスとApartmentインスタンスを作成して、それらの新しいインスタンスをjohnおよびunit4A変数に代入することができます：

Here’s how the strong references look after creating and assigning these two instances. The john variable now has a strong reference to the new Person instance, and the unit4A variable has a strong reference to the new Apartment instance: それらの２つのインスタンスの作成と代入の後に強い参照がどのように見えるかが、ここにあります。john変数は現在新しいPersonインスタンスへの強い参照を持ちます、そしてunit4A変数は新しいApartmentインスタンスへの強い参照を持ちます：

You can now link the two instances together so that the person has an apartment, and the apartment has a tenant. Note that an exclamation point (!) is used to unwrap and access the instances stored inside the john and unit4A optional variables, so that the properties of those instances can be set: あなたは次に人がアパートを持つように、２つのインスタンスを結びつけることができます、するとアパートには賃借人があります。感嘆符（!）が使われることに注意してください、そうすることでオプショナル変数のjohnとunit4Aに格納されるインスタンスがアンラップされてアクセスされるようになります、それでそれらのインスタンスのプロパティが設定されることができます：

Here’s how the strong references look after you link the two instances together: あなたが２つのインスタンスを結びつけた後に強い参照がどのように見えるかが、ここにあります。

Unfortunately, linking these two instances creates a strong reference cycle between them. The Person instance now has a strong reference to the Apartment instance, and the Apartment instance has a strong reference to the Person instance. Therefore, when you break the strong references held by the john and unit4A variables, the reference counts don’t drop to zero, and the instances aren’t deallocated by ARC: 残念なことに、これらの２つのインスタンスを結ぶことは、それらの間で強い参照循環をつくります。Personインスタンスは現在Apartmentインスタンスへの強い参照を持ちます、そして、ApartmentインスタンスはPersonインスタンスへの強い参照を持ちます。したがって、あなたがjohnとunit4A変数によって保持される強い参照を壊すとき、参照総数はゼロに落ちません、なのでインスタンスはARCによって割り当て解除されません：

Note that neither deinitializer was called when you set these two variables to nil. The strong reference cycle prevents the Person and Apartment instances from ever being deallocated, causing a memory leak in your app. あなたがこれらの２つの変数をnilに設定したとき、どちらのデイニシャライザも呼ばれなかった点に注意してください。強い参照循環はPersonとApartmentインスタンスがともかく割り当て解除されるのを妨げます。そして、あなたのアプリのメモリリークを引き起こします。

Here’s how the strong references look after you set the john and unit4A variables to nil: あなたがjohnとunit4A変数をnilに設定したあと、強い参照がどのように見えるかは、ここにあります：

The strong references between the Person instance and the Apartment instance remain and can’t be broken. PersonインスタンスとApartmentインスタンスの間の強い参照は、残っていて、壊されることができません。

Resolving Strong Reference Cycles Between Class Instances¶ クラスインスタンス間の強い参照循環の解消¶

Swift provides two ways to resolve strong reference cycles when you work with properties of class type: weak references and unowned references. あなたがクラス型のプロパティを扱うとき、スウィフトは強い参照循環を解消する２つの道を提供します：弱い参照と非所有参照。

Weak and unowned references enable one instance in a reference cycle to refer to the other instance without keeping a strong hold on it. The instances can then refer to each other without creating a strong reference cycle. 弱いおよび非所有参照は、ある参照循環の中の１つのインスタンスに、他のインスタンスに言及することをそれに対する強い支配力を持つことなく可能にします。インスタンスは、そのあと強い参照循環をつくることなくお互いに言及することができます。

Use a weak reference when the other instance has a shorter lifetime—that is, when the other instance can be deallocated first. In the Apartment example above, it’s appropriate for an apartment to be able to have no tenant at some point in its lifetime, and so a weak reference is an appropriate way to break the reference cycle in this case. In contrast, use an unowned reference when the other instance has the same lifetime or a longer lifetime. 弱い参照を他のインスタンスがより短い生涯を持つ場合に使ってください — すなわち、他のインスタンスが最初にでアロケートされることが可能である時。上のApartment例において、あるアパートがその生涯のどこかの時点で賃借人がいないことがあるというのは妥当です、なのでこの場合は弱い参照が参照循環を壊す適切な方法です。対照的に、非所有参照を他のインスタンスが同じ生涯またはより長い生涯を持つ場合に使ってください。

Weak References¶ 弱い参照¶

A weak reference is a reference that doesn’t keep a strong hold on the instance it refers to, and so doesn’t stop ARC from disposing of the referenced instance. This behavior prevents the reference from becoming part of a strong reference cycle. You indicate a weak reference by placing the weak keyword before a property or variable declaration. 弱い参照は、それが言及するインスタンスに対する強い支配力を保たない参照です、なのでARCは参照をつけられたインスタンスを処分するのを止めません。この挙動は、参照が強い参照循環の一部になるのを妨げます。あなたは、プロパティまたは変数の宣言の前にweakキーワードを置くことによって弱い参照を示します。

Because a weak reference doesn’t keep a strong hold on the instance it refers to, it’s possible for that instance to be deallocated while the weak reference is still referring to it. Therefore, ARC automatically sets a weak reference to nil when the instance that it refers to is deallocated. And, because weak references need to allow their value to be changed to nil at runtime, they’re always declared as variables, rather than constants, of an optional type. 弱い参照がそれが言及するインスタンスに対する強い支配力を保たないので、弱い参照がまだそれに言及している間にそのインスタンスが割り当て解除されることは可能です。したがって、ARCは自動的に、弱い参照をそれが言及するインスタンスが割り当て解除されるときnilに設定します。そしてまた、弱い参照はそれらの値を実行時にnilに変更されるのを許される必要があることから、それらは常にオプショナル型の変数として宣言されます、定数ではなく。

You can check for the existence of a value in the weak reference, just like any other optional value, and you will never end up with a reference to an invalid instance that no longer exists. 他のあらゆるオプショナルの値と同じように、あなたは弱い参照の中の値の存在について調べることができます、そして、あなたは既に存在しない無効なインスタンスへの参照に至ることは決してありません。

Note 注意

Property observers aren’t called when ARC sets a weak reference to nil. プロパティオブザーバーは、ARCが弱い参照をnilに設定するとき呼び出されません。

The example below is identical to the Person and Apartment example from above, with one important difference. This time around, the Apartment type’s tenant property is declared as a weak reference: 下の例は、上記のPersonとApartment例に同一ですが、１つの重要な違いがあります。今度は、Apartment型のtenantプロパティは、弱い参照として宣言されます：

1. class Person {
2. let name: String
3. init(name: String) { self.name = name }
4. var apartment: Apartment?
5. deinit { print("\(name) is being deinitialized") }
6. }
8. class Apartment {
9. let unit: String
10. init(unit: String) { self.unit = unit }
11. weak var tenant: Person?
12. deinit { print("Apartment \(unit) is being deinitialized") }
13. }

The strong references from the two variables (john and unit4A) and the links between the two instances are created as before: ２つの変数（johnとunit4A）からの強い参照と２つのインスタンスの繋がりは、前の通り作成されます：

1. var john: Person?
2. var unit4A: Apartment?
4. john = Person(name: "John Appleseed")
5. unit4A = Apartment(unit: "4A")
7. john!.apartment = unit4A
8. unit4A!.tenant = john

Here’s how the references look now that you’ve linked the two instances together: あなたが２つのインスタンスを結びつけた今、参照がどのように見えるかは、ここにあります：

The Person instance still has a strong reference to the Apartment instance, but the Apartment instance now has a weak reference to the Person instance. This means that when you break the strong reference held by the john variable by setting it to nil, there are no more strong references to the Person instance: Personインスタンスは依然としてApartmentインスタンスへの強い参照を持ちます、しかし、Apartmentインスタンスは現在はPersonインスタンスへの弱い参照を持ちます。これは、あなたがjohn変数によって保持される強い参照を、それをnilに設定することによって壊すとき、Personインスタンスへの強い参照がもうそれ以上ないことを意味します：

1. john = nil
2. // Prints "John Appleseed is being deinitialized"（「John Appleseedは、デイニシャライズされた」を出力します）

Because there are no more strong references to the Person instance, it’s deallocated and the tenant property is set to nil: もうこれ以上Personインスタンスへの強い参照はないことから、それは割り当て解除されます、そしてtenant特性はnilに設定されます：

The only remaining strong reference to the Apartment instance is from the unit4A variable. If you break that strong reference, there are no more strong references to the Apartment instance: Apartmentインスタンスへの唯一の残っている強い参照は、unit4A変数からです。あなたがその強い参照を壊すならば、Apartmentインスタンスへの強い参照はもうこれ以上ありません：

1. unit4A = nil
2. // Prints "Apartment 4A is being deinitialized"（「アパート4Aは、デイニシャライズされた」を出力します）

Because there are no more strong references to the Apartment instance, it too is deallocated: Apartmentインスタンスへの強い参照はもうこれ以上ないので、それも割り当て解除されます：

Note 注意

In systems that use garbage collection, weak pointers are sometimes used to implement a simple caching mechanism because objects with no strong references are deallocated only when memory pressure triggers garbage collection. However, with ARC, values are deallocated as soon as their last strong reference is removed, making weak references unsuitable for such a purpose. ガベージコレクションを使うシステムにおいて、時おり弱いポインタが簡単なキャッシュの仕組みを実装するために使われます、なぜなら強い参照を持たないオブジェクトは、メモリの逼迫がガベージコレクションを引き起こす時のみに割り当て解除されるためです。しかしながら、ARCでは、値はその最後の強い参照が削除されるやいなや割り当て解除されて、弱い参照をそのような目的のためにふさわしくないものにします。

Unowned References¶ 非所有参照¶

Like a weak reference, an unowned reference doesn’t keep a strong hold on the instance it refers to. Unlike a weak reference, however, an unowned reference is used when the other instance has the same lifetime or a longer lifetime. You indicate an unowned reference by placing the unowned keyword before a property or variable declaration. 弱い参照のように、非所有参照は、それが言及するインスタンスに対する強い支配力を保ちません。しかしながら、弱い参照とは違い、非所有参照は他のインスタンスが同じ生涯またはより長い生涯を持つ場合に使われます。あなたは、プロパティまたは変数の宣言の前にunownedキーワードを置くことによって非所有参照を示します。

Unlike a weak reference, an unowned reference is expected to always have a value. As a result, marking a value as unowned doesn’t make it optional, and ARC never sets an unowned reference’s value to nil. 弱い参照とは違い、非所有参照は常に値を持つと期待されます。結果として、ある値を非所有と印することは、それをオプショナルにしません、そしてARCは決して非所有参照のもつ値をnilに設定しません。

Important 重要

Use an unowned reference only when you are sure that the reference always refers to an instance that hasn’t been deallocated. 非所有参照を、その参照が常にデアロケートされていないインスタンスに言及するとあなたが確信する時にだけ使用してください。

If you try to access the value of an unowned reference after that instance has been deallocated, you’ll get a runtime error. あなたがある非所有参照の値に、そのインスタンスがデアロケートされてしまった後にアクセスしようとするならば、あなたは実行時エラーを得るでしょう。

The following example defines two classes, Customer and CreditCard, which model a bank customer and a possible credit card for that customer. These two classes each store an instance of the other class as a property. This relationship has the potential to create a strong reference cycle. 以下の例は２つのクラス、CustomerとCreditCardを定義します、それは、銀行顧客とその顧客のために可能なクレジットカードをモデル化します。これらの２つのクラスは、それぞれ他のクラスのインスタンスをプロパティとして格納します。この関係は、強い参照循環をつくる可能性を持ちます。

The relationship between Customer and CreditCard is slightly different from the relationship between Apartment and Person seen in the weak reference example above. In this data model, a customer may or may not have a credit card, but a credit card will always be associated with a customer. A CreditCard instance never outlives the Customer that it refers to. To represent this, the Customer class has an optional card property, but the CreditCard class has an unowned (and non-optional) customer property. CustomerとCreditCardの関係は、上の弱い参照の例で見られるApartmentとPersonの関係と少しばかり異なります。このデータ・モデルにおいて、顧客はクレジットカードを持っているかもしれないし、持っていないかもしれません、しかし、クレジットカードは常にひとりの顧客と結び付けられます。CreditCardインスタンスは、それが参照するCustomerより決して長生きしません。これを表すために、Customerクラスはオプショナルのcardプロパティを持ちます、しかし、CreditCardクラスは非所有（そして非オプショナル）のcustomerプロパティを持ちます。

Furthermore, a new CreditCard instance can only be created by passing a number value and a customer instance to a custom CreditCard initializer. This ensures that a CreditCard instance always has a customer instance associated with it when the CreditCard instance is created. さらに、新しいCreditCardインスタンスは、number値とcustomerインスタンスをあつらえのCreditCardイニシャライザに渡すことによってのみ作成されることができます。これは、CreditCardインスタンスがつくられるとき、CreditCardインスタンスが常にそれと結びつけられるCustomerインスタンスを持つことを確実にします。

Because a credit card will always have a customer, you define its customer property as an unowned reference, to avoid a strong reference cycle: クレジットカードが常にひとりの顧客を持つので、強い参照循環を避けるために、あなたはそのcustomerプロパティを非所有参照として定義します：

1. class Customer {
2. let name: String
3. var card: CreditCard?
4. init(name: String) {
5. self.name = name
6. }
7. deinit { print("\(name) is being deinitialized") }
8. }
10. class CreditCard {
11. let number: UInt64
12. unowned let customer: Customer
13. init(number: UInt64, customer: Customer) {
14. self.number = number
15. self.customer = customer
16. }
17. deinit { print("Card #\(number) is being deinitialized") }
18. }

Note 注意

The number property of the CreditCard class is defined with a type of UInt64 rather than Int, to ensure that the number property’s capacity is large enough to store a 16-digit card number on both 32-bit and 64-bit systems. CreditCardクラスのnumberプロパティは、UInt64の型で定義されます、Intではなく、それによってnumberプロパティの容量が32bitと64bitシステムの両方で16桁のカード番号を格納するのに十分に大きいことを保証します。

This next code snippet defines an optional Customer variable called john, which will be used to store a reference to a specific customer. This variable has an initial value of nil, by virtue of being optional: 次のコード断片は、johnと呼ばれる、オプショナルのCustomer変数を定義します。それは、特定の顧客への参照を格納するために使われます。オプショナルであるおかげで、この変数はnilの初期値を持ちます：

1. var john: Customer?

You can now create a Customer instance, and use it to initialize and assign a new CreditCard instance as that customer’s card property: あなたは、現在Customerインスタンスを作成して、それを使って、新しいCreditCardインスタンスを、その顧客のcardプロパティとして初期化して代入することができます：

1. john = Customer(name: "John Appleseed")
2. john!.card = CreditCard(number: 1234_5678_9012_3456, customer: john!)

Here’s how the references look, now that you’ve linked the two instances: あなたが２つのインスタンスを結んだ今、これらの参照がどのように見えるかは、ここにあります：

The Customer instance now has a strong reference to the CreditCard instance, and the CreditCard instance has an unowned reference to the Customer instance. Customerインスタンスは現在CreditCardインスタンスへの強い参照を持ちます、そして、CreditCardインスタンスはCustomerインスタンスへの非所有参照を持ちます。

Because of the unowned customer reference, when you break the strong reference held by the john variable, there are no more strong references to the Customer instance: 非所有customer参照であることから、あなたがjohn変数によって保持される強い参照を壊すとき、Customerインスタンスへの強い参照はもうそれ以上ありません：

Because there are no more strong references to the Customer instance, it’s deallocated. After this happens, there are no more strong references to the CreditCard instance, and it too is deallocated: Customerインスタンスへの強い参照はもうないので、それは割り当て解除されます。これが起こったあと、CreditCardインスタンスへの強い参照はもうありません、そして、それも割り当て解除されます：

1. john = nil
2. // Prints "John Appleseed is being deinitialized"（「John Appleseedは、デイニシャライズされた」を出力します）
3. // Prints "Card #1234567890123456 is being deinitialized"（「カード#1234567890123456は、デイニシャライズされた」を出力します）

The final code snippet above shows that the deinitializers for the Customer instance and CreditCard instance both print their “deinitialized” messages after the john variable is set to nil. 上の最後のコード断片は、CustomerインスタンスとCreditCardインスタンスのためのデイニシャライザが両方ともそれらの「デイニシャライズされた」メッセージを、john変数がnilに設定された後に出力することを示します。

Note 注意

The examples above show how to use safe unowned references. Swift also provides unsafe unowned references for cases where you need to disable runtime safety checks—for example, for performance reasons. As with all unsafe operations, you take on the responsibility for checking that code for safety. 上の例は、どのようにsafe非所有参照を使うかを示します。スウィフトはまたunsafe非所有参照を、あなたが実行時安全確認を無効にする必要がある場合のために提供します — 例えば、性能上の理由のために。すべての安全でない操作と同様に、あなたはコードの安全について検査する責任を持つようになります。

You indicate an unsafe unowned reference by writing unowned(unsafe). If you try to access an unsafe unowned reference after the instance that it refers to is deallocated, your program will try to access the memory location where the instance used to be, which is an unsafe operation. あなたは、安全でない非所有参照をunowned(unsafe)を書くことによって指し示します。あなたが安全でない非所有参照に、それが参照するインスタンスがデアロケートされてしまった後にアクセスすることを試みるならば、あなたのプログラムはそのインスタンスが存在するのに使われたところの位置でメモリにアクセスしようと試みるでしょう、それはメモリ安全ではない操作です。

Unowned Optional References¶ 非所有オプショナル参照¶

You can mark an optional reference to a class as unowned. In terms of the ARC ownership model, an unowned optional reference and a weak reference can both be used in the same contexts. The difference is that when you use an unowned optional reference, you’re responsible for making sure it always refers to a valid object or is set to nil. あなたは、あるクラスへのオプショナル参照を非所有として印できます。ARC所有権モデルの観点では、非所有オプショナル参照と弱い参照は両方とも同じ文脈で使用できます。違いは、あなたが非所有オプショナル参照を使う場合、あなたはそれが有効なオブジェクトを常に参照するまたはnilに設定されるのを確実にする責任があることです。

Here’s an example that keeps track of the courses offered by a particular department at a school: ここに例があります、それはある学校でのある特定の学科（Department）によって提供される課程（Course）それらの情報を得続けます。

1. class Department {
2. var name: String
3. var courses: [Course]
4. init(name: String) {
5. self.name = name
6. self.courses = []
7. }
8. }
10. class Course {
11. var name: String
12. unowned var department: Department
13. unowned var nextCourse: Course?
14. init(name: String, in department: Department) {
15. self.name = name
16. self.department = department
17. self.nextCourse = nil
18. }
19. }

Department maintains a strong reference to each course that the department offers. In the ARC ownership model, a department owns its courses. Course has two unowned references, one to the department and one to the next course a student should take; a course doesn’t own either of these objects. Every course is part of some department so the department property isn’t an optional. However, because some courses don’t have a recommended follow-on course, the nextCourse property is an optional. Department（学科）は、ある強い参照をその学科が提供する課程それぞれに対して保守します。ARC所有権モデルにおいて、ある学科はそれの課程それらを所有します。Course（課程）は２つの非所有参照を持ちます、学科に対して１つそして生徒が取るべき次の課程に対して１つ；ある課程はこれらオブジェクトのどちらも所有しません。あらゆる課程は、なんらかの学科の一部です、なのでdepartmentプロパティはオプショナルではありません。しかしながら、いくつかの課程は推奨される後続の課程を持たないことから、nextCourseプロパティはオプショナルです。

Here’s an example of using these classes: ここにこれらクラスを使う例があります：

1. let department = Department(name: "Horticulture")
3. let intro = Course(name: "Survey of Plants", in: department)
4. let intermediate = Course(name: "Growing Common Herbs", in: department)
5. let advanced = Course(name: "Caring for Tropical Plants", in: department)
7. intro.nextCourse = intermediate
8. intermediate.nextCourse = advanced
9. department.courses = [intro, intermediate, advanced]

The code above creates a department and its three courses. The intro and intermediate courses both have a suggested next course stored in their nextCourse property, which maintains an unowned optional reference to the course a student should take after completing this one. 上のコードは、ある学科とそれの３つの課程を作成します。入門と中級の課程の両方とも、それらのnextCourseプロパティの中に格納される提案される次の課程を持ちます、それは生徒がそれを修了した後に取るべき課程への非所有オプショナル参照を保守します。

An unowned optional reference doesn’t keep a strong hold on the instance of the class that it wraps, and so it doesn’t prevent ARC from deallocating the instance. It behaves the same as an unowned reference does under ARC, except that an unowned optional reference can be nil. 非所有オプショナル参照は、強い保持をそれがラップするクラスのインスタンス上で持ち続けません、それゆえそれはARCがインスタンスをデアロケートするのを妨げません。それは非所有参照がARCの下でするのと同じに振る舞います、非所有オプショナル参照がnilであることが可能である以外は。

Like non-optional unowned references, you’re responsible for ensuring that nextCourse always refers to a course that hasn’t been deallocated. In this case, for example, when you delete a course from department.courses you also need to remove any references to it that other courses might have. 非オプショナル非所有参照のように、あなたはnextCourseが常にあるデアロケートされていない課程を参照することを確実にする責任があります。この場合には、例えば、あなたがある課程をdepartment.coursesから削除する場合はあなたはまた他の課程が持つかもしれないそれへのあらゆる参照を取り除く必要があります。

Note 注意

The underlying type of an optional value is Optional, which is an enumeration in the Swift standard library. However, optionals are an exception to the rule that value types can’t be marked with unowned. あるオプショナル値の基礎をなす型は、Optionalです、それはSwift標準ライブラリにおけるある列挙です。しかしながら、オプショナルそれらは、値型はunownedで印されることが出来ないという規則に対するひとつの例外です

The optional that wraps the class doesn’t use reference counting, so you don’t need to maintain a strong reference to the optional. クラスをラップするオプショナルは、参照カウントを使用しません、それであなたはオプショナルへの強い参照を保守する必要はありません。

Strong Reference Cycles for Closures¶ クロージャのための強い参照循環¶

You saw above how a strong reference cycle can be created when two class instance properties hold a strong reference to each other. You also saw how to use weak and unowned references to break these strong reference cycles. あなたは上で、２つのクラスインスタンスプロパティが強い参照にお互いを守らせるとき、どのように強い参照循環がつくられることができるかを見ました。あなたはまた、これらの強い参照循環を壊すために弱いおよび非所有参照を使う方法を見ました。

A strong reference cycle can also occur if you assign a closure to a property of a class instance, and the body of that closure captures the instance. This capture might occur because the closure’s body accesses a property of the instance, such as self.someProperty, or because the closure calls a method on the instance, such as self.someMethod(). In either case, these accesses cause the closure to “capture” self, creating a strong reference cycle. 強い参照循環はまた、あなたがあるクロージャをクラスインスタンスのプロパティに代入して、そのクロージャの本文がそのインスタンスを捕獲するならば、起こることができます。この捕獲は、例えばself.somePropertyのようにクロージャの本文がインスタンスのプロパティにアクセスするために、または例えばself.someMethod()のようにクロージャがインスタンスのメソッドを呼ぶために起こるかもしれません。いずれにせよ、これらのアクセスは、クロージャが強い参照循環をつくってselfを「捕獲する」ことを引き起こします。

This strong reference cycle occurs because closures, like classes, are reference types. When you assign a closure to a property, you are assigning a reference to that closure. In essence, it’s the same problem as above—two strong references are keeping each other alive. However, rather than two class instances, this time it’s a class instance and a closure that are keeping each other alive. この強い参照循環は、クロージャが、クラスの様に参照型であるために起こります。あなたがクロージャをプロパティに代入するとき、あなたは参照をそのクロージャに代入しています。本質において、それは上記と同じ問題です ― ２つの強い参照が、お互いを生かし続けています。しかし２つのクラスインスタンスではなく、今度は、それはお互いを生かし続けているクラスインスタンスとクロージャです。

Swift provides an elegant solution to this problem, known as a closure capture list. However, before you learn how to break a strong reference cycle with a closure capture list, it’s useful to understand how such a cycle can be caused. スウィフトはこの問題の洗練された解答、クロージャ捕獲リストとして知られるものを提供します。しかし、あなたがクロージャ捕獲リストで強い参照循環を壊す方法を学ぶ前に、そのような循環がどのように引き起こされることがありえるか理解することは役に立ちます。

The example below shows how you can create a strong reference cycle when using a closure that references self. This example defines a class called HTMLElement, which provides a simple model for an individual element within an HTML document: 下の例は、selfに参照をつけるクロージャを使うとき、あなたがどのように強い参照循環をつくることができるかについて示します。この例はHTMLElementと呼ばれるクラスを定義します、それは、HTML文書内個々の要素に対する単純なモデルを用意します：

The HTMLElement class defines a name property, which indicates the name of the element, such as "h1" for a heading element, "p" for a paragraph element, or "br" for a line break element. HTMLElement also defines an optional text property, which you can set to a string that represents the text to be rendered within that HTML element. HTMLElementクラスはnameプロパティを定義します、それは、要素の名前を示します、例えばヘッダ要素の"h1"、段落要素のための"p"、またはあるいは、改行のための"br"要素など。HTMLElementはまた、オプショナルのtextプロパティを定義します、それは、あなたはそれをテキストがそのHTML要素の範囲内で提出されると述べる文字列に設定することができます。

In addition to these two simple properties, the HTMLElement class defines a lazy property called asHTML. This property references a closure that combines name and text into an HTML string fragment. The asHTML property is of type () -> String, or “a function that takes no parameters, and returns a String value”. これらの２つの単純なプロパティに加えて、HTMLElementクラスは、asHTMLと呼ばれる遅延プロパティを定義します。このプロパティは、nameとtextをHTML文字列断片に結合するクロージャに参照をつけます。asHTMLプロパティは型() -> Stringです、あるいは「パラメータをとらなくて、String値を返す関数」。

By default, the asHTML property is assigned a closure that returns a string representation of an HTML tag. This tag contains the optional text value if it exists, or no text content if text doesn’t exist. For a paragraph element, the closure would return "<p>some text</p>" or "<p />", depending on whether the text property equals "some text" or nil. 特に何もしなければ、asHTMLプロパティは、あるHTMLタグの文字列表現を返すクロージャを代入されます。このタグは、それが存在するならばオプショナルのtext値を、あるいはtextが存在しないならば、無いテキスト内容を含みます。段落要素のために、このクロージャは、"<p>some text</p>"または"<p />"を返します、textプロパティが"some text"に等しいまたはnilかどうかに従って。

The asHTML property is named and used somewhat like an instance method. However, because asHTML is a closure property rather than an instance method, you can replace the default value of the asHTML property with a custom closure, if you want to change the HTML rendering for a particular HTML element. asHTMLプロパティは、いくぶんインスタンスメソッドのように名前をつけられて、使われます。しかし、asHTMLはインスタンスメソッドではなくクロージャプロパティであるので、あなたが特定のHTML要素に対してHTML解釈を変更したいならば、あなたはあつらえのクロージャでasHTMLプロパティの省略時の値を置き替えることができます。

For example, the asHTML property could be set to a closure that defaults to some text if the text property is nil, in order to prevent the representation from returning an empty HTML tag: 例えば、asHTMLプロパティは、あるクロージャに設定されることができます、それはtextプロパティがnilならば特に何もしなくともいくらかのテキストになり、その表現が空のHTMLタグを返すことを予防する手段となります。

The HTMLElement class provides a single initializer, which takes a name argument and (if desired) a text argument to initialize a new element. The class also defines a deinitializer, which prints a message to show when an HTMLElement instance is deallocated. HTMLElementクラスは１つのイニシャライザを提供します、それは、name引数と（希望する場合には）text引数をとって新しい要素を初期化します。クラスもデイニシャライザを定義します、それは、HTMLElementインスタンスが割り当て解除される場合に示すメッセージを出力します。

Here’s how you use the HTMLElement class to create and print a new instance: あなたが新しいインスタンスを作成して出力するためにHTMLElementクラスを使用する方法は、ここにあります：

Unfortunately, the HTMLElement class, as written above, creates a strong reference cycle between an HTMLElement instance and the closure used for its default asHTML value. Here’s how the cycle looks: 残念なことに、このHTMLElementクラスは、上で書かれるように、HTMLElementインスタンスとその省略時のasHTML値のために使われるクロージャとの間に強い参照循環をつくります。循環がどのように見えるかは、ここにあります：

The instance’s asHTML property holds a strong reference to its closure. However, because the closure refers to self within its body (as a way to reference self.name and self.text), the closure captures self, which means that it holds a strong reference back to the HTMLElement instance. A strong reference cycle is created between the two. (For more information about capturing values in a closure, see Capturing Values.) このインスタンスのasHTMLプロパティは、それのクロージャに対する強い参照を保持します。しかし、クロージャがその本文内でselfに言及する（self.nameとself.textを参照する方法として）ので、クロージャはselfを捕獲します、それは、今度は逆にそれがHTMLElementインスタンスへの強い参照を保持することを意味します。強い参照循環は、２つ作られます。（クロージャにおいて値を捕獲することに関する詳細は、値を捕獲するを見てください。）

If you set the paragraph variable to nil and break its strong reference to the HTMLElement instance, neither the HTMLElement instance nor its closure are deallocated, because of the strong reference cycle: あなたがparagraph変数をnilに設定して、HTMLElementへのそれの強い参照を壊すならば、HTMLElementインスタンスもそれのクロージャも割り当て解除されません、強い参照循環のためです：

Note that the message in the HTMLElement deinitializer isn’t printed, which shows that the HTMLElement instance isn’t deallocated. HTMLElementデイニシャライザにおけるメッセージが出力されないことに注意してください、それは、HTMLElementインスタンスが割り当て解除されないことを示します。

Resolving Strong Reference Cycles for Closures¶ クロージャのための強い参照循環の解消¶

You resolve a strong reference cycle between a closure and a class instance by defining a capture list as part of the closure’s definition. A capture list defines the rules to use when capturing one or more reference types within the closure’s body. As with strong reference cycles between two class instances, you declare each captured reference to be a weak or unowned reference rather than a strong reference. The appropriate choice of weak or unowned depends on the relationships between the different parts of your code. あなたは、クロージャの定義の一部として捕獲リストを定義することによってクロージャとクラスインスタンスの間で強い参照循環を解消します。捕獲リストは、クロージャの本文内で１つ以上の参照型を捕獲するとき使用する規則を定義します。２つのクラスインスタンスの間の強い参照循環と同様に、あなたは各捕らえられた参照が強い参照というよりは弱いまたは非所有参照であると宣言します。弱いまたは非所有の適切な選択は、あなたのコードの異なる部分間の関係に依存します。

Weak and Unowned References¶ 弱いおよび非所有参照¶

Define a capture in a closure as an unowned reference when the closure and the instance it captures will always refer to each other, and will always be deallocated at the same time. 捕獲をクロージャにおいて非所有参照として定義してください、クロージャとそれが捕らえるインスタンスが常に互いに言及する、そして常に同時に割り当て解除される時は。

Conversely, define a capture as a weak reference when the captured reference may become nil at some point in the future. Weak references are always of an optional type, and automatically become nil when the instance they reference is deallocated. This enables you to check for their existence within the closure’s body. 逆に、捕らえられた参照が将来どこかの時点でnilになるかもしれないときは、捕獲を弱い参照として定義してください。弱い参照は常にオプショナルの型です、そしてそれが参照をつけるインスタンスが割り当て解除されるとき、自動的にnilになります。これはあなたに、クロージャの本文内でそれらの存在について調べることを可能にします。

Note 注意

If the captured reference will never become nil, it should always be captured as an unowned reference, rather than a weak reference. 捕獲された参照が決してnilにならないならば、それは常に、非所有参照として捕らえられなければなりません、弱い参照ではなくて。

An unowned reference is the appropriate capture method to use to resolve the strong reference cycle in the HTMLElement example from Strong Reference Cycles for Closures above. Here’s how you write the HTMLElement class to avoid the cycle: 非所有参照は、上のクロージャのための強い参照循環のHTMLElement例での強い参照循環を解消するのために使うのに適切な捕獲の手法です。ここに、あなたがHTMLElementクラスを循環を避けるように書く方法があります：

1. class HTMLElement {
3. let name: String
4. let text: String?
6. lazy var asHTML: () -> String = {
7. [unowned self] in
8. if let text = self.text {
9. return "<\(self.name)>\(text)</\(self.name)>"
10. } else {
11. return "<\(self.name) />"
12. }
13. }
15. init(name: String, text: String? = nil) {
16. self.name = name
17. self.text = text
18. }
20. deinit {
21. print("\(name) is being deinitialized")
22. }
24. }

This implementation of HTMLElement is identical to the previous implementation, apart from the addition of a capture list within the asHTML closure. In this case, the capture list is [unowned self], which means “capture self as an unowned reference rather than a strong reference”. HTMLElementのこの実装は、asHTMLクロージャ内の捕獲リストの追加は別として、前の実装と同一です。この場合、捕獲リストは[unowned self]です、それは、「selfを強い参照ではなく非所有参照として捕獲する」ことを意味します。

You can create and print an HTMLElement instance as before: あなたは、HTMLElementインスタンスを前の通り作成して出力することができます：

1. var paragraph: HTMLElement? = HTMLElement(name: "p", text: "hello, world")
2. print(paragraph!.asHTML())
3. // Prints "<p>hello, world</p>"（「<p>よろしく、世界</p>」を出力します）

Here’s how the references look with the capture list in place: 捕獲リストで適切にされた参照がどのように見えるかは、ここにあります：

This time, the capture of self by the closure is an unowned reference, and doesn’t keep a strong hold on the HTMLElement instance it has captured. If you set the strong reference from the paragraph variable to nil, the HTMLElement instance is deallocated, as can be seen from the printing of its deinitializer message in the example below: 今度は、クロージャによるselfの捕獲は非所有参照であって、それが捕獲しているHTMLElementインスタンスに対する強い支配力を保ちません。あなたが強い参照であるparagraph変数をnilに設定するならば、そのHTMLElementインスタンスは、下の例におけるそれのデイニシャライザのメッセージの出力から分かるように、割り当て解除されます：

1. paragraph = nil
2. // Prints "p is being deinitialized"（「pは、デイニシャライズされている」を出力します）

For more information about capture lists, see Capture Lists. キャプチャリストについての更なる情報として、キャプチャリストを見てください。