Lexical Structure

語彙構造

下記URLから引用し、日本語訳をつけてみました

https://docs.swift.org/swift-book/documentation/the-swift-programming-language/lexicalstructure

Use the lowest-level components of the syntax.

構文の最下位レベルのコンポーネントを使用します。

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.

Swift の語彙構造は、どの文字シーケンスが言語の有効なトークンを形成するかを記述します。 これらの有効なトークンは、言語の最下位レベルの構成要素を形成し、後続の章で言語の残りの部分を説明するために使用されます。 トークンは、識別子、キーワード、句読点、リテラル、または演算子で構成されます。

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.

ほとんどの場合、トークンは、以下で指定する文法の制約内で、入力テキストから可能な限り長い部分文字列を考慮することによって、Swift ソース ファイルの文字から生成されます。 この動作は、最長一致または最大ムッチと呼ばれます。

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).

ホワイトスペースには 2 つの用途があります。ソース ファイル内のトークンを区切る目的と、前置演算子、後置演算子、および中置演算子を区別するためです (「演算子」を参照)。それ以外の場合は無視されます。 次の文字は空白とみなされます: スペース (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(Link:developer.apple.com).

「マークアップ書式設定リファレンス(Link:developer.apple.com)（英語）」で説明されているように、コメントには追加の書式設定とマークアップを含めることができます。

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, subscripts whose first argument label begins with an underscore, and initializers whose first argument label begins 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 の一部をマークできます。 さらに、2 つのアンダースコアで始まる識別子は、Swift コンパイラーと標準ライブラリ用に予約されています。

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.

• Keywords used in statements: break, case, catch, continue, default, defer, do, else, fallthrough, for, guard, if, in, repeat, return, throw, switch, where, and while.
• Keywords used in expressions and types: Any, as, await, catch, false, is, nil, rethrows, self, Self, super, throw, throws, true, and try.
• Keywords used in patterns: _.
• Keywords that begin with a number sign (#): #available, #colorLiteral, #elseif, #else, #endif, #fileLiteral, #if, #imageLiteral, #keyPath, #selector, #sourceLocation.

• 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.

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:

リテラルの例を次に示します。

42               // Integer literal
3.14159          // Floating-point literal
"Hello, world!"  // String literal
/Hello, .*/      // Regular expression literal
true             // Boolean literal

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 and listed in the table below. 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 the Swift standard library protocols listed in the table below.

リテラルにはそれ自体の型がありません。 代わりに、リテラルは無限の精度を持つものとして解析され、Swift の型推論はリテラルの型を推論しようとします。 たとえば、let x: Int8 = 42 という宣言では、Swift は明示的な型アノテーション (: Int8) を使用して、整数リテラル 42 の型が Int8 であると推論します。 適切な型情報が利用できない場合、Swift はリテラルの型が、Swift 標準ライブラリで定義され、以下の表にリストされているデフォルトのリテラル型の 1 つであると推測します。 リテラル値の型アノテーションを指定する場合、アノテーションの型は、そのリテラル値からインスタンス化できる型である必要があります。 つまり、型は、以下の表にリストされている Swift 標準ライブラリ プロトコルに準拠する必要があります。

For example, in the declaration let str = "Hello, world", the default inferred type of the string literal "Hello, world" is String. Also, 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.

たとえば、let str = "Hello, world" という宣言では、文字列リテラル"Hello, world"のデフォルトの推論型は String です。 また、Int8 は ExpressibleByIntegerLiteral プロトコルに準拠しているため、宣言 let x: Int8 = 42 内の整数リテラル 42 の型アノテーションで使用できます。

Integer Literals

整数リテラル

Integer literals represent integer values of unspecified precision. By default, integer literals are expressed in decimal; you can specify an alternate base using a prefix. Binary literals begin with 0b, octal literals begin with 0o, and hexadecimal literals begin with 0x.

整数リテラルは、精度が指定されていない整数値を表します。 デフォルトでは、整数リテラルは 10 進数で表現されます。 プレフィックスを使用して代替ベースを指定できます。 2 進数リテラルは 0b で始まり、8 進数リテラルは 0o で始まり、16 進数リテラルは 0x で始まります。

Decimal literals contain the digits 0 through 9. Binary literals contain 0 and 1, octal literals contain 0 through 7, and hexadecimal literals contain 0 through 9 as well as A through F in upper- or lowercase.

10 進数リテラルには 0 から 9 までの数字が含まれます。2 進数リテラルには 0 と 1 が含まれ、8 進数リテラルには 0 から 7 が含まれ、16 進数リテラルには 0 から 9 と、大文字または小文字の A から F が含まれます。

Negative integers literals are expressed by prepending a minus sign (-) to an integer literal, as in -42.

負の整数リテラルは、-42 のように、整数リテラルの前にマイナス記号 (-) を追加することで表現されます。

Underscores (_) are allowed between digits for readability, but they’re ignored and therefore don’t affect the value of the literal. Integer literals can begin with leading zeros (0), but they’re likewise ignored and don’t affect the base or value of the literal.

読みやすくするために数字の間にアンダースコア (_) を使用できますが、アンダースコア (_)は無視されるため、リテラルの値には影響しません。 整数リテラルは先頭にゼロ (0)を付けることができますが、同様に無視され、リテラルの基数や値には影響しません。

Unless otherwise specified, the default inferred type of an integer literal is the Swift standard library type Int. The Swift standard library also defines types for various sizes of signed and unsigned integers, as described in Integers.

特に指定がない限り、整数リテラルのデフォルトの推論型は、Swift 標準ライブラリの型 Int です。 Swift 標準ライブラリでは、「整数」で説明されているように、さまざまなサイズの符号付き整数と符号なし整数の型も定義されています。

Floating-Point Literals

浮動小数点リテラル

Floating-point literals represent floating-point values of unspecified precision.

浮動小数点リテラルは、精度が指定されていない浮動小数点値を表します。

By default, floating-point literals are expressed in decimal (with no prefix), but they can also be expressed in hexadecimal (with a 0x prefix).

デフォルトでは、浮動小数点リテラルは 10 進数 (接頭辞なし) で表現されますが、16 進数 (0x 接頭辞付き) で表現することもできます。

Decimal floating-point literals consist of a sequence of decimal digits followed by either a decimal fraction, a decimal exponent, or both. The decimal fraction consists of a decimal point (.) followed by a sequence of decimal digits. The exponent consists of an upper- or lowercase e prefix followed by a sequence of decimal digits that indicates what power of 10 the value preceding the e is multiplied by. For example, 1.25e2 represents 1.25 x 10², which evaluates to 125.0. Similarly, 1.25e-2 represents 1.25 x 10⁻², which evaluates to 0.0125.

10 進浮動小数点リテラルは、一連の 10 進数と、それに続く小数部、小数部の指数、またはその両方で構成されます。 小数部は、小数点 (.) とそれに続く一連の 10 進数で構成されます。 指数は、大文字または小文字の e の接頭辞と、それに続く e の前の値に 10 の何乗を乗算するかを示す 10 進数のシーケンスで構成されます。 たとえば、1.25e2 は 1.25 x 10² を表し、125.0 と評価されます。 同様に、1.25e-2 は 1.25 x 10⁻² を表し、0.0125 と評価されます。

Hexadecimal floating-point literals consist of a 0x prefix, followed by an optional hexadecimal fraction, followed by a hexadecimal exponent. The hexadecimal fraction consists of a decimal point followed by a sequence of hexadecimal digits. The exponent consists of an upper- or lowercase p prefix followed by a sequence of decimal digits that indicates what power of 2 the value preceding the p is multiplied by. For example, 0xFp2 represents 15 x 2², which evaluates to 60. Similarly, 0xFp-2 represents 15 x 2⁻², which evaluates to 3.75.

16 進浮動小数点リテラルは、0x 接頭辞、その後にオプションの 16 進数、その後に 16 進指数が続きます。 16 進数は、小数点とそれに続く一連の 16 進数で構成されます。 指数は、大文字または小文字の p の接頭辞と、その後に続く一連の 10 進数で構成され、p の前の値に 2 の累乗を乗算することを示します。 たとえば、0xFp2 は 15 x 2² を表し、60 と評価されます。同様に、0xFp-2 は 15 x 2⁻² を表し、3.75 と評価されます。

Negative floating-point literals are expressed by prepending a minus sign (-) to a floating-point literal, as in -42.5.

負の浮動小数点リテラルは、-42.5 のように、浮動小数点リテラルの前にマイナス記号 (-) を追加することで表現されます。

Underscores (_) are allowed between digits for readability, but they’re ignored and therefore don’t affect the value of the literal. Floating-point literals can begin with leading zeros (0), but they’re likewise ignored and don’t affect the base or value of the literal.

読みやすくするために数字の間にアンダースコア (_) を使用できますが、アンダースコア (_) は無視されるため、リテラルの値には影響しません。 浮動小数点リテラルは先頭にゼロ (0) を付けることができますが、同様に無視され、リテラルの基数や値には影響しません。

Unless otherwise specified, the default inferred type of a floating-point literal is the Swift standard library type Double, which represents a 64-bit floating-point number. The Swift standard library also defines a Float type, which represents a 32-bit floating-point number.

特に指定がない限り、浮動小数点リテラルのデフォルトの推論型は、64 ビット浮動小数点数を表す Swift 標準ライブラリ型 Double です。 Swift 標準ライブラリでは、32 ビット浮動小数点数を表す Float 型も定義されています。

String Literals

文字列リテラル

A string literal is a sequence of characters surrounded by quotation marks. A single-line string literal is surrounded by double quotation marks and has the following form:

文字列リテラルは、引用符で囲まれた一連の文字です。 単一行の文字列リテラルは二重引用符で囲まれ、次の形式になります。

"<#characters#>"

String literals can’t contain an unescaped double quotation mark ("), an unescaped backslash (\), a carriage return, or a line feed.

文字列リテラルには、エスケープされていない二重引用符 (")、エスケープされていないバックスラッシュ (\)、キャリッジ リターン、またはライン フィードを含めることはできません。

A multiline string literal is surrounded by three double quotation marks and has the following form:

複数行の文字列リテラルは 3 つの二重引用符で囲まれ、次の形式になります。

"""
<#characters#>
"""

Unlike a single-line string literal, a multiline string literal can contain unescaped double quotation marks ("), carriage returns, and line feeds. It can’t contain three unescaped double quotation marks next to each other.

単一行の文字列リテラルとは異なり、複数行の文字列リテラルには、エスケープされていない二重引用符 (")、復帰、改行を含めることができます。エスケープされていない二重引用符を 3 つ並べて含めることはできません。

The line break after the """ that begins the multiline string literal isn’t part of the string. The line break before the """ that ends the literal is also not part of the string. To make a multiline string literal that begins or ends with a line feed, write a blank line as its first or last line.

複数行の文字列リテラルを開始する """ の後の改行は文字列の一部ではありません。リテラルを終了する """ の前の改行も文字列の一部ではありません。 改行で始まるか終わる複数行の文字列リテラルを作成するには、最初または最後の行に空行を記述します。

A multiline string literal can be indented using any combination of spaces and tabs; this indentation isn’t included in the string. The """ that ends the literal determines the indentation: Every nonblank line in the literal must begin with exactly the same indentation that appears before the closing """; there’s no conversion between tabs and spaces. You can include additional spaces and tabs after that indentation; those spaces and tabs appear in the string.

複数行の文字列リテラルは、スペースとタブを任意に組み合わせてインデントできます。 このインデントは文字列には含まれません。 リテラルを終了する """ によってインデントが決まります。リテラル内の空白以外の行は、終了の """ の前に表示されるのとまったく同じインデントで始まる必要があります。タブとスペースの間の変換はありません。 インデントの後に追加のスペースやタブを含めることができます。 これらのスペースとタブは文字列内に表示されます。

Line breaks in a multiline string literal are normalized to use the line feed character. Even if your source file has a mix of carriage returns and line feeds, all of the line breaks in the string will be the same.

複数行の文字列リテラル内の改行は、改行文字を使用するように正規化されます。 ソース ファイルにキャリッジ リターンとライン フィードが混在している場合でも、文字列内の改行はすべて同じになります。

In a multiline string literal, writing a backslash (\) at the end of a line omits that line break from the string. Any whitespace between the backslash and the line break is also omitted. You can use this syntax to hard wrap a multiline string literal in your source code, without changing the value of the resulting string.

複数行の文字列リテラルでは、行末にバックスラッシュ (\) を記述すると、文字列からの改行が省略されます。 バックスラッシュと改行の間の空白も省略されます。 この構文を使用すると、結果の文字列の値を変更せずに、ソース コード内で複数行の文字列リテラルをハード ラップすることができます。

Special characters can be included in string literals of both the single-line and multiline forms using the following escape sequences:

次のエスケープ シーケンスを使用すると、単一行形式と複数行形式の両方の文字列リテラルに特殊文字を含めることができます。

• Null character (\0)
• Backslash (\\)
• Horizontal tab (\t)
• Line feed (\n)
• Carriage return (\r)
• Double quotation mark (\")
• Single quotation mark (\')
• Unicode scalar (\u{n}), where n is a hexadecimal number that has one to eight digits

The value of an expression can be inserted into a string literal by placing the expression in parentheses after a backslash (\). The interpolated expression can contain a string literal, but can’t contain an unescaped backslash, a carriage return, or a line feed.

式の値を文字列リテラルに挿入するには、バックスラッシュ (\) の後の括弧内に式を置きます。 補間された式には文字列リテラルを含めることができますが、エスケープされていないバックスラッシュ、キャリッジ リターン、またはライン フィードを含めることはできません。

For example, all of the following string literals have the same value:

たとえば、次の文字列リテラルはすべて同じ値を持ちます。

"1 2 3"
"1 2 \("3")"
"1 2 \(3)"
"1 2 \(1 + 2)"
let x = 3; "1 2 \(x)"

A string delimited by extended delimiters is a sequence of characters surrounded by quotation marks and a balanced set of one or more number signs (#). A string delimited by extended delimiters has the following forms:

拡張区切り文字で区切られた文字列は、引用符と 1 つ以上のシャープ記号 (#) のバランスの取れたセットで囲まれた一連の文字です。 拡張区切り文字で区切られた文字列の形式は次のとおりです。

#"<#characters#>"#


#"""
<#characters#>
"""#

Special characters in a string delimited by extended delimiters appear in the resulting string as normal characters rather than as special characters. You can use extended delimiters to create strings with characters that would ordinarily have a special effect such as generating a string interpolation, starting an escape sequence, or terminating the string.

拡張区切り文字で区切られた文字列内の特殊文字は、結果の文字列では特殊文字ではなく通常の文字として表示されます。 拡張区切り文字を使用すると、文字列補間の生成、エスケープ シーケンスの開始、文字列の終了など、通常は特別な効果を持つ文字を含む文字列を作成できます。

The following example shows a string literal and a string delimited by extended delimiters that create equivalent string values:

次の例は、文字列リテラルと、同等の文字列値を作成する拡張区切り文字で区切られた文字列を示しています。

let string = #"\(x) \ " \u{2603}"#
let escaped = "\\(x) \\ \" \\u{2603}"
print(string)
// Prints "\(x) \ " \u{2603}"
print(string == escaped)
// Prints "true"

If you use more than one number sign to form a string delimited by extended delimiters, don’t place whitespace in between the number signs:

複数のシャープ記号を使用して拡張区切り文字で区切られた文字列を形成する場合は、シャープ記号の間に空白を入れないでください。

print(###"Line 1\###nLine 2"###) // OK
print(# # #"Line 1\# # #nLine 2"# # #) // Error

Multiline string literals that you create using extended delimiters have the same indentation requirements as regular multiline string literals.

拡張区切り文字を使用して作成した複数行の文字列リテラルには、通常の複数行文字列リテラルと同じインデント要件があります。

The default inferred type of a string literal is String. For more information about the String type, see Strings and Characters and String(Link:developer.apple.com).

文字列リテラルのデフォルトの推論型は String です。String タイプの詳細については、「文字列と文字」および「String(Link:developer.apple.com)（英語）」を参照してください。

String literals that are concatenated by the + operator are concatenated at compile time. For example, the values of textA and textB in the example below are identical — no runtime concatenation is performed.

 + 演算子によって連結された文字列リテラルは、コンパイル時に連結されます。 たとえば、以下の例の textA と textB の値は同一です。実行時連結は実行されません。

let textA = "Hello " + "world"
let textB = "Hello world"

Regular Expression Literals

正規表現リテラル

A regular expression literal is a sequence of characters surrounded by slashes (/) with the following form:

正規表現リテラルは、次の形式のスラッシュ (/) で囲まれた一連の文字です。

/<#regular expression#>/

Regular expression literals must not begin with an unescaped tab or space, and they can’t contain an unescaped slash (/), a carriage return, or a line feed.

正規表現リテラルは、エスケープされていないタブまたはスペースで始まることはできません。また、エスケープされていないスラッシュ (/)、キャリッジ リターン、またはライン フィードを含めることはできません。

Within a regular expression literal, a backslash is understood as a part of that regular expression, not just as an escape character like in string literals. It indicates that the following special character should be interpreted literally, or that the following nonspecial character should be interpreted in a special way. For example, /\(/ matches a single left parenthesis and /\d/ matches a single digit.

正規表現リテラル内では、バックスラッシュは文字列リテラルのようなエスケープ文字としてだけでなく、その正規表現の一部として理解されます。 これは、次の特殊文字を文字通りに解釈する必要があること、または次の非特殊文字を特別な方法で解釈する必要があることを示します。 たとえば、 /\(/ は 1 つの左括弧に一致し、 /\d/ は 1 つの数字に一致します。

A regular expression literal delimited by extended delimiters is a sequence of characters surrounded by slashes (/) and a balanced set of one or more number signs (#). A regular expression literal delimited by extended delimiters has the following forms:

拡張区切り文字で区切られた正規表現リテラルは、スラッシュ (/) と 1 つ以上のシャープ記号 (#) で囲まれた一連の文字です。 拡張区切り文字で区切られた正規表現リテラルの形式は次のとおりです。

#/<#regular expression#>/#


#/
<#regular expression#>
/#

A regular expression literal that uses extended delimiters can begin with an unescaped space or tab, contain unescaped slashes (/), and span across multiple lines. For a multiline regular expression literal, the opening delimiter must be at the end of a line, and the closing delimiter must be on its own line. Inside a multiline regular expression literal, the extended regular expression syntax is enabled by default — specifically, whitespace is ignored and comments are allowed.

拡張区切り文字を使用する正規表現リテラルは、エスケープされていないスペースまたはタブで始まり、エスケープされていないスラッシュ (/) を含み、複数行にまたがることができます。 複数行の正規表現リテラルの場合、開始区切り文字は行の末尾にあり、終了区切り文字は独自の行にある必要があります。 複数行の正規表現リテラル内では、拡張正規表現構文がデフォルトで有効になっています。具体的には、空白は無視され、コメントが許可されます。

If you use more than one number sign to form a regular expression literal delimited by extended delimiters, don’t place whitespace in between the number signs:

複数のシャープ記号を使用して拡張区切り文字で区切られた正規表現リテラルを形成する場合は、シャープ記号の間に空白を入れないでください。

let regex1 = ##/abc/##       // OK
let regex2 = # #/abc/# #     // Error

If you need to make an emptacy regular expression literal, you must use the extended delimiter syntax.

空の正規表現リテラルを作成する必要がある場合は、拡張区切り文字構文を使用する必要があります。

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.

Swift 標準ライブラリでは、使用できる多数の演算子が定義されており、その多くは基本的な演算子と高度な演算子で説明されています。 このセクションでは、カスタム演算子の定義に使用できる文字について説明します。

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 文字 /、=、-、+、!、*、%、<、>、&、|、^、?、または ~ のいずれか、または以下の文法で定義されている Unicode 文字の 1 つで始めることができます。 （これには、数学演算子、その他の記号、Dingbats Unicode ブロックの文字などが含まれます）。 最初の文字の後には、Unicode 文字を組み合わせることもできます。

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.

これらのルールでは、演算子の前の文字 (、[、および {、演算子の後の文字)、]、および }、および文字,, ;, および: も空白とみなされます。

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.

もし！ または ？の 事前定義された演算子の左側に空白がない場合、右側に空白があるかどうかに関係なく、後置演算子として扱われます。 ?をオプションの連鎖演算子として使用するには 、左側に空白を含めることはできません。 三項条件演算子 (? :) で使用するには、両側に空白が必要です。

If one of the arguments to an infix operator is a regular expression literal, then the operator must have whitespace around both sides.

中置演算子の引数の 1 つが正規表現リテラルである場合、演算子の両側には空白が必要です。

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.

特定の構成では、先頭に < または > がある演算子が 2 つ以上のトークンに分割される場合があります。 残りも同様に扱われ、再度分割される場合があります。 その結果、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.

新しいカスタム演算子を定義する方法については、「カスタム演算子」と「演算子の宣言」をご覧ください。 既存の演算子をオーバーロードする方法については、「演算子メソッド」を参照してください。