https://www.youtube.com/watch?v=03wl8gyziS8
今回から、毎週月水金のペースで Swift 言語仕様の基礎的なところを、Apple 公式の解説書 The Swift Programming Languagte に沿ってじっくり眺めていく勉強会の始まりです。
せっかくたくさん開催できる機会があるので、Swift のひとつに着目して全体的な視野から広く深く見ていけたらいいなと思っていますけれど、それに先立って、みんなで一緒に学びを深めていくにあたって、初回はこの会の方向性などを共有するオリエンテーション回にしてみようと思います。よろしくお願いいたしますね。
——————————————————————————————— 熊谷さんのやさしい Swift 勉強会 #1
00:00:00 開始 00:00:07 オリエンテーション 00:00:15 自己紹介 00:00:58 この勉強会を始めるにあたって 00:01:45 目的 00:03:17 やさしい Swift 勉強会 00:04:10 対象者 00:05:22 方向性 00:07:04 談笑形式 00:10:16 心持ち 00:12:35 心構え 00:14:08 質疑応答 00:15:09 フリートーク 00:16:48 言語仕様に興味のある人 00:18:12 扱う題材 00:18:59 最適化 00:21:04 LLVM での最適化 00:22:35 リリースビルドでの最適化 00:25:01 nil を除外してループを回す 00:26:54 Copy-On-Write 00:30:27 Copy-On-Write とマルチスレッド 00:36:59 値渡しとバッファー参照 00:44:28 談笑タイム（クールダウン） 00:47:05 バッファーがクラスで作られていることについて 00:53:49 受け取った配列をさらに渡すと 00:56:35 アロケーション 01:00:57 動的配列と静的配列 01:04:52 同じ言葉でも言語によって意味が違うことも 01:07:52 次回以降の予定 ———————————————————————————————
Transcription & Summarize : 熊谷さんのやさしい Swift 勉強会 #1
では、始めましょう。
まず、軽く自己紹介をさせていただきます。熊谷と申します。簡単な略歴ですが、2014年9月頃から日本各地で勉強会を開催したり、2016年8月からネットラジオを3年間ほどやっていました。また、2016年12月末頃からは技術同人誌の執筆を始めました。この前にも少し商業誌を書いたことがありましたが、本格的に執筆活動を始めたのはこれが最初です。執筆会もやってみました。
今回の勉強会を始めるにあたって、少しお話ししたいと思います。実はこの勉強会、急に昨日、今日から始めることになりました。今回は顔合わせを兼ねて、これからどんなことをやっていこうかというところがまだ定まっていません。なので、皆さんと一緒に作り上げていけたらいいなと思っています。
この会の目的について少しお話しします。プログラミング言語の基礎学力を養うことを目的にしようと思っています。国語国文学のような感じで、あまり華やかではないかもしれませんが、実務においても意味があることです。難しいコードを書く際に役立つことも多いので、基礎は大切です。文化系の習い事のような気持ちでじっくりとやっていきたいと思っています。
この勉強会を通して、プログラミング言語というものに意識を向けるきっかけになればと思います。また、プログラミング言語に向き合うことで、各自が自分の力で考えていく力を養うことにもつながればいいなという願いを込めています。
この勉強会の題名もいただいたので、それで進めていこうと思います。スパルタ的な回ではないので、優しく基礎を学ぶ場として続けていこうと思います。
対象としては、アソシエイトエンジニアやジュニアエンジニアを意識しつつ、Swift言語に携わるプログラマーならばどなたでも歓迎です。ハイレベルな方も基礎の話から新たな発見があるかもしれませんので、ぜひ参加してもらえると嬉しいです。Swiftに興味を持ってくれればどんな言語の人でも、どんな分野の人でも大歓迎です。
勉強会の方向性としては、Swiftの基本的な事柄に着目し、そこからSwift全体を広く見渡していくイメージで進めていこうと思います。一つのことから全体を見ることで、何度も同じことを繰り返し学ぶことで知識として馴染んでいくと考えています。
自分が開いてきた「みんなでSwift復習会」などに参加された方なら、同じような感じだと思っていただければ大丈夫です。今のところ3回開催を予定しているので、月1回の勉強会よりはじっくりと時間をかけて進めていきたいと思っています。
この勉強会の大事なところは談笑形式です。皆さんと集まって話をしながら勉強していきたいと思っていますので、いつでも質問やコメントをしてください。今でも大丈夫です。適当に空気を作りましょう。話しかけやすい雰囲気にしていかないと誰もしゃべりませんので、適当に話しかけてください。それでは始めましょう。 まだオンラインでこういうスタイルの勉強会をやったことがないので、どのように成り立っていくのか分からない部分もあります。システム的には例えば電話のシステムだと、誰かが話しているときには待機節約のために相手側の声を削るとかしますよね。Zoomがどうなっているのかは分かりませんが、もしシステムの都合で話しかけたけれどもこちらの音声が届かないというようなことがあれば、しつこく言ってください。聞こえてきたら話すのをやめますので、そんな感じでいろいろと探り探りやっていこうと思います。
最初しゃべりづらい方は、チャットでつぶやいていただければ、しーさんや私が拾ったりしますので、いつでも話しかけてくれて大丈夫です。一応、自分の中では話しかけるのが苦手な人は聞いているだけでも良いと思っています。ただ、こういうところで交流するのも学習の一環だと捉えているなら、できるだけ積極的に話して交流を盛んにする方法は模索してもらっていいです。
そんな感じでやっていこうと思います。話すのが苦手な人は、チャットで試してみたり、様子を伺ってみたりするのも良いでしょう。試し試しでいろいろやってみてもらえたらいいかなと思います。そのうち、話しかける方が楽だと感じると思います。ぜひよろしくお願いします。
さて、こうやって「話しかけてオッケー」と言っても、いざ話しかけるとなると難しいと感じることもあるかと思います。そういった場合は、以下の3つの心持ちを持っていただければ、話しかけやすくなるのではないかと思います。
まず、どんなに詳しそうな人でも、ほんの些細なことを知らないことが普通にあります。ですので、これぐらい誰でも知っているよねと思って話しかけないのはもったいないです。仮にそれを知っている人でも、知っていることを聞くことで視野が広がることもあります。ですので、これぐらい知っているだろうからといって話すのをやめる必要はありません。
次に、技術の話ではありがちですが、その情報が確かなのか、証拠があるのか、ソースはあるのかといったことは今回は気にしなくて大丈夫です。そういったことは話していく中で見つかっていくもので、確認すればいいものですし、そもそも正解がないことも往々にしてあります。したがって、証拠を探していると話しかけるタイミングを逃してしまうので、なんとなくこう思うんだよねといった話も大歓迎です。
最後に、技術の場で誰かが間違ったことを言ったとしても、それは相手を騙すためではないという心持ちが大事です。聞く側としては、その人にとっては正しいと思って言っていることを忘れずに、尊重して受け取ることが大事だと思います。業務の中ではうまくいかないこともあるかもしれませんが、学習の場ではみんなの意見が正しいという前提で話していくことが欠かせない心がけです。
特にアソシエイトエンジニアの方々には、この点を忘れずに持っていてほしいと思います。こんな感じのスタイルでこの勉強会をやっていこうと思いますので、どうぞよろしくお願いします。
ここまでで何か質問や意見があれば、どんどん言ってください。とてもいいスタートが切れている予感がします。ありがとうございます。心構えを心に留めておいてもらえれば、あとはゆるく進めていけるのではないかと思います。あまり緊張せずに、楽しくいけたらいいですね。
ここから1時間の枠となりますが、あと30分ちょっとありますので、せっかくの最初の回として、俗に言うアイスブレイクや顔合わせをしましょう。SWIFTに関わることやそれ以外のことなど、いろいろと話しましょう。今、自分の画面には1,2,3,4,5人のリストが表示されていますが、もっとたくさんの方がいらっしゃるようですね。合計で27人も参加しています。Zoomでピックアップされている方々には結構ベテランの方もいらっしゃいますね。
この中で、SWIFT言語の仕様そのものに興味がある方はどれぐらいいらっしゃるのでしょうか。山田さとひさん、よく存じ上げております。意外と興味がある方が多いようですね。 世間で話題に上がるのって、もっと実用的で即効性のあるものが多いですよね。ただ、意外とSwiftの言語仕様についても興味を持つ方がいらっしゃるんです。こういった勉強会は仲間探しとしても役立つと思いますよ。
仲間だと思ったら、ぜひ熊谷さんのSlarkチャンネルに参加してください。そこで自由に会話していただいて大丈夫です。
それでは、Swiftの基本について話しましょう。この会では、題材としてApple公式の「The Swift Programming Language」を軸に、一つ一つ見ていこうと思います。この本は誰でも簡単に見ることができ、個人的にも非常におすすめです。
何かSwiftで分からないことや、つっかかることがありましたら、ぜひ教えてください。なかなかすぐに思いつく人は少ないかもしれませんが、日々の中で困っていることはあるかもしれません。
少し深い話になりますが、コードの最適化がどのようにされるか不明確な点があります。自分が書いたコードが最適化されてしまうと、どう書けばいいか迷うことがあります。
そうですね、その話題はLLVMやSwiftコンパイラ（swiftc）に詳しい人の分野かもしれません。ただ、例えばLLVMはかなり強力な最適化をします。例えば、ソースコードで1から100までの数字をすべて足すコードを書いたとき、LLVMが自動的に5050と返してくるなどです。これは、ループを解いたりする最適化も行っています。
昔は命令ごとの実行時間を考慮してコーディングすることがありましたが、現代の最適化コンパイラではそういった手動最適化は通用しないことが多いです。
最近のリリースビルドでのトラブルで、ARC（Automatic Reference Counting）がオブジェクトをすぐに破棄してしまう問題に当たりました。デバッグビルドではスコープが終わるまでオブジェクトが生存していたのが、リリースビルドでは最適化のために解放されることがあります。
特にクロージャーに構造体をキャプチャする際に、その構造体が解放されないように注意が必要です。このような最適化の問題は少し深いところです。
また、最近の手動最適化の話として、nilを含む配列からnilを除外してループを回す場合、compactMapを使うとメモリコピーが発生して処理が遅くなることがあります。そこで、for case let value in valuesという書き方を使った方が良いというお話がありました。これは今話題にしている最適化とは少し違いますが、興味深い点なので紹介しておきます。
以上です。質問や補足があれば、いつでもどうぞ。 配列に関する話題ですが、Swiftの配列には「コピーオンライト」という仕組みがあります。例えば、配列Aがあって、その配列を他の変数にコピーした場合、本来構造体は同じメモリインスタンスを指さないという基本原則があります。したがって、AとBは別物として扱われます。
しかし、Swiftでは「コピーオンライト」という最適化がされています。具体的には、let B = A という形で配列を代入した時、実際にはメモリがコピーされず、BがAの内部メモリを参照する形になります。この状態ではメモリの複製はまだ行われていません。
実際にBに変更を加える、例えばBの要素の一部を変更したり追加したりする際に、初めてメモリのコピーが発生します。これにより、パフォーマンスが向上し、メモリの無駄遣いが減少します。
ただし、この最適化が原因で問題が発生することもあります。特にマルチスレッド環境で、初めて変更が加わる時にメモリコピーが行われるため、タイミングによってはランタイムエラーやアクセス違反が発生する可能性があります。
例えば、変数Aを定義し、以下のようにDispatchQueueを使用して異なるスレッドでアクセスした場合を考えます。
var A = [1, 2, 3]
DispatchQueue.global().async {
// Bの生成
var B = A
// Bを変更
B.append(4)
}
DispatchQueue.global().async {
// Aを変更
A.append(5)
}
このような状況で、最初に変更が加わったタイミングでメモリのコピーが行われるため、アクセスが重なるとランタイムエラーが発生する可能性があります。Objective-Cの頃には、このような場合にコピーを明示的に行うなどして対応していましたが、Swiftではコピーオンライトを意識してコードを書く必要があります。
また、クロージャのキャプチャについても注意が必要です。以下のようなコードで、クロージャ内で配列をキャプチャする場合、適切にレッド変数を扱わないとコピーオンライトによる問題が発生する可能性があります。
var A = [1, 2, 3]
DispatchQueue.global().async {
var B = A
// Aが変更される前にBを変更
B.append(4)
}
このように、Swiftの配列では「コピーオンライト」の特性に注意しながらコーディングすることが重要です。マルチスレッド環境では特に気をつける必要があります。 引数です。キャプチャリストは、とりあえず後でちゃんと調べて、Slackに投げときますね。今回あんまり本題じゃないんでね。
さっき変数のAがletで、変数Bがvarでバリアブルになってて、それでBにappendしてたじゃないですか。この時って、変数が参照渡しになっているので、Bに追加すればAにも追加されるのか？
それですね。Swiftの構造体は値渡しが原則です。なので、Aには追加されないっていう動きになります。
なるほど。あれがストラクトだから値型になって、でもコピーオンライトが働いているから、変更加えるまでは例外的に参照になってるって感じですか？
そうそう、そういうことなんです。なかなか変更加えるまでは参照渡しになってるから、このグローバルだと起きる？
そうそう、グローバルだとそう。参照渡しというか、例外的にBが持っているのは実体の[1,5,15]の配列ではなくてAの参照。
なるほど。つまり、Bに変更加え始めると、その参照から[1,5,15]の配列がコピーされて、別のメモリアドレスにアサインされて、そこに変更加えるという感じですね。
なるほど。その同時にAとBをいじろうとすると、BはAから実体を作ろうとするが、そのタイミングでAが書き換わっているのでランタイムエラーが発生するみたいな可能性がある。AとB両方がvarだと。
なるほど、そうかそうか。Aがletの場合はこれ起きないのか？
Aがletだったら確かに問題は起こらないんですね。
なるほど。起こらないはずですよね。Aは絶対変更されないから。その場合も考えなくてよい。あと、「ミュータブル」と「イミュータブル」という考え方を調べていくと、いろいろ面白い知識が広がっていくかなと思います。
実際、配列ってイメージしにくいかと思うんですけど、こんなふうな2つの構造にタブになってる。内部的に外からアクセスできないバッファーを持っていて、それでアレイが成り立っていて、こうやって書いたときに、構造体のメモリーは丸っと複製される。クラスはポインター、差し先だけがコピーされる。差し先のアドレスだけがコピーされて同じインスタンスを指している。これが、入れ子に対しても同様に起こるんです。
この代入文が書かれたときに、構造体の中身のプロパティが丸っとコピーされて、その中身のプロパティはクラス型なので、この参照だけがコピーされるっていう動きをして、実質的にXもYも同じアレイバッファーを参照したインスタンスが作られるという風になります。
実際に書き込みが行われるときに、こんな感じかな。書き込みが行われるときにappendのほうが分かりやすかったかな。書き込みが行われるときにisUniqueってなかったっけな、isNonUniquelyReferencedっていうのを参照して、バッファーが唯一一箇所から参照されていた場合には...
今回の逆は、唯一じゃない。複数の場所で共有されていたときには、改めて自分のバッファーを、たとえばちょっとコピーは作ってないけど、動くものと仮定して、自分のバッファーを初めてここでコピーして、それからバッファーのインデックスに対して値を入れるみたいな、こういう動きになる。ちょっとスクロールしちゃった。こういう作りになってるんです。
なので標準ライブラリのArrayもそうですし、DictionaryもStringも、そういったたくさんのデータもそうですね。標準ライブラリには、NSデータを持っている場合でも、とりあえずメモリー量が多くなりがちな標準の型については、こういうふうに内部でバッファーを作って、参照が複数あったときにはコピーを作って、唯一の参照を持った状態にして、初めて書き込み処理を行うっていうコードが組み込まれていて、最適化が図られているっていうのを知っておくといいです。
もし今後、自分でメモリーを大量に使うけど頻繁に書き込みを行う可能性がある型っていうのを作らなきゃいけなくなったときには、この標準ライブラリのやり方を応用して、自分でコピーオンライトを書いてみることもできたりします。こんな感じで、ユーザーも触れる最適化の一例を紹介してみました。
他にも、ここで話したいことがあればこのままいろいろ話してもいいですし、なければもう1個の最適化の例を5分ぐらいで話そうかなと思いますけど。
コピーオンライトを自作するという発想がなかったですね。あんまりこういうことをやると、さっきのマルチスレッドでの思いがけないランタイムエラーとか、起こすことがあることも考えると、パフォーマンスばかり求めるのも良くないかなとは思いますけど、知っておくと応用できていいですよね。
はい、以上で終わります。ありがとうございました。第1回にしてはいきなり難度が高い問題が多かったですね。最適化のお話自体が難度高いので、こういったふうに話しかけてもらえれば、自分が分かる範囲で話ができたりもします。皆さんが自分の好みのほうに勉強会を持っていけるっていうところがあるんで、ぜひぜひ慣れてきたら、こんなふうに話しかけてもらえたら嬉しいなと思います。
せっかくなので、大塚さんとか木村さんが聞きたいことありますかね？
ありがとうございます。非常に深い話だったので、思ったよりも、これを自分で理解して使えるようになるのはまだまだ先の日だなと思いながら。
大丈夫大丈夫、コピーオンライトなんて自分でもまだ... 自分の中では、こういったことについては、ここで完全に理解することよりも、とにかく触れておくのが大事だと思います。そうすると、頭のどこかに発想として徐々に積み重なっていきます。一回では無理かもしれませんが、実際の現場で高度なコードに触れたときに、「これってあの時のあれだ！」とか楽しむことができますし、そこから新たな発見や推察が生まれてきたりすると思います。
この際、難しいとか難しくないとか、あまり気にしなくて良いので、とりあえずこういう機会を活かしてほしいと思います。話す側も聞く側もせっかくなので、気軽な気持ちで参加していただければと思います。分からない部分は誰にでもあるので、気にせず流してもらえれば十分です。
次に、「ArrayBuffer」がクラスとして扱われる場合、参照渡しになります。このため、特定の問題が発生することがあります。もし「ArrayBuffer」が構造体だった場合、値渡しで扱われるため、代入文を書いた際に全てをコピーしなくてはならず、パフォーマンスが低下する問題が出てきます。この点について、「構造体ではダメなんですか？」という質問がありましたが、前述の理由で速度が遅くなるため、クラスとしての実装が選ばれています。
また、「compactMap」の最適化によるメモリ複製についても話します。このとき、プリントなどの簡単な処理でも、コピーされているかどうかで速度が大きく違ってきます。試してみると、リリースビルドでもどこまで最適化されるか分かりませんが、LLVMが最適化を行う可能性があります。
「compactMap」がフィルターであった場合、最適化が行われない可能性もありますが、最適化が確実であればパフォーマンス面では問題ありません。実際のプロジェクトでも、この点を考慮してコードを書いています。
次に、巨大な配列や文字列をメソッドの引数に渡す場合の「コピーオンライト（Copy On Write）」について話します。この機能により、無駄なコピーが起こらず、パフォーマンスの低下を防ぎます。例えば、大きな配列や文字列を引数として渡しても問題ありません。コピーオンライトは非常に重要な機能で、これを理解することで、性能を向上させたコードを書くことができます。
最後に、今日は14時までの予定なので、そろそろ終わりにします。他に用事がある方もいらっしゃるかと思うので、ここまでにしますが、今回の内容が難しく感じたとしても、理解を深めるための第一歩として捉えていただければと思います。興味があるキーワードは、ぜひ調べてみてください。 ただ、基本を見つつ脱線していくというような感じになっていくと思いますので、また2回目、3回目とぜひよろしくお願いします。
はい、じゃあ今回はこの辺で終わりにします。皆さまお疲れさまでした。ありがとうございました。
メソッドのほうに配列を渡して、渡したさっきの例みたいなものをサブスレッドで両方一気にやろうとしたらクラッシュする可能性もありますかね？
えっと… Swiftの場合、変数に渡した時点で let になります。そっちは定数だから問題ないのか。そう、定数の扱いになるんです。この時点で... あ、でも、もし A が var だったら状況は変わりますね。A が var だったら、いくら let にしても、書き込みが行われない限りは複製されません。例えば、ディスパッチの async を使って、グローバル async の中で操作をするとします。
正しい書き方をするならば、ここの let は不要で var でコピーします。それで、この async の中で append とかをしたときに、
var a = [1, 2, 3]
DispatchQueue.global().async {
a.append(4)
}
例えば、ここの var で渡すと、最初のタイミングでバッファが変わるんです。これが、うっかり同じタイミングで a が書き換えられていると、問題が起こる可能性があります。
なるほど、勉強になります。ありがとうございます。
こういった部分は非常に難しいですよね。全てがクラスだったオブジェクト指向の頃は気を回しやすかったですが、それでも面倒でした。次の動画でお会いしましょう。じゃあ、またね。
今時のエンジニアは多分、もうアロケーションについて知らないでしょう。Swiftはアロケーションを暗黙的にやってくれるので、初期化（イニシャライゼーション）は基本的に init のタイミングでユーザーに渡されます。そのため、裏で起きているアロケーションについては理解しづらいですね。
アロケーションの部分で問題が起こると致命的です。昔は、オブジェクティブCの頃は、手動でコピーしておかないと危険だとか、別のスレッドに渡す前にはコピーが必要だとか、そういった配慮が必要でした。
今の Swift のコードでは、アロケーションやコピーオンライトなどの裏方の動きを意識するのは非常に重要です。それを意識するだけで、他の人よりも安全なコードを書けるアドバンテージになります。この機会に自身でも調べて深めてみるといいかなと思います。自分でコピーオンライトを書いてみるのも楽しいですよ。非常に面白い経験になると思います。
バッファーをクラスで作ったり、構造体で作ったりという応用もあります。バッファーを共有したい場合は構造体よりクラスのほうが適しています。構造体の勉強を進めれば、クラスと構造体の使い分けについての知見も深まるでしょう。
コピーオンライトについても、理解を深めると非常に興味深い話が広がっていきます。最初のうちは意識的に学ぶ必要がありますけど、だんだんと余裕が出てきたら、さらに応用的な視点で考えてみると良いと思います。
いろいろ話していますが、これは雑談タイムという感じですので、時間がない方は離れていただいても問題ありません。時間が過ぎていますので、よろしくお願いします。
何か質問がある方はぜひ聞いてください。まだ時間がありますし、毎週3回ありますので拙速にならずに進めましょう。
最近、パフォーマンスやメモリー領域について気になっていて、特に動的確保と静的確保について興味があります。Javaだとリストを最初に確保して、追加ごとにメモリー領域が動的に拡張されますが、その辺も面白いですね。また別の機会にでもそれについて話しましょう。 たぶん、どっちを配列（Array）と呼ぶか、どっちをリスト（List）と呼ぶかというのは、言語ごとに発想が違ってくるかなと思いますので、言葉にとらわれないようにしつつ、いろいろな情報を集めていくといいかと思います。
あと、その他にね、もう1個なんだっけ、リストの形のうちにポインタで繋いでいくやつ、何でしたっけね。値と次の値を持つインスタンスのためのポインタを持っていて…ノード? ノードって言ってもいいかもしれないですね。それも多分、人によってはリストとか配列とかの種類のうちの1個と捉える人もいるかもしれないですね。二分探索木とかを作るときに便利なやつです。
繋ぐ箇所を1箇所じゃなくて2箇所にするとツリーを作っていけますし、間を抜くときにも、抜いたやつの参照先を持ってきてあげれば間をいくらでも切り貼りを同じパフォーマンスでできる。固定配列だと間を抜くと残り全部を丸っとコピーしないといけない。動的配列もそうですね。なので、間を切り抜いたりとかを頻繁にやるリストを作りたいときには、そういうノードのスタイルを選んでいくということもありますね。
情報処理技術者試験の範囲、今は基本情報技術者ですね。基本情報技術者試験で学ぶようなアルゴリズムは、最近あまり必要なくなってきましたが、知っておくとより役立つこともあります。なので、次のステップとして、まだ資格を持っていない方は基本情報技術者試験を受験してみると面白く感じる人もいるかもしれませんし、少なくとも力にはなりますね。
リストといってもたくさんありますね。リストではついつい配列だけをイメージしがちですが、厳密には人によって違うんですね。そうやって他の言語を知っていると、その知見と合わせて比較してみるとまた視野も広がって面白いんですよね。ただし、同じ言葉を使っていたとしても言語によって違うものを指すことはよくあるので、そこに惑わされると足を引っ張られることも意識しておくと、より知識が広がるかなと思います。
自分は勉強していて、特にObjective-CからSwiftに移ったときに特にそう感じましたね。結構似ているんですけど、この二つは何でしたっけ。Javaだと、初期化を「initialize」、コンストラクタを「constructor」と言っていましたね。Swiftでは「constructor」という言葉は出てこないんですけど、「アロケーション」と「初期化」ですね。
確かJavaではフィールドを埋めるのがイニシャライザーで、その後のインスタンスを整えるのがコンストラクタだったと記憶しています。その辺りもJavaを見ていくと面白かったりするので、Javaもぜひ言語仕様などを見てみるといいかなとお勧めします。
はい、以上で終わります。ありがとうございました。何か他にありますか？ こんな感じで、感想とか何でも。だんだん人も少なくなってきたでしょうから、話しやすいですよね。
次回以降でどんなことをやっていく予定なんですか？
そうですね、とりあえず冒頭では『The Swift Programming Language』の一番最初「The Basics」というところ、変数の代入とかそういったところから見ていくかなと思います。その中でも、流れによっては今回話したようなコピーオンライトの話に繋がったりするかもしれません。今回話したばかりなので、コピーオンライト以外の話をしようかなとは思っています。
それと、SwiftのAppleが公式で出しているAPIデザインガイドラインをまず復習してみても有意義かなと考えています。Swiftではメソッドは小文字から始めるとか、そういう基本的なルールですね。やっぱりそこが整っていると気持ちがいいですし、自分のコードを確認しても、人の見るにしても理解しやすいと思います。既に知っている人も確認の意味で多分いいかなと思います。
今後もしっかりと学ぶ時間を取るのが難しい分野なので、じっくりとこの1時間を使って、詳しく細かく見ていこうかなと思います。特に話題が落ち着いたなら、時間も20分過ぎてますし、また次回にしましょう。