なぜC ++はDのアプローチをその概念の実装に採用できないのですか？

あなたの多くが知っているように、テンプレート引数の可能な型を制限するためのC ++のアプローチ、概念、C ++ 11には含まれていませんでした。

Dプログラミング言語2.0には、一般的なプログラミングと同様の機能があることがわかりました。その解決策は私には非常にエレガントでシンプルなようです。

私の質問は、C ++が同様のアプローチを使用できない理由です。

• C ++の概念の目標は、Dの実装が提供するものよりも大きいでしょうか？
• または、C ++のレガシーにより、そのようなアプローチを採用できませんか？
• または他の？

ご回答ありがとうございます。

ps Dの汎用プログラミングパワーの例を参照するには、これを参照してください：https : //stackoverflow.com/questions/7300298/metaprogramming-in-c-and-in-d/7303534#7303534

C ++の標準は規範的なドキュメントであり、将来のドキュメントに残る（ほとんど影響を受けない）ルールを設定します。そのため、委員会はその更新に関して非常に慎重なアプローチを取っています。

標準ライブラリへの追加はいくぶん簡単でした。長い間、多くのライブラリがBoostにありました。それらが機能していることが証明されていました。

ただし、言語の中核概念への追加は、最初にコンパイラの変更が必要になるため、実験がはるかに困難です。C ++ 03機能（テンプレートのエクスポート）がコンパイラのサポートなしで指定されていました...結果は恐ろしいものでした。EDGコンパイラフロントエンドの実装者は、それを非常にわずかな利益で大規模なタスク（数人年）として報告しました。他のコンパイラはこれを実装しようとしませんでした。それは快適な状況ではありません。

constexprまたはのような機能static_assertは簡単でした（そしてすでにライブラリによってエミュレートされていました）。ラムダは非常によく理解され、他のさまざまな言語で実装されています。すでに広範な研究が行われているため、主に構文の問題でした。

他方で、概念はあまりにも新しくて未熟であると判断されました。彼らは時間内にほとんど特定されておらず、概念の証拠はありませんでした...したがって、彼らは彼らを待つ（または間違いをする）のではなく、拒否されました。

Dをフォローしないのはなぜですか？そうしないということはありません。委員会は、締め切りを迫ることなく、ゼロから再考すること、そして言語の他の機能とどのように相互作用するかを見るためにコンパイラーに含めることを試みることを人々に奨励しました。特に、コンセプトとコンセプトマップを分離する問題があります。それらを1つとしてバンドルすべきかどうか。

参考までに、現在、この実験専用のClangの支部があり、インディアナ大学のLarisse Voufoが率いています。

2011年の標準では、C ++の概念が取り組んでいたものであり、「ベーキング」が不十分だったため、最終的にその標準から削除されました。C ++の概念に関する作業は継続されており、C ++の概念が次の標準につながる可能性があります。ただし、Dのテンプレート制約に類似した次の標準の提案に取り組む人もいるでしょう。それが起こるかどうかはまだ分からない。私の知る限り、2011年の規格にはそのような提案がなかったため、メリットに関係なくその規格に準拠する機会はありませんでしたが、次の規格に準拠するかどうかは完全に不明ですこの時点で。

Dのテンプレート制約に似たものをC ++に実装できない主な理由は知りませんが、C ++は一般にコンパイル時に実行できる機能がより制限されているため、次のように動作させるのは難しいかもしれませんDで行っているように（ただし、このようなものの導入はconstexpr確かに役立ちます）。

だから本当に短い答えは、Dのテンプレート制約に似たものがC ++にない理由は技術的な理由がないということだと思います。

問題は、そのような提案が次の標準に向けて作成されるかどうか、作成された類似の提案（たとえば、概念に関連する提案）と比較する方法です。許容できる提案ができると仮定すると、コンセプトやDのテンプレートの制約に似たものが、それに対する多くの要望があるという理由だけで、次の標準になると完全に期待しています。問題は、誰もが十分に堅実で、受け入れられる「十分に焼き付けられた」提案を思いつくことができるかどうかです。

Dのテンプレートが制約するということですか？

私の知る限り、boost :: conceptに代わってC ++の概念が提案されていました。ここでの問題は、boostがC ++ 03用に作成されたライブラリであることです。C ++ 11には、C ++ 03が許可する方法で特定のものを実装できる他の構文機能があります（したがって、boost自体は新しい構文の利点を利用して書き換えることができます）。

標準委員会は、概念の指定に時間がかかりすぎたため、概念を削除しました（したがって、c ++ 11の承認が再び遅れました）。彼らはおそらく次のC ++リリースで行くでしょう。

一方、D構文はC ++とは異なり、D自体はコンパイル時にいくつかの式評価機能を保持します。C++は一部のレガシーコードを壊すことなく常に保持することはできません（Dにはない、短い履歴があるため）。C ++自体は、今持っているstatic_assertとcostexpr、それはコンパイル時の評価能力を向上させることができます。将来的には同様のレベルに達する可能性があります。

ここにハーブサッターのQAがあり、彼は15分マークでコンセプトについて話しています。

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

あなたがそれを好めば、ここに別のものがあります：http : //channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

さてあなたの質問について。なぜDバージョンではないのですか？なぜそれを使用するのですか？C ++は非常に複雑で安定した言語です。通常、何十年もサポートする必要があるため、各機能は非常に慎重に選択する必要があります。最初のC ++標準を見て改訂版に従うと、廃止された機能がいくつかありますが、それらもサポートする必要があります。したがって、C ++に100％フィットするように概念を設計することは理にかなっています。

C ++ 0xに含まれていなかった理由について。それは巨大だったからです。提案は100ページの長さで、実装が非常に困難でした。この機能は、標準に含まれるまで成熟するのに時間がかかると判断されました。

簡単に言えば、C ++にはDよりもはるかに多くの歴史的な荷物があります。C++には、正常に動作し続ける必要のある大量の履歴コードがないという事実がなければ、非常に多くのものを実装するのがはるかに簡単になりますそして予想通り。Dにはこの問題はありません。