The lexical structure of Swift describes what sequence of characters form valid tokens of the language. These valid tokens form the lowest-level building blocks of the language and are used to describe the rest of the language in subsequent chapters. A token consists of an identifier, keyword, punctuation, literal, or operator.
スウィフトの語彙の構造は、どんな文字の連なりがこの言語の公式のトークン（個々の語、最少単位の語）を作り上げるかについて述べます。これらの公式のトークンは、言語の最も基本的な建物ブロックを形成して、以降の章において言語の残りの部分を記述するために使われます。あるトークンは１つの識別子、キーワード、句読点、リテラル、または演算子からなります。

In most cases, tokens are generated from the characters of a Swift source file by considering the longest possible substring from the input text, within the constraints of the grammar that are specified below. This behavior is referred to as longest match or maximal munch.
ほとんどの場合、トークンは、スウィフトのソースファイルの文字から、下で指定される文法の制約の範囲内で、その入力テキストからの最も長く取ることのできる下位文字列を考慮することによって生成されます。この挙動は、最長マッチまたは欲張り捕獲と呼ばれます。

Whitespace and Comments
空白とコメント

Whitespace has two uses: to separate tokens in the source file and to help determine whether an operator is a prefix or postfix (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.
コメントは、さらに追加の書式とマークアップを含む事が、マークアップ書式リファレンスで記述されるように可能です。

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文字もまた、許されます。

To use a reserved word as an identifier, put a backtick (`) before and after it. For example, class is not 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、などと名前をつけられます。これらの名前は、クロージャのスコープ内で有効な識別子です。

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, protocol, public, static, struct, subscript, typealias, and var.
  宣言において使用されるキーワード：associatedtype, class, deinit, enum, extension, fileprivate, func, import, init, inout, internal, let, open, operator, private, protocol, public, static, struct, subscript, typealias, そしてvar。

• Keywords used in statements: break, case, continue, default, defer, do, else, fallthrough, for, guard, if, in, repeat, return, switch, where, and while.
  文において使用されるキーワード：break, case, continue, default, defer, do, else, fallthrough, for, guard, if, in, repeat, return, switch, where, そしてwhile。

• Keywords used in expressions and types: as, Any, catch, false, is, nil, rethrows, super, self, Self, throw, throws, true, and try.
  式と型において使用されるキーワード：as, Any, catch, false, is, nil, rethrows, super, self, Self, throw, throws, true, そしてtry。

• Keywords used in patterns: _.
  パターンにおいて使用されるキーワード：_。

• Keywords that begin with a number sign (#): #available, #colorLiteral, #column, #else, #elseif, #endif, #file, #fileLiteral, #function, #if, #imageLiteral, #line, #selector, and #sourceLocation.
  番号記号（#）で始まるキーワード：#available, #colorLiteral, #column, #else, #elseif, #endif, #file, #fileLiteral, #function, #if, #imageLiteral, #line, #selector, そして #sourceLocation。

• Keywords reserved in particular contexts: associativity, convenience, dynamic, didSet, final, get, infix, indirect, lazy, left, mutating, none, nonmutating, optional, override, postfix, precedence, prefix, Protocol, required, right, set, Type, unowned, weak, and willSet. Outside the context in which they appear in the grammar, they can be used as identifiers.
  特定の前後関係において予約されるキーワード：associativity, convenience, dynamic, didSet, final, get, infix, indirect, lazy, left, mutating, none, nonmutating, optional, override, postfix, precedence, prefix, Protocol, required, right, set, 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 mark (!), postfix operators can’t begin with either a question mark or an exclamation mark.
あなたは疑問符（?）を含むあつらえの演算子を定義できるけれども、それは単一の疑問符文字だけから構成されることはできません。それに加えて、演算子は感嘆符（!）を含むことができますが、接尾辞演算子は、疑問符または感嘆符のどちらかで始まることはできません。

The whitespace around an operator is used to determine whether an operator is used as a prefix operator, a postfix operator, or a binary operator. This behavior is summarized in the following rules:
演算子のまわりの空白は、演算子が接頭辞演算子か、接尾辞演算子か、または二項演算子として使われるかを決定するために使われます。この挙動は、以下の規則において要約されます：

• If an operator has whitespace around both sides or around neither side, it’s treated as a binary operator. As an example, the +++ operator in a+++b and a +++ b is treated as a binary 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, there’s no need to use whitespace to disambiguate between the closing > characters in constructs like Dictionary<String, Array<Int>>. In this example, the closing > characters are not 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.
新しい、あつらえの演算子を定義する方法を学ぶために、あつらえの演算子と演算子宣言を見てください。既存の演算子にオーバーロードする方法を学ぶために、演算子メソッドを見てください。