只是浏览digitalmars.D.learn论坛，以及关于StackOverflow的D相关问题，在我看来，初学者D程序员（包括我）的一个主要错误点是char的使用和能力的差异， wchar，dchar和关联的字符串类型。这会导致以下问题：
我知道这必须是出于向后兼容性的原因以及对来自C ++或C的开发人员的熟悉程度，但我认为可以提出一个相当令人信服的论点，即这些可能的收益被这些开发人员在尝试某些事情时遇到的问题所抵消。使用 char 或字符串非常简单，并期望它在C / C ++中工作，只是让它以难以调试的方式失败。
为了避免很多这些问题，我已经看到D开发社区的有经验的成员一次又一次地告诉没有经验的编码人员使用 dchar 来避免这些问题，这引出了一个问题为什么 char 默认情况下不是32位unicode字符，8位ASCII字符降级为 achar 或类似的东西，仅在必要时才触及？< / p>
答案 0 :(得分：13)
就个人而言，我希望char不存在，而不是char，wchar和dchar，我们更像utf8 ，utf16和utf32。然后每个人都会立即被迫意识到char 不应该用于个别角色，但这不是它的方式。我要说几乎可以肯定的是char简单地从C / C ++中获取，然后添加其他内容以改进Unicode支持。毕竟，char没有任何根本性的错误。只是因为很多程序员都错误地认识到char总是一个字符（即使在C / C ++中也不一定如此）。但是Walter Bright非常了解Unicode并且似乎认为其他人也应该这样，所以他倾向于做出关于Unicode的决定，如果你理解Unicode，那么它的工作效果非常好但如果你不懂（大多数程序员没有）。 D几乎迫使你至少要对Unicode有一个基本的了解，这并不是一件好事，但是确实让一些人感到沮丧。
但问题的实际情况是，虽然将dchar用于单个字符是很有意义的，但通常 有意义将其用于字符串。有时，这就是你所需要的，但UTF-32需要方式比UTF-8更多的空间。这可能会影响性能并且肯定会影响程序的内存占用。并且 lot 的字符串处理根本不需要随机访问。因此，将UTF-8字符串作为默认值比将UTF-32字符串作为默认值更有意义。
在D中管理字符串的方式通常非常有效。只是名称char对于许多人来说具有不正确的内涵，并且不幸的是，在许多情况下，该语言选择将字符文字默认为char而不是dchar。
我认为可以提出一个相当令人信服的论点，即当这些开发人员尝试使用字符串或字符串进行非常重要的事情并期望它在C / C ++中工作时，这些可能的增益会被这些开发人员遇到的问题所抵消。 ，只是让它以难以调试的方式失败。
事实上，C / C ++中的字符串与D中的字符串相同，只是它们不能保护你不被愚昧或愚蠢，这与D中的D. char不同。 C ++总是8位，通常被操作系统视为UTF-8代码单元（至少在* nix版本中 - 对于char的编码，Windows确实很奇怪，并且通常要求您使用{{1}用于Unicode）。当然，除非您明确使用使用不同编码的字符串类型，否则您在C / C ++中拥有的任何Unicode字符串都是UTF-8。 wchar_t和C字符串都在代码单元而不是代码点上运行。但是普通的C / C ++程序员将它们视为每个元素都是一个完整的字符，除非你只使用ASCII，否则这是完全错误的，在这个时代，这通常是一个非常糟糕的假设。
D将实际构建正确Unicode支持的路径引入语言并进入其标准库。这迫使你至少对Unicode有一个基本的了解，并且通常会让它更难搞砸，同时让那些理解它的人非常强大，不仅能正确而且有效地管理Unicode字符串。 C / C ++只是解决问题，让程序员踩到Unicode地雷。
答案 1 :(得分：2)
我理解为“默认情况下为什么dchar不用于字符串？”
dchar是UTF-32代码单元。你很少想要处理UTF-32代码单元，因为你浪费了太多空间，特别是如果你只处理ASCII字符串。
使用UTF-8代码单元（D中的适当类型是char）更节省空间。
D string是immutable(char)[]，即UTF-8代码单元的数组。
是的，如果您经常使用字符串进行随机访问，可以说处理UTF-32代码单元可能会提高应用程序的速度。但是，如果您知道要使用某些特定文本执行此操作，请在该情况下使用dstring类型。这就是说，你现在应该理解为什么D将字符串视为dchar范围。
答案 2 :(得分：0)
由于组合字符，即使dchar也无法真正保存所有Unicode字符（以人类想要的任何方式想到它）并且无法直接编入索引（请参阅{{3}的末尾） } 举些例子）。