就个人而言，我希望那char不存在，而不是char, wchar, and dchar, 我们有一些更像utf8, utf16, and的东西utf32。然后每个人都会立即被迫意识到这char不应该用于单个角色，但事实并非如此。我会说几乎可以肯定的情况char是简单地从 C/C++ 中提取，然后添加其他的以改进 Unicode 支持。毕竟，从根本上来说并没有什么问题char。只是很多程序员有这样的错误理解char总是一个字符（即使在 C/C++ 中也不一定是真的）。但是 Walter Bright 对 Unicode 有很好的理解，并且似乎认为其他人也应该如此，所以他倾向于做出关于 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 位，通常是操作系统将其视为 UTF-8 代码单元（至少在 *nix 领域 - Windows 为编码做了一些奇怪的事情，char并且通常要求您使用wchar_tUnicode）。当然，您在 C/C++ 中拥有的任何 Unicode 字符串都是 UTF-8 格式，除非您明确使用使用不同编码的字符串类型。std::string和 C 字符串都对代码单元而不是代码点进行操作。但是普通的 C/C++ 程序员将它们视为每个元素都是一个完整的字符，除非您只使用 ASCII，否则这是完全错误的，而在当今时代，这通常是一个非常糟糕的假设。
D 采取了在语言及其标准库中实际构建适当的 Unicode 支持的路线。这迫使您至少对 Unicode 有一个基本的了解，并且通常会使其更难搞砸，同时为那些理解它的人提供非常强大的工具，不仅可以正确而且有效地管理 Unicode 字符串。C/C++ 只是绕过这个问题，让程序员踩到 Unicode 地雷。