Lexical Structure¶ 語彙の構造¶

Whitespace and Comments¶ 空白とコメント¶

Whitespace has two uses: to separate tokens in the source file and to distinguish between prefix, postfix, and infix operators (see Operators), but is otherwise ignored. The following characters are considered whitespace: space (U+0020), line feed (U+000A), carriage return (U+000D), horizontal tab (U+0009), vertical tab (U+000B), form feed (U+000C) and null (U+0000). 空白には、２つの用途があります：ソース・ファイルの中のトークンを切り離すため、そして接頭辞、接尾辞、および接中辞演算子の間の区別をするため（演算子を見てください）、しかしそれ以外では無視されます。以下の文字は、空白とみなされます：空白（U+0020）、行送り（U+000A）、復帰（U+000D）、水平タブ（U+0009）、垂直タブ（U+000B）、改ページ（U+000C）およびヌル（U+0000）。

Comments are treated as whitespace by the compiler. Single line comments begin with // and continue until a line feed (U+000A) or carriage return (U+000D). Multiline comments begin with /* and end with */. Nesting multiline comments is allowed, but the comment markers must be balanced. コメントは、コンパイラによって空白とみなされます。一行コメントは//で始まります、そして行送り（U+000A）または復帰（U+000D）まで続きます。複数行コメントは/*で始まり*/で終わります。複数行コメントが入れ子にされることは許されます、しかしコメント目印が釣り合っている必要があります。

Comments can contain additional formatting and markup, as described in Markup Formatting Reference. コメントは、さらに追加の書式とマークアップを含む事が、Markup Formatting Referenceで記述されるように可能です。

Identifiers¶ 識別子¶

Identifiers begin with an uppercase or lowercase letter A through Z, an underscore (_), a noncombining alphanumeric Unicode character in the Basic Multilingual Plane, or a character outside the Basic Multilingual Plane that isn’t in a Private Use Area. After the first character, digits and combining Unicode characters are also allowed. 識別子は、大文字または小文字のAからZ、アンダースコア（_）、基本多言語面の非合成英数字のUnicode文字、または基本他言語面の外側ての使用領域の中でない文字で始まります。最初の文字の後は、桁および合成Unicode文字もまた、許されます。

Treat identifiers that begin with an underscore as internal, even if their declaration has the public access-level modifier. This convention lets framework authors mark part of an API that clients must not interact with or depend on, even though some limitation requires the declaration to be public. In addition, identifiers that begin with two underscores are reserved for the Swift compiler and standard library. あるアンダースコアで始まる識別子を内部として扱ってください、たとえそれらの宣言がpublicアクセス水準修飾子を持つとしてもです。この慣例は、フレームワーク作者にあるAPIの一部を印させます、それはクライアントがそれと相互作用すべきでないまたはそれに依存すべきでないものです、たとえ何らかの限界がその宣言にパブリックであることを要求しても。さらに、２つのアンダースコアで始まる識別子は、スウィフトコンバイラおよび標準ライブラリのために予約されます。

To use a reserved word as an identifier, put a backtick (`) before and after it. For example, class isn’t a valid identifier, but `class` is valid. The backticks aren’t considered part of the identifier; `x` and x have the same meaning. 識別子として予約語を使用するために、それの前後にバッククォート（`）を置いてください。例えば、classは有効な識別子ではありません、しかし、`class`は有効です。バッククォートは、識別子の一部とみなされません；`x`とxは、同じ意味を持ちます。

Inside a closure with no explicit parameter names, the parameters are implicitly named $0, $1, $2, and so on. These names are valid identifiers within the scope of the closure. 明確なパラメータ名のないクロージャの内部で、パラメータは暗黙のうちに$0、$1、$2、などと名前をつけられます。これらの名前は、クロージャのスコープ内で有効な識別子です。

The compiler synthesizes identifiers that begin with a dollar sign ($) for properties that have a property wrapper projection. Your code can interact with these identifiers, but you can’t declare identifiers with that prefix. For more information, see the propertyWrapper section of the Attributes chapter. コンパイラは、ドル記号（$）で始まる識別子を、プロパティラッパー投影を持つプロパティに対して合成します。あなたのコードは、それらの識別子と相互作用できます、しかしあなたは識別子をその接頭辞で宣言できません。さらなる情報として、属性の章のpropertyWrapperの節を見てください。

Keywords and Punctuation¶ キーワードと句読点¶

The following keywords are reserved and can’t be used as identifiers, unless they’re escaped with backticks, as described above in Identifiers. Keywords other than inout, var, and let can be used as parameter names in a function declaration or function call without being escaped with backticks. When a member has the same name as a keyword, references to that member don’t need to be escaped with backticks, except when there’s ambiguity between referring to the member and using the keyword—for example, self, Type, and Protocol have special meaning in an explicit member expression, so they must be escaped with backticks in that context. 上の識別子で記述されるように、以下のキーワードは予約済で、それらがバッククォートでエスケープされない限り、識別子として使われることはできません。inout、var、そしてlet以外のキーワードは、パラメータ名として関数宣言または関数呼び出しにおいてバッククォートでエスケープされることなく使われることができます。あるメンバーがあるキーワードと同じ名前を持つ時、そのメンバーへの参照はバッククォートでエスケープされる必要はありません、そのメンバーへの参照とキーワードの使用の間に曖昧さがある場合を除いては—例えば、self、Type、そしてProtocolは、特別な意味をある明示的メンバー式の中で持ちます、それでそれらはバッククォートでエスケープされることがその文脈においては必要です。

• Keywords used in declarations: associatedtype, class, deinit, enum, extension, fileprivate, func, import, init, inout, internal, let, open, operator, private, precedencegroup, protocol, public, rethrows, static, struct, subscript, typealias, and var. 宣言において使用されるキーワード：associatedtype, class, deinit, enum, extension, fileprivate, func, import, init, inout, internal, let, open, operator, private, precedencegroup, protocol, public, rethrows, static, struct, subscript, typealias, そして var。

• Keywords used in statements: break, case, catch, continue, default, defer, do, else, fallthrough, for, guard, if, in, repeat, return, throw, switch, where, and while. 文において使用されるキーワード：break, case, catch, continue, default, defer, do, else, fallthrough, for, guard, if, in, repeat, return, throw, switch, where, そして while。
• Keywords used in expressions and types: Any, as, catch, false, is, nil, rethrows, self, Self, super, throw, throws, true, and try. 式と型において使用されるキーワード：Any, as, catch, false, is, nil, rethrows, self, Self, super, throw, throws, true, そして try。
• Keywords used in patterns: _. パターンにおいて使用されるキーワード：_。
• Keywords that begin with a number sign (#): #available, #colorLiteral, #column, #dsohandle, #elseif, #else, #endif, #error, #fileID, #fileLiteral, #filePath, #file, #function, #if, #imageLiteral, #keyPath, #line, #selector, #sourceLocation, and #warning. シャープ記号（#）で始まるキーワード：#available, #colorLiteral, #column, #dsohandle, #elseif, #else, #endif, #error, #fileID, #fileLiteral, #filePath, #file, #function, #if, #imageLiteral, #keyPath, #line, #selector, #sourceLocation, そして #warning。

• Keywords reserved in particular contexts: associativity, convenience, didSet, dynamic, final, get, indirect, infix, lazy, left, mutating, none, nonmutating, optional, override, postfix, precedence, prefix, Protocol, required, right, set, some, Type, unowned, weak, and willSet. Outside the context in which they appear in the grammar, they can be used as identifiers. 特定の前後関係において予約されるキーワード：associativity, convenience, didSet, dynamic, final, get, indirect, infix, lazy, left, mutating, none, nonmutating, optional, override, postfix, precedence, prefix, Protocol, required, right, set, some, Type, unowned, weak, そして willSet。そこにおいてそれらが文法の中に現れる文脈外では、それらは識別子として使われることができます。

The following tokens are reserved as punctuation and can’t be used as custom operators: (, ), {, }, [, ], ., ,, :, ;, =, @, #, & (as a prefix operator), ->, `, ?, and ! (as a postfix operator). 以下のトークンは、句読点として予約されます、そしてあつらえの演算子として使われることができません：(, ), {, }, [, ], ., ,, :, ;, =, @, #, &（接頭辞演算子として）, ->, `, ?, そして!（接尾辞演算子として）。

Literals¶ 様々なリテラル¶

A literal is the source code representation of a value of a type, such as a number or string. リテラルは、ある型のある値をソースコードに表わしたものです、例えばある数や文字列など。

The following are examples of literals: 以下はリテラルの例です：

A literal doesn’t have a type on its own. Instead, a literal is parsed as having infinite precision and Swift’s type inference attempts to infer a type for the literal. For example, in the declaration let x: Int8 = 42, Swift uses the explicit type annotation (: Int8) to infer that the type of the integer literal 42 is Int8. If there isn’t suitable type information available, Swift infers that the literal’s type is one of the default literal types defined in the Swift standard library. The default types are Int for integer literals, Double for floating-point literals, String for string literals, and Bool for Boolean literals. For example, in the declaration let str = "Hello, world", the default inferred type of the string literal "Hello, world" is String. リテラルはそれ独自の型を持ちません。そうではなく、リテラルは無限精度を持つものとして解析されて、スウィフトの型推論はそのリテラルの型を推測することを試みます。例えば、宣言let x: Int8 = 42において、スウィフトは明示的な型注釈（: Int8）を使って、整数リテラル42の型はInt8であると推論します。適した型情報が得られなかったならば、スウィフトはそのリテラルの型はスウィフト標準ライブラリで定義される省略時のリテラル型の１つと推論します。省略時の型は、整数リテラルのためのInt、浮動小数点リテラルのためのDouble、文字列リテラルのためのString、そしてブールのリテラルのためのBoolです。例えば、宣言let str = "Hello, world"において、文字列リテラル"Hello, world"の省略時の推論される型はStringです。

When specifying the type annotation for a literal value, the annotation’s type must be a type that can be instantiated from that literal value. That is, the type must conform to one of the following Swift standard library protocols: ExpressibleByIntegerLiteral for integer literals, ExpressibleByFloatLiteral for floating-point literals, ExpressibleByStringLiteral for string literals, ExpressibleByBooleanLiteral for Boolean literals, ExpressibleByUnicodeScalarLiteral for string literals that contain only a single Unicode scalar, and ExpressibleByExtendedGraphemeClusterLiteral for string literals that contain only a single extended grapheme cluster. For example, Int8 conforms to the ExpressibleByIntegerLiteral protocol, and therefore it can be used in the type annotation for the integer literal 42 in the declaration let x: Int8 = 42. あるリテラル値に型注釈を指定するとき、その注釈の型は、そのリテラル値からインスタンス化されることができる型でなければなりません。すなわち、その型は以下のスウィフト標準ライブラリのプロトコルの１つに準拠しなければなりません：整数リテラルに対してExpressibleByIntegerLiteral、浮動小数点リテラルに対してExpressibleByFloatLiteral、文字列リテラルに対してExpressibleByStringLiteral、ブールのリテラルに対してExpressibleByBooleanLiteral、ただ１つのユニコードスカラーだけを含む文字列リテラルに対してExpressibleByUnicodeScalarLiteral、そしてただ１つの拡張書記素クラスタだけを含む文字列リテラルに対してExpressibleByExtendedGraphemeClusterLiteral。例えば、Int8はExpressibleByIntegerLiteralプロトコルに準拠します、したがってそれは宣言let x: Int8 = 42の中の整数リテラル42のための型注釈において使われることができます。

Operators¶ 演算子¶

The Swift standard library defines a number of operators for your use, many of which are discussed in Basic Operators and Advanced Operators. The present section describes which characters can be used to define custom operators. スウィフト標準ライブラリは、いくつかの演算子をあなたが使うために定義します、その多くは基本の演算子と先進の演算子で記述されます。いま目の前の節は、どの文字があつらえの演算子を定義するために使われることができるかを記述します。

Custom operators can begin with one of the ASCII characters /, =, -, +, !, *, %, <, >, &, |, ^, ?, or ~, or one of the Unicode characters defined in the grammar below (which include characters from the Mathematical Operators, Miscellaneous Symbols, and Dingbats Unicode blocks, among others). After the first character, combining Unicode characters are also allowed. あつらえの演算子は、ASCII文字/、=、-、+、!、*、%、<、>、&、|、^、?、および~のうちの１つ、または以下の文法において定義されるユニコード文字のうちの１つで始まります（それはMathematical Operators、Miscellaneous Symbols、そしてDingbatsユニコードブロックなどからの文字を含みます）。最初の文字の後は、合成ユニコード文字もまた許されます。

You can also define custom operators that begin with a dot (.). These operators can contain additional dots. For example, .+. is treated as a single operator. If an operator doesn’t begin with a dot, it can’t contain a dot elsewhere. For example, +.+ is treated as the + operator followed by the .+ operator. あなたはまた、１つのドット（.）で始まるあつらえの演算子を定義することができます。これらの演算子は、さらなるドットを含むことが可能です。例えば、.+.は単一の演算子とみなされます。ある演算子がドットで始まらないならば、それはどこか他にドットを含むことはできません。例えば、+.+は、+演算子に.+演算子が続くとみなされます。

Although you can define custom operators that contain a question mark (?), they can’t consist of a single question mark character only. Additionally, although operators can contain an exclamation point (!), postfix operators can’t begin with either a question mark or an exclamation point. あなたは疑問符（?）を含むあつらえの演算子を定義できるけれども、それは単一の疑問符文字だけから構成されることはできません。それに加えて、演算子は感嘆符（!）を含むことができますが、接尾辞演算子は、疑問符または感嘆符のどちらかで始まることはできません。

The whitespace around an operator is used to determine whether an operator is used as a prefix operator, a postfix operator, or an infix operator. This behavior has the following rules: 演算子のまわりの空白は、演算子が接頭辞演算子、接尾辞演算子、または接中辞演算子として使われるかどうかを決定するために使われます。この挙動は以下の規則を持ちます：

• If an operator has whitespace around both sides or around neither side, it’s treated as an infix operator. As an example, the +++ operator in a+++b and a +++ b is treated as an infix operator. ある演算子が、空白をそのまわりの両側に持つか、そのまわりのどちら側にも持たないならば、それは接中辞演算子とみなされます。例として、+++演算子はa+++bとa +++ bにおいて、接中辞演算子とみなされます。
• If an operator has whitespace on the left side only, it’s treated as a prefix unary operator. As an example, the +++ operator in a +++b is treated as a prefix unary operator. ある演算子が左側だけで空白を持つならば、それは接頭辞単項演算子とみなされます。例として、a +++bにおける+++演算子は、接頭辞単項演算子とみなされます。
• If an operator has whitespace on the right side only, it’s treated as a postfix unary operator. As an example, the +++ operator in a+++ b is treated as a postfix unary operator. ある演算子が右側だけで空白を持つならば、それは接尾辞単項演算子とみなされます。例として、a+++ bにおける+++演算子は、接尾辞単項演算子とみなされます。
• If an operator has no whitespace on the left but is followed immediately by a dot (.), it’s treated as a postfix unary operator. As an example, the +++ operator in a+++.b is treated as a postfix unary operator (a+++ .b rather than a +++ .b). ある演算子が左側では空白を持たないが直ちに続けて１つのドット（.）を持つならば、それは接尾辞単項演算子と見なされます。例として、+++演算子はa+++.bにおいて、接尾辞単項演算子（a+++ .b、a +++ .bではなく）とみなされます。

For the purposes of these rules, the characters (, [, and { before an operator, the characters ), ], and } after an operator, and the characters ,, ;, and : are also considered whitespace. これらの規則を理由に、演算子の前の文字(、[、および{、演算子の後の文字)、]、および}、そして文字,、;、および:は、また、空白と見なされます。

There’s one caveat to the rules above. If the ! or ? predefined operator has no whitespace on the left, it’s treated as a postfix operator, regardless of whether it has whitespace on the right. To use the ? as the optional-chaining operator, it must not have whitespace on the left. To use it in the ternary conditional (? :) operator, it must have whitespace around both sides. １つのただし書きが、上の規則にあります。あらかじめ定義された演算子!または?が左側に空白を持たないならば、それは接尾辞演算子と見なされます、それが右側に空白を持つかどうかに関係なく。?をオプショナル連鎖演算子として使うには、それは左側に空白を持ってはなりません。それを三項条件（? :）において使うためには、それは両側に空白を持ってはなりません。

In certain constructs, operators with a leading < or > may be split into two or more tokens. The remainder is treated the same way and may be split again. As a result, you don’t need to add whitespace to disambiguate between the closing > characters in constructs like Dictionary<String, Array<Int>>. In this example, the closing > characters aren’t treated as a single token that may then be misinterpreted as a bit shift >> operator. 特定の構造物において、先導する<または>をもつ演算子は、２つ以上のトークンに分割されるでしょう。剰余は、同じ方法で扱われて、そして再び分割されるでしょう。その結果、あなたは空白を加えて閉じ>文字の間の曖昧さをなくす必要はありません、Dictionary<String, Array<Int>>のような構造物においては。この例において、閉じ>文字それらは、単一のトークンとして見なされることはなく、それでビットシフト演算子>>と誤解されることはありません。

To learn how to define new, custom operators, see Custom Operators and Operator Declaration. To learn how to overload existing operators, see Operator Methods. 新しい、あつらえの演算子を定義する方法を学ぶために、あつらえの演算子と演算子宣言を見てください。既存の演算子にオーバーロードする方法を学ぶために、演算子メソッドを見てください。