std :: initializer_listが組み込み言語ではないのはなぜですか？

std::initializer_listコア言語が組み込まれていないのはなぜですか？

これはC ++ 11の非常に重要な機能であり、独自の予約済みキーワード（または同様のもの）がないように思えます。

代わりに、initializer_listそれはだだけで、特別な、暗黙の持っている標準ライブラリのテンプレートクラスのマッピング新しいからブレース-のinit-リスト {...}コンパイラによって処理の構文を。

最初は、このソリューションはかなりハックです。

これは、C ++言語への新しい追加が実装される方法ですか？コア言語ではなく、いくつかのテンプレートクラスの暗黙のロールによって？

これらの例を検討してください：

   widget<int> w = {1,2,3}; //this is how we want to use a class

新しいクラスが選ばれた理由：

   widget( std::initializer_list<T> init )

これらのアイデアのいずれかに類似したものを使用する代わりに：

   widget( T[] init, int length )  // (1)
   widget( T... init )             // (2)
   widget( std::vector<T> init )   // (3)

1. 古典的な配列、おそらくconstあちこちに追加できます
2. 言語にはすでに3つのドット（var-args、現在は可変テンプレート）があります。構文を再利用してください（組み込みのように感じてください）。
3. 既存のコンテナだけを追加してconst、&

それらのすべてはすでに言語の一部です。私は最初の3つのアイデアを書いただけで、他にも多くのアプローチがあると確信しています。

std名前空間で定義された型を返す「コア」言語機能の例はすでにありました。typeidが返されstd::type_info、（おそらくポイントを伸ばす）sizeofが返されますstd::size_t。

前者の場合、このいわゆる「コア言語」機能を使用するには、すでに標準ヘッダーを含める必要があります。

現在、イニシャライザリストの場合、オブジェクトを生成するためにキーワードは必要ありません。構文は状況に応じた中括弧です。それ以外はと同じtype_infoです。個人的には、キーワードがないことで「もっとハッキー」になるとは思いません。もう少し意外かもしれませんが、その目的は、集計で既に許可されているのと同じ中かっこで初期化された構文を許可することでした。

したがって、はい、おそらくこの設計原則は今後さらに期待できるでしょう。

• 新しいキーワードなしで新しい機能を導入することが可能な機会がさらに発生した場合、委員会がそれらを採用します。
• 新しい機能が複雑なタイプを必要とする場合、それらのタイプはstd組み込みではなく配置されます。

したがって：

• 新しい機能が複雑なタイプを必要とし、新しいキーワードなしで導入できる場合は、ここにあるものが得られます。これは、新しいキーワードのない「コア言語」構文であり、からのライブラリタイプを使用しますstd。

結局のところ、C ++には「コア言語」と標準ライブラリの間の絶対的な分割がないということです。それらは規格では異なる章ですが、それぞれが他を参照しており、常にそうです。

C ++ 11には別のアプローチがあります。ラムダは、コンパイラーによって生成された匿名型を持つオブジェクトを導入するというものです。名前がないため、名前空間にはありませんstd。確かににはありません。ただし、初期化子リストを受け入れるコンストラクターを作成するときに型名を使用するため、これは初期化子リストに適した方法ではありません。

C ++標準委員会は、新しいキーワードを追加しないことを好むようです。これはおそらく、既存のコードを破壊するリスクが高まるためです（レガシーコードでは、そのキーワードを変数やクラスなどの名前として使用できます）。

さらに、std::initializer_listテンプレート化されたコンテナとして定義することは非常に洗練された選択であるように私には思えます。どのように反復しますか？多くの新しい演算子も必要になるので、標準のコンテナで実行できるのと同じことを実行するには、より多くの名前とキーワードを覚える必要があります。

をstd::initializer_list他のコンテナーとして扱うことで、それらのいずれかで機能する汎用コードを作成する機会が得られます。

更新：

次に、既存の組み合わせを使用するのではなく、なぜ新しいタイプを導入するのですか？（コメントより）

そもそも、他のすべてのコンテナには、要素を追加、削除、および配置するためのメソッドがありますが、これらは、コンパイラが生成したコレクションには望ましくありません。唯一の例外はでstd::array<>、これは固定サイズのCスタイルの配列をラップするため、唯一の妥当な候補となります。

ただし、Nicol Bolasがコメントで正しく指摘しているように、と他のstd::initializer_listすべての標準コンテナ（を含むstd::array<>）のもう1つの根本的な違いは、後者は値のセマンティクスをstd::initializer_list持ち、参照セマンティクスは持っているということです。コピーstd::initializer_list、例えば、それが含まれている要素のコピーが発生することはありません。

さらに（ここでも、Nicol Bolasの好意により）、ブレース初期化リスト用の特別なコンテナがあると、ユーザーが初期化を実行する方法でオーバーロードが可能になります。

これは新しいことではありません。たとえば、クラス内の特定のメソッドまたはスタンドアロン関数の存在にfor (i : some_container)依存していsome_containerます。C＃は、.NETライブラリにさらに依存しています。実際、これは非常に洗練されたソリューションだと思います。言語仕様を複雑にすることなく、クラスをいくつかの言語構造と互換性があるからです。

これは確かに新しいものではなく、いくつ指摘されていますが、このプラクティスはC ++にもあり、たとえばC＃にもあります。

Andrei Alexandrescuはこれについて良い点を述べました：あなたはそれを架空の「コア」名前空間の一部として考えるかもしれません、そしてそれはもっと理にかなっています。

：だから、それは実際のようなものだcore::initializer_list、core::size_t、core::begin()、core::end()とのようにします。これは、std名前空間にいくつかのコア言語構成要素が含まれているという残念な偶然です。

標準ライブラリで完全に機能するだけでなく、標準ライブラリに含まれていても、コンパイラが巧妙なトリックを実行できないわけではありません。

このタイプはよく知られているか、単純なタイプであり、を無視しinitializer_listて、初期化された値のメモリイメージを保持することができます。

言い換えると、取るに足らないコンストラクタを持つintの単純なラッパークラスint i {5};と同等int i(5);か、int i=5;またはintwrapper iw {5};Where intwrapperでさえも可能です。initializer_list

それは、ライブラリに完全に実装することができますので、ちょうどラインコア言語の一部ではありませんoperator newとoperator delete。コンパイラを組み込むのがより複雑になると、どのような利点がありますか？