タイプ特性はかっこいいです、そして、それらが数年前にブーストで始まったので、私はそれらを使いました。ただし、それらの実装を見ると（「仕組みis_base_of」 StackOverflowスレッドを確認してください）。
なぜコンパイラはここで役に立たないのですか？たとえば、あるクラスが別のクラスのベースであるかどうかを確認したい場合、コンパイラはすでにそれを知っていますが、なぜそれが私たちに教えてくれないのですか？これにより、概念などの実装と使用が非常に簡単になります。そこで言語構造を使用できます。
よくわかりませんが、一般的なパフォーマンスが向上すると思います。これは、C ++言語ではなく、コンパイラに助けを求めるようなものです。
主な理由は「下位互換性を維持する必要がある」のように聞こえるかもしれませんが、同意しますが、なぜコンパイラは汎用テンプレートコードの生成にもっと積極的にならないのでしょうか。
実は...そうする人もいます。
重要なのは、純粋なC ++コードで何かを実装できる場合、コードを単純化する以外に、コンパイラーにそれらを配線する理由はないということです。それはトレードオフの問題ですが、コードの単純化によってもたらされる価値は、ハードワイヤリングの価値がありますか？
これはいくつかの点に依存します：
これらすべてのポイントが重み付けされたら、ライブラリまたはコンパイラに物を置く方が有利かどうかを判断できます。そして、より可能性の高い状況は、混合戦略になってしまうことです。ライブラリに必要なインターフェイスを提供するためのビルディングブロックとして使用されるコンパイラのいくつかの組み込み関数です。
コンパイラではメンテナンスの負担がはるかに大きいことに注意してください。言語に精通しているC++開発者なら誰でもライブラリの実装を詳しく調べることができますが、コンパイラコードはブラックボックスです。したがって、コンパイラよりもライブラリのデバッグとパッチ適用がはるかに簡単になるため、非常に正当な理由がない限り、コンパイラに物を入れないようにするインセンティブがあります。
ここで客観的な答えを出すのは難しいですが、次のように思います。
それは基本的に「壊れていないものを直さない」という考え方です。
型特性に対するコンパイラのヘルプは、常に設計目標でした。TR1は正式に型特性を導入し、ストレートC ++で型特性を記述できるようにするために、場合によっては許容できる誤った結果を説明するセクションを含めました。これらの型特性がC++11に追加されたとき（それらの実装に影響を与えないいくつかの名前の変更を伴う）、誤った結果の許容が削除され、それらのいくつかを実装するためにコンパイラーの助けが事実上必要になりました。また、ストレートC ++で実装できるものであっても、コンパイラの作成者は複雑なテンプレートよりも組み込み関数を好むため、過労のコンパイラによってコンピュータが溶けてしまうため、スラグをキャッチするためにドリップパンをコンピュータの下に置く必要がありません。