9.字句構造

9.1 トークン

9.1.1 識別子

　標準C++ の文法ではしかるべき場所で識別子を受け入れてはいません。 しかし、C++/CLI は、特別な意味を持っているこれらの識別子によって、それらの場所での識別子のセットを定義することを許しています。 ［注意：そのような識別子は口語的に文脈依存キーワードとして言及されています。そうでなければ、それらは識別子なのです。］ 一定の文脈上で特殊な意味づけをもたらす識別子は次の通りです。

abstract	delegate	event	finally	generic	in
initonly	internal	literal	override	property	sealed
where

　文法上で参照されたとき、これらの識別子はidentifier文法生成を使うよりも明示的に使われます。 識別子が意味を持つことを保証するのは、構文上のチェックよりも、むしろ意味論的チェックになります。 トークンが識別子であると取られたときになんの適切なパースがなかったとき、その時にのみ、与えられたコンテキスト中において識別子はキーワードであるとみなされます。それはつまり、トークンが識別子になれるとき、それは識別子となります。
　いくつかの名称パターンはしかるべきコンテキストの関数名として予約されています。（§19.2 、§19.7.5 ）
　トークン generic が見つかると、もし、トークン :: に先んじており、続けてトークン < 、そして、キーワード class か typename がある時のみ、generic は特別な意味を持つことになります。［注意：稀なケースですが、正規な標準 C++ プログラムとして、generic に続いて < 続いて class となるトークン列が含まれることが、generic が型の名前として記述されているような場合で、あり得ます。例えば、

template<typename T> struct generic {
    typedef int I;
};
class X {};
generic<class X> x1;
generic<class X()> x2;

　そのような場合には、generic が型の名前であることを示すよう、typename を使ってください。

typename generic<class X> x1;
typename generic<class X()> x2;

　もしくは、これらの特殊な場合には、別の表記としてキーワード class を（elaborated-type-specifier を使わないように）取り除いても良いでしょう。例えば、

generic<X> x1;
generic<X()> x2;

］
　typename を言及する elaborated-type-specifier（標準 C++ § 7.1.5.3、§ 14.6、§ A.6 ） の構文生成は、二つの適切な生成の最初のものを随意に nested-name-specifier とするために、次のように拡張されています。
［注意：標準 C++ の改訂が現在進んでおり、この生成物もその改訂の提出によって変更を加えます。］
　attributes は§29 に記述されています。
　標準 C++ （§ 14.6/3）は以下のように訂正されます。
　そして、§ 14.6/5 は削除されます。
［注意：typename の存在は、指定をしないと property :: X x; のように曖昧になってしまう場合に、プログラマに曖昧さの排除を強いています。宣言 property :: X x; は標準C++ が認識するとおり、property::X 型のメンバ変数 x を宣言します。トークン列 property typename :: X x; は ::X という型のプロパティをxと言う名前で宣言します。］
　array, interior_ptr, pin_ptr, または、safe_cast のどれかの名前解決を行ってその名前を見つけられなかったとき、そして、その名前に左括弧が続かなかった場合、その名前は cli:: で修飾されているものとして解釈され、名前空間 ::cli にその名前を見つけるべく名前解決を継続します。
　array, interior_ptr, pin_ptr, または、safe_cast のどれかの名前解決を行ってその名前を名前空間 ::cli に見つけたとき、その名前は通常の識別子ではなく、この標準に記述されている特殊な意味を持っています。
　識別子でないトークンは識別子として使うことも可能です。これは __identifier(T) 、T は識別子、キーワード、または文字列リテラルである、を通して仕立てます。文字列リテラル形式は C++/CLI 実装に使うために予約されています。この構成物は最初の、そして、ただ一つの識別子として #define プリプロセッサ命令中に配置するべきではありません。［例：

     __identifier(totalCost)
     __identifier(delete)
     __identifier("<Special Name #3>")

］

9.1.2 キーワード

　以下のキーワードが標準 C++ （§2.11 ）に追加されています。

enum#class	enum#struct	for#each	gcnew
interface#class	interface#struct	nullptr	ref#class
ref#struct	value#class	value#struct

　シンボル # はキーワード中に現れる空白を指し示す文法のために使われています。変換フェーズ１の後のプログラム・テキスト中に現れる任意の空白がシンボル # の場所に配置されることが許されています。シンボル # の場所に配置されることが許された空白がコメントやドキュメント・コメント、マクロによって生成されたものかどうかは問題ではありません。次に示す変換フェイズ４で # を含むトークンが一つのキーワードであるとされます。［注意：# シンボルは言語の文法の中でのみ使われています。例には正規なプログラムが要請している空白が含まれています。］［注意：# シンボルを含むキーワードはマクロによって生成することができますが、決してマクロ名であるとは認識されておりません。］
　標準C++ （§2.1/4 ）の変換フェイズ４は以下のように拡張されています。
　文法中の多くの場所で、特定の識別子は特別な意味を持っていますが、キーワードではありません。［注意：例えば、仮想関数宣言の中で、識別子 abstract と sealed は特別な意味を持っています。通常、ユーザー定義識別子は決してそのような場所には認められていませんが、これはこれらの言葉を識別子として衝突することなく使用しています。これら特殊な識別子の完全なリストは§9.1.1 を見てください。］

9.1.3 リテラル

　標準 C++ のリテラルに関する文法（§2.13 ）は以下のように拡張されています。

9.1.3.1 整数リテラル

　long long int と unsigned long long int 型を協調して追加するために、標準 C++ （§2.13.1）中の整数後置子は以下のように拡張されます。

　標準 C++ （§2.13.1/2）は以下のように変更されます。
　拡張整数型を協調して追加するために、標準 C++ （§2.13.1/3）は以下のように変更されます。

9.1.3.2 null リテラル

　null literal （null リテラル）は null 型（§12.3.4 ）であるキーワード nullptr です。 nullptr は null 値定数を表しており、ユニーク（一意な）存在です。このリテラルは左辺値にはなりません。
　null 値定数は、結果が null ハンドルとなるよう、任意のハンドル型に変換可能です。 null 値定数は、また、結果が null ポインタとなるよう、任意のポインタ型にも変換可能です。

9.1.3.3 文字列リテラル

　標準 C++（§2.13.4/1）は以下のように変更されます。

9.1.4 演算子と強調子

　C++/CLI はテンプレートとジェネリック・コンストラクタ、List<List<int>> のような、>> が一つではなく二つのトークンである、表現が許されていることを要求しています。 これは標準 C++ でこれを仕様規定している節 §15.3 , §30.1 そして、§30.2 の数多くの部分への変更を要請します。
　標準 C++ (§2.1/1 )、変換フェーズ７は、すでに存在する注記に優先して、以下のような文章を追加することが議論されています。