v5.7
のラベル付けています。もしやりたいものがあればAssigneesにお名前追加してください! https://github.com/stzn/the-swift-programming-language-jp/issues (edited)String
で特定されているので、String
のみを保持することができます。 と訳していますが、今となっては全部「格納」で良いのかなと思ってきました。 当時はなんとなく「メモリに値を格納する」と「データを変数に保持する」みたいな感じで分けていたのかなと(ただ統一性がなく、なぜそうしたのかは1年以上前なので覚えてないです...)。 (edited)stored
が使われてる例だと stored procedure があるなあと思ったけどこれは「ストアドプロシージャ」で定着しててなんも参考にならんかった。struct
も Swift の文脈ではあまり「構造体」と呼ばない気がする。Stored Properties of Constant Structure Instances
のところ、定数の格納インスタンスのプロパティ
と翻訳されていました。 定数の格納インスタンス
は定数に格納されたインスタンス
という意味で通りそうですが、それでもProperty
にかかるStored
が抜け落ちているため、翻訳として適切でないと思います。 methods.mdからこの項目へのリンクがあったので、併せて修正しています。 // this range represents integer values 0, 1, 2, and 3
です。 3が抜けてコードと矛盾していました。
textlint-disable
で無視するようにしました。if let
の同名省略の記述を追加(Swift5.7からなのでコメントアウトしています) 特定の列挙ケースの全てのインスタンス
だと一つの列挙ケースにたくさんインスタンスがあるということになり、それは変じゃないかと思ったのですが、Swiftの列挙体は値型なので、別の変数に代入すればそれは異なるインスタンスになるのでした。ここは元の文に戻しておきます。 suggestion もし列挙型が Raw Value を持つ場合、これらの値は宣言の一部として決定されます。これはつまり、特定の列挙ケースの全てのインスタンスは、必ず同じ Raw Value を持つということです。もう 1 つの選択肢は、列挙ケースに関連値\(Associated Values\)を持たせることです。関連値はインスタンス生成時に決定され、列挙ケースのインスタンスごとに異なる値を持つことができます。関連値は列挙ケースのインスタンスの格納プロパティのように振る舞います。例えば、サーバから日の出時刻と日の入り時刻をリクエストする場合を考えてみてください。サーバはリクエスト情報に応じたレスポンスを返すか、リクエストが間違っている場合は間違っているという内容を返します。
定数、変数、プロパティ、または subscript
のようになっている文章が多く、サブスクリプトにしたほうが読みやすいかと思います。
opaque type
となっていました。 これに対する訳は他の言語コミュニティでも定まっていなさそうで、 一番定着している訳というのもわからなかったです。 他方、データベースの型について調べると 簡単に変わることはないのではと思う例がありました。 IBM と Oracle は自社製品に関するドキュメントの中で 不透明型
という訳を使っています。
不透明型
とするのはどうかなと思っています。value
の訳が 値
ではなく バリュー
となってしまっています。 GitHub の Projects 機能で管理してもいいのではないでしょうか。
value
は文脈による可能性ということですね。 要素
という語も浮かびましたが、適切なのか分かりません…。 とりあえず value
の表記揺れは他の方の意見を待ち、 それ以外の部分をチェックしていきます key-value pair
についてはキーバリューペアでいいと思います。 https://github.com/stzn/the-swift-programming-language-jp/blob/777b7d6f03b85e6de0000d0226c133f2b870d0c2/language-guide/collection-types.md?plain=1#L474 これを根拠として、辞書型ではバリューを使っていくというのでも良いんじゃないでしょうか。value
については バリュー
の訳になるよう気をつけます! 格納
にして問題なさそうなところはそのようにしていきますね。
キーパス
、KeyPath
、key-path
、key path
が混在しています。 原文では型を指す KeyPath
以外では key path
かkey-path
が使われています。 関連して、identity key path
(.self)の翻訳が識別キーパス
となっていますが、識別だと意味が違うような気がします。型が Sendable であることを示すことができます
にしたいがlintで弾かれる。structured concurrency
の翻訳が 構造同時並行性
になっていましたが、構造化された並行性
という翻訳が他言語でも広く使われているようです。 構造同時並行処理
のような形で出てきている箇所もありますが、これらも併せて変更しています。非構造タスク(unstructured task)
を 構造化されていないタスク
にすべきか迷ってとりあえずそのままにしています。 また、原文ではunstructured task
の初出は斜体になっているのですが、翻訳の際にルールはあるのでしょうか?key path
が良いかなと思いますが、いかがでしょうか? self key path
で良いような気がしますねー。いかがでしょうか?構造化されていない〜
という否定形が何度も出てくると読みにくいかなと感じました。 一方、少し上の方でunstructured child task
を独立した子タスク
と翻訳している箇所がありました。 unstructured
の翻訳として 独立した
を使うのが正当なのかはよく分かりませんが、読みやすさだけなら 構造化されていないタスク
より 独立したタスク
のほうが上だと思います。意味的にもずれてはいないと思いますがどうでしょうか。SE-0249 Key Path Expressions as Functions
の話ですが、字幕では全体に KeyPath
ですね。 https://developer.apple.com/videos/play/wwdc2020/10170 型の KeyPath
と混在してしまうという問題がありますが… 自己参照KeyPath
みたいにするより self KeyPath
のほうがシンプルで良さそうですね。unstructured
の翻訳を独立した
に変更しました。 unstructured task
を残してみました。* 正規表現の作成に関する情報を [正規表現リテラル](../language-reference/lexical-structure.md#lexical-structure-regular-expression-literals) セクションに追加しました
* アクターとタスク間のデータ送信に関する情報を [Sendable Types](../language-guide/concurrency.md#sendable-types) セクションに追加しました。また、[@Sendable](../language-reference/attributes.md#sendable) 属性と [@unchecked](../language-reference/attributes.md#unchecked) 属性に関するセクションを追加しました
KeyPath
に統一 identity key path (\.self)
の翻訳として self KeyPath
を導入 subscript syntax
だけ翻訳していたのですが、 @t-ae さんによる先の PR で包括的に解消済み To create an unstructured task that’s not part of the current actor, known more specifically as a detached task,
で、detached task ⊂ unstructured task
という関係が明示されています(翻訳では省略されていますね)。 なので独立したタスク
の中に完全に独立したタスク
があるというのも一理あるかとは思うのですが、読みやすさでは切り離されたタスク
のほうが良いと思います。現在のアクター上で実行されない独立したタスク
となり、独立した
の意味がブレそうなのが気になるのも一因です)access context
と access level context
が出てきて、ここでは access context
です。 使い分けがよく分かりませんが、とりあえず出てくるものに合わせました。but whose conformance to an internal protocol can only be used within the internal protocol’s defining module.
準拠自体のアクセスレベルの話をしているようなので、プロトコルへ準拠した実装は
は違うと思います。 ある型が InternalProtocol
を実装しているとして、外部のモジュールからは InternalProtocol
に準拠していることを認識できないというような意図ではないかと思っています。John Appleseed
人名も翻訳したほうがいいですかね? 例えば「ジョン・アップルシード」に変えたほうがいいでしょうか?4
に変更しました。Customer
クラスのname
プロパティなので、呼称を「さま」にしました。全てのタイプエイリアスは、アクセス制御の目的で別個の型として扱われます。タイプエイリアスは、エイリアスする型のアクセスレベルより制限の厳しいアクセスレベルを設定することができます。例えば、private タイプエイリアスは private、fileprivate、internal、public、または open 型のエイリアスになれますが、public タイプエイリアスは internal、fileprivate、または private 型のエイリアスにはなれません。
[Default Initializers\(デフォルトイニシャライザ\)](../language-guide/initialization.md#default-initializers)で説明されているように、Swift は、全てのプロパティにデフォルト値が提供されていて、かつ 1 つもイニシャライザが定義されていない構造体または基本クラスに、引数なしの_デフォルトイニシャライザ_を自動的に提供します。
少なくとも同じレベル
-> 同じかより高い
-> 同じかより緩い
で同じ気がしてきました… 頭の中で緩厳で認識していたので、少なくとも同じレベル
だと緩厳どちら方向が許されるのか曖昧だなと思ったのですが、高低で考えると分かる箇所ですね。 元に戻します。suggestion 列挙型定義の Raw Value または関連値に使用される型には、少なくとも列挙型のアクセスレベルと同じ高さのアクセスレベルが必要です。例えば、private 型を internal アクセスレベルの列挙型の Raw Value 型として使用することはできません。
https://github.com/stzn/the-swift-programming-language-jp/pull/333#discussion_r939156980 このコメントで元の文を復元したのですが、元の文はレベルが複数回出てきて読みにくい気がします。 アクセスレベル自体が高低を持った概念なので、少なくとも同じレベル
という言い回しより 少なくとも同じ高さ
で良いかと思いました。
name
プロパティで3つも出し分けが必要でした。 Person
のname
プロパティ: 「さん」 Customer
のname
プロパティ:「さま」 HTMLElement
のname
プロパティ:敬称なし The fallback logic to use “World” when name is nil has to be done inline using the ?? operator,
インラインで実行する
だと意味が通らないので 記述する
に変更しました。
suggestion 最終更新日: 2022/8/10
suggestion print("letters は \(letters.count) 個の要素を持つ Set<Character> 型です。")
suggestion print("ただ今 \(customerProvider()) を接客中!")
servingは[飲食物を人]に配るという意味だから、 customersInLine
に合った訳は「接客中」のほうがいいかもしれないan axis
を「ある軸上」と訳すよりは具体的な軸に言及したほうがわかりやすいかなと思いました。swift printAndCount(string: "hello, world") // prints "hello, world" and returns a value of 12 printWithoutCounting(string: "hello, world") // prints "hello, world" but doesn't return a value
https://docs.swift.org/swift-book/LanguageGuide/Functions.html
print
の英文が抜けていたので、翻訳は原文を参照しました。
swift let doubleIndex = findIndex(of: 9.3, in: [3.14159, 0.1, 0.25]) // doubleIndex is an optional Int with no value, because 9.3 isn't in the array
with no value
の情報が現状抜け落ちていたので補いました
xxx演算子
と訳すのが良さそうですね。 候補は下記がありそうですが、どれもググって正式に使われているシーンがちゃんと見つけられないです・・・ print("\(customerProviders.count) 個のクロージャーが保持されています。")
print("空港辞書には \(airports.count) 個のアイテムがあります。")
// 私には 3 個の好きな音楽ジャンルがあります。
// theAceOfSpades: 柄は ♠, 数字は 1 と 11
保持されています
良いと思いますairports
dictionaryを定義して説明していく流れになっています。 本文も 「airports
辞書」と説明しているのでいるので「airports」はそのままにするほうがいいかなと思いました。 var airports: [String: String] = ["YYZ": "Toronto Pearson", "DUB": "Dublin"] `airports` 辞書は、`[String: String]` 型と宣言され、 // 本文もairports辞書で説明 「`String` 型のキーと `String` 型のバリューの `Dictionary`」を意味します。
https://github.com/stzn/the-swift-programming-language-jp/pull/342/files/0cf86c48e96ae9a73398642791d8be0228efafbf#...
airports
dictionaryを一度定義してそれを使って説明する流れになっています。 https://github.com/stzn/the-swift-programming-language-jp/blob/0cf86c48e96ae9a73398642791d8be0228efafbf/language-guide/collection-types.md?plain=1#L481 なので、 「the airports dictionary.」は上の定義を指しているので「airports」は削らないほうがいいかなと思いました。 また、今までの訳では「airport/空港 辞書」で説明したところがいきなり「辞書」だけになると読者も同じものを指しているかが分かりくくなるかなと思いました。airports
のままで大丈夫です!suggestion print("予期せぬ自動販売機とは関係ないエラーが発生: \(error)")
suggestion print("(\(x), \(y)) は x == -y の線上にあります")
suggestion 上記の例では、`approximateCount` が `switch` 文で評価されています。それぞれのケースでは、1 つの数値または範囲で比較しています。`approximateCount` の値は、12 から 100 の間にあるので、`naturalCount` には `"数多くある"` という値が代入されます。実行後は `switch` 文から抜け出します。
suggestion print("(\(x), \(y)) は x == y の線上にあります")
〜である〜
と書きたい所を〜な〜
と書いている箇所が散見されます。 textlint-rule-no-mix-dearu-desumasuのREADMEによると、オプションでstrict: false
と設定することで文中の〜である〜
が弾かれなくなるようです。 問題なさそうならこの設定に変えても良いのではないでしょうか。これらの要件を定義するために、`Container` プロトコルは、コンテナが保持する要素の型を参照する必要がありますが、特定のコンテナでその型が何なのかを知る必要はありません。`Container` プロトコルは、`append(_:)` メソッドに渡される値の型、およびサブスクリプトによって返される値の型とコンテナの要素の型を一致することを要求します。
suggestion Swift の型推論のおかげで、`IntStack` の定義の中で `Item` が `Int` であることを宣言する必要は実際はありません。`IntStack` は `Container` プロトコルの全ての要件に準拠しているため、`append(_:)` メソッドの `item` パラメータの型とサブスクリプトの戻り値の型から、使用する適切な `Item` を推論できます。実際、上記のコードから `typealias Item = Int` 行を削除しても、`Item` に使用する型が明確になっているため、全てが引き続き機能します。
Reference cycle
の翻訳として循環参照と参照循環が混在しており、前者のほうが一般的なのでそちらに統一しました。suggestion Swift は、不要になったインスタンスのメモリへの割り当てを自動的に解除して、リソースを解放します。[Automatic Reference Counting\(自動参照カウント\)](automatic-reference-counting.md)で説明されているように、自動参照カウント\(ARC\)を通じてインスタンスのメモリを管理します。通常、インスタンスが解放されるときに手動でクリーンアップを実行する必要はありません。ただし、独自のリソースを取り扱っている場合は、追加のクリーンアップが必要になる場合があります。例えば、ファイルを開いてデータを書き込むカスタムクラスを作成する場合、クラスのインスタンスを解放する前にファイルを閉じる必要があります。
suggestion クラスへのオプショナルの参照を `unowned` とマークできます。ARC 所有権モデルの観点から言うと、オプショナルの非所有参照と弱参照は共に同じコンテキストで使用できます。弱参照との違いは、オプショナルの非所有参照を使用する場合、それが有効なオブジェクトを参照しているか、`nil` が設定されているか、どちらの状態であるかを常に確認する責任が自分にあることです。
make sure
の日本語訳の候補の一つですが、実際の所unownedな変数が有効なオブジェクトを指しているかどうかを確認する方法ってあるんですっけ?(実際アクセスしてクラッシュさせるのは除く) そもそもweak変数がオブジェクト開放時にnilになる=有効なオブジェクトを指さなくなったことを容易に確認できる機能なので、optional unownedでも確認が必要ならweakにすればいいのでは?という話になってしまい、この文章の主張しているweakとunownedの差異について正しく伝えられないと思います。 unownedは存在チェックをするようなものではなく、指しているオブジェクトが開放されるタイミングまでにその参照を外すことをユーザーに要求し、どのタイミングでアクセスしてもクラッシュしない状態を維持することの責任はユーザーにある、というのがこの文章の意図だと私は解釈しています。 making sure
の翻訳的には、これを意図しています。 https://ejje.weblio.jp/content/make+sure
suggestion クラスへのオプショナルの参照を `unowned` とマークできます。ARC 所有権モデルの観点から言うと、オプショナルの非所有参照と弱参照は共に同じコンテキストで使用できます。弱参照との違いは、オプショナルの非所有参照を使用する場合、それが有効なオブジェクトを参照しているか、`nil` が設定されているか、クラッシュしない状態を維持する責任は常に自分にあります。
suggestion クラスへのオプショナルの参照を `unowned` とマークできます。ARC 所有権モデルの観点から言うと、オプショナルの非所有参照と弱参照は共に同じコンテキストで使用できます。弱参照との違いは、オプショナルの非所有参照を使用する場合、いつアクセスしてもクラッシュしないように、それが有効なオブジェクトを参照しているか、`nil` が設定されているか、常にどちらかの状態を維持する責任があることです。
クラッシュしない状態
を入れるならこちらのほうが分かりやすいかなと思います。
suggestion プロパティラッパを用いることで、複数のプロパティの get や set のためのコードを再利用できます。
他と合わせてひらがながよいかなと思います。suggestion タスクは、プログラムを分離された同時並行処理の断片に分割するために使用できます。タスクは互いに分離されているので同時並行に実行しても安全ですが、タスク間で何らかの情報を共有したい場合もあります。アクター\(_actors_\)を使用すると、同時並行処理をするコード間で安全に情報を共有することができます。
ありがとうございます。いくつか細かい提案です。suggestion Swift は、これらの概念を単一のプロパティ宣言に統合しました。Swift のプロパティには対応するインスタンス変数がなく、プロパティの保存領域に直接アクセスされることはありません。このアプローチにより、様々なコンテキストから値にアクセスされてしまうことで起きる混乱を回避し、プロパティの宣言方法を単一の明確な文に単純化します。名前、型、メモリ管理の特性など、プロパティに関する全ての情報は、型の定義の一部として 1 つの場所に集約されています。
suggestion 最終更新日: 2022/11/25 原文: https://github.com/apple/swift-book/blob/main/Style.md
suggestion プロトコルにオプショナルの要件を定義できます。これらの要件は、プロトコルに準拠する型によって実装される必要はありません。オプショナルの要件には、プロトコルの定義の一部として `optional` 修飾子が付けられます。Objective-C と相互運用するコードを作成できるように、オプショナルの要件が利用可能です。プロトコルとオプショナルの要件の両方が `@objc` 属性でマークされている必要があります。`@objc` プロトコルは、構造体や列挙型で準拠することはできず、クラスでのみ準拠できることに注目してください。
もう少しシンプルにできるかなーと思いましたが、どうでしょうか?suggestion プロトコルの名前は、他の名前が付いた型と同じように使用することができます。例えば、同じ 1 つのプロトコルに準拠した異なる型のオブジェクトのコレクションを作成することができます。ボックス化されたプロトコル型の値をそのまま扱っている場合、プロトコルの外側で定義されたメソッドを使用することはできません。
suggestion * [Opaque 型とボックス化されたプロトコル型\(Opaque Types and Boxed Types\)](language-guide/opaque-types.md)
suggestion プロトコルをジェネリック制約として使用することについては、[ジェネリクス\(Generics\)](../language-guide/generics.md)を参照してください。Opaque 型とボックス化されたプロトコル型については、[Opaque 型とボックス化されたプロトコル型\(Opaque Types and Boxed Types\)](language-guide/opaque-types.md)を参照してください。
suggestion * 必須ではない構文カテゴリとリテラルは、末尾にクエスチョンマーク_?_が付加されます
等幅フォント
は原文に合わせて↓に変更させてください。 <img width="978" alt="スクリーンショット 2023-08-18 18 45 13" src="https://github.com/stzn/the-swift-programming-language-jp/assets/35151927/2618a632-784d-4002-a89b-1883319cef5e">
suggestion * 単語リテラルと句読点は、**太字の等幅フォント**で示され、文法生成規則の右側にのみ現れます
* 必須ではない構文カテゴリとリテラルは、末尾にクエスチョンマーク _?_ が付加されます
doc:TheBasics#Type-Annotations
の削除 同時並行コードを構造化するために、タスクグループ\(_task group_\)を使います。
nil
の値を伝播させるには、nil
を返すか、?
を使用します。?
演算子については[Optional Chaing]を参照してください。」txt `??`を使用してフォールバック値を提供する方法の詳細については、[Nil-Coalescing-Operator\( `nil` 合体演算子\)]()を参照してください。
suggestion 冠詞を省略してください。"use an optional binding"ではなく、"use optional binding"を使用してください。
suggestion // convertedNumber の型は 「Optional<Int>」 です。
suggestion このオプショナルと非オプショナル値を区別することで、どの情報が欠如しているか明示的にマークすることができ、欠如している値を取り扱うコードを書くのが簡単になります。オプショナルを非オプショナルとして誤って扱うことはできません。なぜなら、このようなミスはコンパイル時にエラーを生成するからです。値をアンラップした後、その値を利用する他のコードは `nil` のチェックをする必要がなくなるため、コードの異なる部分で同じ値を何度もチェックする必要がありません。
suggestion この種のコードはとても一般的で、短いスペルを使用してオプショナル値をアンラップできます。アンラップする定数または変数の名前だけを記述します。ラップされていない新しい定数または変数は、オプショナル値と同じ名前を暗黙的に使用します。
suggestion オプショナル値にアクセスするとき、コードは常に `nil` の場合と非 `nil` の場合の両方を処理します。値が欠如しているときにできるいくつかのことがあり、次のセクションで説明されています。
タグを使う必要があります。
swift ;
``suggestion > Any 型は、オプショナルの型を含む任意の型の値を表します。`Any` 型の値が期待されているところにオプショナル値を使用すると、Swift は警告を出します。本当にオプショナル値を `Any` として使用する必要がある場合は、下記に示すように、`as` 演算子を使用して、オプショナルを `Any` に明示的にキャストします。
suggestion オプショナルチェーンが `nil` 値で呼び出される可能性があるということを反映するために、照会しているプロパティ、メソッド、またはサブスクリプトが非オプショナル値を返した場合でも、オプショナルチェーンの呼び出しの結果は、常にオプショナル値になります。このオプショナルの戻り値を使用して、オプショナルチェーンが成功したか\(返されたオプショナル値に値が含まれているか\)、`nil` が存在して失敗したか\(返されたオプショナル値が `nil` か\)を確認できます。
suggestion `nil` ではない場合に呼び出したいオプショナル値のプロパティ、メソッド、またはサブスクリプトの後に疑問符\(`?`\)を配置して、オプショナルチェーンを指定します。これは、オプショナル値の後に感嘆符\(`!`\)を配置して、その値を強制アンラップするのによく似ています。主な違いは、オプショナル値が `nil` の場合、オプショナルチェーンが失敗するのに対し、強制アンラップは実行時エラーを引き起こすことです。
suggestion このコードは、前の例のコードと同様に、`myNumber` に値が含まれているかどうかを確認することから始まります。`myNumber` に値がある場合、`myNumber` という名前の新しい定数の値がその値に設定されます。`if` 文の本文内では、`myNumber` は新しい非オプショナルの定数が参照されます。`if` 文の前後で `myNumber` を使うと、元のオプショナルの定数 `Int` が参照されます。
suggestion 以下で定義される `Counter` クラスには、`CounterDataSource?` 型のオプショナル値の `dataSource` プロパティがあります:
suggestion _オプショナルチェーン_は、`nil` になる可能性のあるオプショナルのプロパティ、メソッド、およびサブスクリプトを照会して呼び出すためのプロセスです。オプショナル値に値が含まれている場合、プロパティ、メソッド、またはサブスクリプトの呼び出しは成功します。オプショナル値が `nil` の場合、プロパティ、メソッド、またはサブスクリプトの呼び出しは `nil` を返します。複数を一気にチェーンさせることができ、ある地点で `nil` が返ってきた場合、オプショナルチェーン全体が失敗します。
suggestion オプショナル値が値を含んでいる場合、`nil` と「等しくない」と見なされます。
suggestion 次は、`findIndex(of:in:)` と呼ばれる、`findIndex(ofString:in:)` のジェネリックバージョンを示しています。この関数は配列のオプショナル値ではなく、オプショナル値のインデックスを返すため、この関数の戻り値の型は引き続き `Int?` であることに注目してください。ただし、次の例の後に説明する理由により、この関数はコンパイルできないことに注意してください:
suggestion `attached` 属性は、この宣言で 2 回、各マクロの役割のために 1 回ずつ、現れます。最初の使用である `@attached(member)` は、マクロがそれを適用する型に新しいメンバを追加することを示します。`@OptionSet` マクロは、`OptionSet` プロトコルで必要な `init(rawValue:)` イニシャライザと、いくつかの追加メンバを追加します。2 つ目の使い方である `@attached(extension, conformances: OptionSet)` は、`@OptionSet` が `OptionSet` プロトコルへの準拠を追加することを示しています。`@OptionSet` マクロは、それを適用する型を展開し、`OptionSet` プロトコルに準拠します。
suggestion 最初の行で、`#function` は Swift 標準ライブラリから [`function()`](https://developer.apple.com/documentation/swift/function()) マクロを呼び出します。このコードをコンパイルするとき、Swift は、`#function` を現在の関数の名前に置き換えるマクロの実装を呼び出します。このコードを実行して `myFunction()` を呼ぶと、"現在実行中 myFunction()" と表示します。2 行目では、`#warning` は、カスタムコンパイル時の警告を生成するために標準ライブラリから [`warning(_:)`](https://developer.apple.com/documentation/swift/warning(_:)) を呼び出します。
suggestion `#fourCharacterCode` マクロは、4 文字の文字列を受け取り、その文字列の ASCII 値を足し合わせた符号なし 32 ビット整数を返します。ファイルフォーマットによっては、コンパクトな一方でデータをデバッガで読めるという理由から、データを識別するためにこのような整数を使用することがあります。以下の[マクロの実装](#マクロの実装)のセクションで、このマクロを実装する方法を示します。
suggestion 上の図は、このコードの構造が、メモリ上でどう表現されるかを示しています。AST の各要素は、ソースコードの一部に対応しています。「定数宣言」 AST 要素には、その下に 2 つの子要素があり、定数宣言の 2 つの部分、つまり名前と値を表しています。「マクロ呼び出し」要素には、マクロの名前とマクロに渡される引数のリストを表す子要素があります。
suggestion Opaque 型の戻り値を返す関数の中に戻り値を返す場所が複数ある場合、返す可能性のある戻り値は全て同じ型にすることが必要です。ジェネリック関数の場合、その戻り値の型に関数のジェネリック型パラメータを使用できますが、それでも単一の型にする必要があります。例えば、正方形の特殊なケースを含む、形状反転関数の無効なバージョンを次に示します:
suggestion ## Opaque 型とBox プロトコル型の違い\(Differences Between Opaque Types and Box Protocol Types\)
suggestion # Opaque 型とBox プロトロコル型\(Opaque and Boxed Protocol Types\)
./github/workflows
が必要なのかも・・・・・・ 一旦マージしてみて良いですか?https://swift-migration-guide.jp/documentation/migrationguide/
への案内が必要https://swift-migration-guide.jp/documentation/migrationguide/
への案内が必要