個人的には、それcharが存在せず、 、 、および の代わりに、char、wcharおよびのdcharようなものがあればいいのにと思います。そうすれば、それは個々のキャラクターに使用されるべきものではないことに誰もがすぐに気付かざるを得なくなりますが、それはそうではありませんでした. 単純に C/C++ から取り出され、Unicode サポートを改善するために他のものが追加されたのはほぼ間違いないと思います。結局のところ、基本的に何も問題はありません。非常に多くのプログラマーが間違った理解をしているだけです。utf8utf16utf32charcharcharcharは常に文字です (これは C/C++ でも必ずしも真ではありません)。しかし、Walter Bright は Unicode について非常によく理解しており、他のすべての人もそうすべきだと考えているようです。 't (ほとんどのプログラマーはそうではありません)。D を使用すると、少なくとも Unicode の基本的な理解が必要になります。これはすべてが悪いわけではありませんが、つまずく人もいます。
しかし、実際には、dchar個々の文字に使用するのは理にかなっていますが、文字列に使用するのは一般的に意味がありません。それが必要な場合もありますが、UTF-32 はUTF-8 よりも多くのスペースを必要とします。これはパフォーマンスに影響を与える可能性があり、プログラムのメモリ フットプリントに確実に影響します。また、多くの文字列処理では、ランダム アクセスはまったく必要ありません。したがって、デフォルトとして UTF-8 文字列を使用することは、UTF-32 文字列をデフォルトにするよりもはるかに理にかなっています。
D で文字列を管理する方法は、通常、非常にうまく機能します。char多くの人にとって名前が間違った意味合いを持っているだけであり、残念ながら言語は多くの場合charではなくデフォルトの文字リテラルを選択しますdchar。
この可能性のある利益は、同じ開発者が char や string で自明でないことを試み、それが C/C++ の場合と同じように機能することを期待するときに経験する問題によって相殺されるというかなり説得力のある議論を行うことができると思います。デバッグが困難な方法で失敗することがあります。
問題の現実は、C/C++ の文字列は D と同じように機能しますが、D とは異なり、無知または愚かであることから保護しないだけですchar。C/C++ では常に 8 ビットであり、通常はOS によって UTF-8 コード単位として扱われます (少なくとも *nix ランドでは、Windows はエンコードに奇妙なことを行い、通常はUnicodecharに使用する必要があります)。wchar_t確かに、C/C++ の Unicode 文字列は、別のエンコーディングを使用する文字列型を明示的に使用しない限り、UTF-8 です。std::stringおよび C 文字列はすべて、コード ポイントではなくコード単位で動作します。しかし、平均的な C/C++ プログラマーは、それらの各要素が文字全体であるかのように扱います。これは、ASCII のみを使用している場合を除き、まったく間違っています。この時代では、多くの場合、それは非常に悪い仮定です。
D は、適切な Unicode サポートを言語とその標準ライブラリに実際に組み込むというルートを採用しています。これにより、少なくとも Unicode の基本的な理解を深めることができ、多くの場合、Unicode 文字列を正しくかつ効率的に管理するための非常に強力なツールを理解している人に与える一方で、それを台無しにすることが難しくなります。C/C++ は問題を回避するだけで、プログラマーは Unicode の地雷を踏むことができます。