d - std.algorithm.joiner(string[],string) - 为什么结果元素是 dchar 而不是 char？

Question

我尝试编译以下代码:

import std.algorithm;
void main()
{
    string[] x = ["ab", "cd", "ef"]; // 'string' is same as 'immutable(char)[]'
    string space = " ";
    char z = joiner( x, space ).front(); // error
}

与 dmd 一起编译以错误结束:

 test.d(8): Error: cannot implicitly convert expression (joiner(x,space).front()) of type dchar to char

换 char z至 dchar z确实修复了错误消息，但我很感兴趣为什么它首先出现。

为什么 joiner(string[],string).front()的结果是 dchar 而不是 char？

(文档 http://dlang.org/phobos/std_algorithm.html#joiner 中没有任何内容)

Answer 1

所有字符串都被视为 dchar 的范围。这是因为 dchar 保证是单个代码点，因为在 UTF-32 中，每个代码单元都是一个代码点，而在 UTF-8 ( char ) 和 UTF-16 ( wchar ) 中，每个代码的代码单元数点不同。因此，如果您对单个 char s 或 wchar s 进行操作，那么您将操作部分字符而不是整个字符，这将是非常糟糕的。如果您不太了解 unicode，我建议您阅读 Joel Spolsky 的 this article。它很好地解释了事情。

在任何情况下，因为对单独的 char 和 wchar 进行操作没有意义，char 和 wchar 的字符串被视为 dchar 的范围( ElementType!string 是 dchar )，这意味着就范围而言，它们没有length ( hasLength!string 是 false - 需要使用 walkLength 来获取它们的长度)，不可切片( hasSlicing!string 是 false )，并且不可索引( isRandomAccess!string 是 false )。这也意味着从任何类型的字符串构建新范围的任何内容都将产生 dchar 范围。 joiner 就是其中之一。有一些函数可以理解 unicode 和特殊情况字符串以提高效率，尽可能利用长度、切片和索引，但除非它们的结果最终是原始的切片，否则它们返回的任何范围都必须进行dchar s。

因此，任何字符范围内的 front 将始终为 dchar ，并且 popFront 将始终弹出完整的代码点。

如果您对范围不太了解，我建议您阅读 this 。这是一本关于 D 的在线书籍中的一章，是目前我们拥有的最好的范围教程。我们真的应该在 dlang.org 上写一篇关于范围(包括它们如何处理字符串)的适当文章，但还没有人开始写它。无论如何，您至少需要对范围有基本的了解，才能使用大量 D 的标准库(尤其是 std.algorithm)，因为它大量使用它们。