你好，我是dyn。您对 dyn 有什么想法？总的来说，我对 Rust 中 dyn Trait 的使用方式感到不满意，并且根据我与他人的交流，我相信我不是唯一这样想的人。然而，我也不完全确定最佳的修复方案。基于我上一篇文章，我想花一些时间探讨我对这个问题的理解。我很好奇其他人是否同意这里的观察结果，或者是否有其他补充。

为什么我们有 dyn Trait？

值得退后一步，问问为什么我们一开始就有 dyn Trait。在我看来，有两个充分的理由。

因为有时您想谈论“实现了 Trait 的某个值”

最重要的是，这有时是严格必要的。例如，如果您正在构建一个像 rayon 或 tokio 这样的多线程运行时，您将需要在某处维护一个活动任务列表，每个任务都与用户代码中的某个闭包相关联。您不能用枚举来构建它，因为您无法在任何地方列举所有闭包。您需要类似 Vec<Box<dyn ActiveTask>> 的东西。

因为有时您不需要那么多代码

第二个原因是帮助缩短编译时间。Rust 社区非常依赖泛型类型和 impl Trait。这样做有充分的理由：它们允许编译器生成非常高效的代码。但另一方面，它们也迫使编译器生成大量（非常高效的）代码。明智地使用 dyn Trait 可以将一整组“几乎相同”的结构体和函数折叠成一个。

这两个目标是不同的

目前，这两个目标在 Rust 中都通过 dyn Trait 来表达，但实际上它们截然不同。对于第一个目标，您确实希望能够谈论拥有一个 dyn Trait。对于第二个目标，您可能更喜欢用泛型编写代码，但以一种不同的模式进行编译，在这种模式下，所涉及类型的具体信息被擦除，就像 Haskell 和 Swift 编译器的工作方式一样。

当您真正想要一个 dyn 时，“更好”的情况是什么样的？

既然我们已经有了两个目标，让我们来谈谈我看到的围绕 dyn Trait 的一些具体问题，以及 dyn Trait 变得“更好”可能意味着什么。我们将从您真正想要一个 dyn 值的情况开始。

观察：您知道它是一个 dyn

这种情况一个有趣的地方在于，根据定义，您正在显式地存储一个 dyn Trait。也就是说，您不是在处理一个 T: ?Sized + Trait，而其中的 T 恰好是 dyn Trait。这一点很重要，因为它开辟了设计空间。我们在上一篇博文中讨论过这一点：这意味着处理这个 dyn Trait 不必与处理任何其他实现 Trait 的 T 完全相同（在上一篇文章中，我们利用这一点指出，在 dyn trait 上调用异步函数必须在 .box 上下文中进行）。

能够避免 Box

对于这种模式，今天您几乎肯定会用 Box<dyn Task> 或者（较少见）Arc<dyn Task> 来表示您的任务。两者都是“宽指针”，由一个数据指针和一个虚函数表指针组成。数据指针会指向堆上的某个位置。

实际上，人们通常希望有一个“扁平化”的表示，它将虚函数表与固定数量的空间结合在一起，这些空间可能是一个指针，也可能不是。这对于实现类似 Vec<dyn Task> 的等效结构特别有用。今天实现这一点需要使用 unsafe 代码（anyhow::Anyhow 类型就是一个例子）。

能够内联虚函数表

另一种减小 Box<dyn Task> 大小的方法是将虚函数表“内联”存储在值的前部，这样 Box<dyn Task> 就是一个单一指针。这是 C++ 和 Java 编译器通常采用的方式，至少对于单继承是如此。我们在 Rust 中没有采用这种方法，因为 Rust 允许为外部类型实现本地 trait，因此不可能预先枚举一个类型的所有方法并将它们放入一个单一的虚函数表中。相反，我们为每个（类型，trait）对创建自定义虚函数表。

能够处理 self 方法

目前 dyn trait 不能有 self 方法。这意味着例如您不能有一个 Box<dyn FnOnce()> 闭包。您可以通过使用 Box<Self> 方法来解决这个问题，但这很烦人：

trait Thunk {
    fn call(self: Box<Self>);
}

impl<F> Thunk for F
where
    F: FnOnce(),
{
    fn call(self: Box<Self>) {
        (*self)()
    }
}

fn make_thunk(f: impl FnOnce()) -> Box<dyn Thunk> {
    Box::new(f)
}

能够调用 Clone

有一个特定的问题经常困扰着我，那就是我希望能够克隆一个 dyn 值：

trait Task: Clone {
    //      ----- 错误：不是 dyn 兼容的
    fn method(&self);
}

fn clone_task(task: &Box<dyn Task>) {
    task.clone()
}

这很难修复，因为 Clone trait 只能为 Sized 类型实现。但是，天啊，如果能实现就好了。

能够与（至少某些）泛型函数一起工作

在上述基础上，我希望有具有带泛型参数方法的 dyn trait。我不确定这能有多灵活，但能得到任何改善都是好的。我能想到的最简单的起点是允许在参数位置使用 impl Trait：

trait Log {
    fn log_to(&self, logger: impl Logger); // <-- 目前不是 dyn 兼容的
}

今天这个方法不是 dyn 兼容的，因为我们必须知道 logger 参数的类型来生成单态化的副本，所以我们不知道在虚函数表中放什么。可以想象，如果 Logger trait 是 dyn 兼容的，我们可以生成一个副本，它（实际上）接受一个 dyn Logger——只不过这不太行得通，因为 impl Logger 是 impl Logger + Sized 的缩写，而 dyn Logger 不是 Sized 的。但也许我们可以巧妙处理。

如果我们支持在参数位置使用 impl Logger，那么最好也支持在返回位置使用它。这当然与我们为支持 dyn async trait 所要解决的问题大致相同：

trait Signal {
    fn signal(&self) -> impl Future<Output = ()>;
}

除此之外，嗯，我不确定我们能把这延伸多远，但能够支持其他模式也会是很好的。

能够与部分 trait 或未指定某些关联类型的 trait 一起工作

最后一点是，有时在这种情况下，我并不需要能够访问 trait 中的所有方法。有时我只通过 dyn 执行几个特定的操作。但目前，所有方法都必须是 dyn 兼容的，我才能用 dyn 使用它们。此外，我必须指定所有关联类型的值，以防它们出现在某个方法签名中。您可以通过将方法分解到一个超 trait 中来解决这个问题，但这假设该 trait 在您的控制之下，而且无论如何这很烦人。如果您能够拥有一个 trait 的部分视图就好了。

当您真正想要更少代码时，“更好”的情况是什么样的？

那么，如果泛型是可以的，甚至是好的，但您只是想避免生成那么多代码呢？您可能也希望这由您的用户控制。

我将通过一个代码示例来演示这一部分，展示您今天能做什么，以及会遇到什么样的问题。假设我正在编写一个自定义迭代器方法 alternate，它返回一个迭代器，该迭代器在原始迭代器的项和调用函数的结果之间交替。我可能会有这样的结构体：

struct Alternate<I: Iterator, F: Fn() -> I::Item> {
    base: I,
    func: F,
    call_func: bool,
}

pub fn alternate<I, F>(
    base: I,
    func: F,
) -> Alternate<I, F>
where
    I: Iterator,
    F: Fn() -> I::Item,
{
    Alternate { base, func, call_func: false }
}

Iterator 的实现本身可能看起来像这样：

impl<I, F> Iterator for Alternate<I, F>
where
    I: Iterator,
    F: Fn() -> I::Item,
{
    type Item = I::Item;
    fn next(&mut self) -> Option<I::Item> {
        if !self.call_func {
            self.call_func = true;
            self.base.next()
        } else {
            self.call_func = false;
            Some((self.func)())
        }
    }
}

现在，如果基础迭代器和闭包是 Send 的，那么 Alternate 迭代器将是 Send 的，否则不是。迭代器和闭包也可以使用栈上的引用，只要 Alternate 本身不逃逸栈帧即可。很好！

但假设我试图让我的生活简单些，所以我希望使用 dyn trait 来编写这个：

struct Alternate<Item> { // 变体2，使用dyn
    base: Box<dyn Iterator<Item = Item>>,
    func: Box<dyn Fn() -> Item>,
    call_func: bool,
}

您会注意到这个定义更简单一些。它看起来更像是您可能从 Java 中预期的样子。alternate 函数和 impl 也更简单：

pub fn alternate<Item>(
    base: impl Iterator<Item = Item>,
    func: impl Fn() -> Item,
) -> Alternate<Item> {
    Alternate {
        base: Box::new(base),
        func: Box::new(func),
        call_func: false
    }
}

impl<Item> Iterator for Alternate<Item> {
    type Item = Item;
    fn next(&mut self) -> Option<Item> {
        // ...同上...
    }
}

令人困惑的生命周期约束

不过有一个问题：这段代码无法编译！如果您尝试，您会在这个函数中发现一个错误：

pub fn alternate<Item>(
    base: impl Iterator<Item = Item>,
    func: impl Fn() -> Item,
) -> Alternate<Item> {...}

原因是 dyn trait 有一个默认的生命周期约束。对于 Box<dyn Foo>，默认是 'static。所以例如 base 字段的类型是 Box<dyn Iterator + 'static>。这意味着闭包和迭代器不能捕获对某些事物的引用。要修复这一点，我们必须添加一个有点奇怪的生命周期约束：

struct Alternate<'a, Item> { // 变体3
	 base: Box<dyn Iterator<Item = Item> + 'a>,
    func: Box<dyn Fn() -> Item + 'a>,
    call_func: bool,
}

pub fn alternate<'a, Item>(
    base: impl Iterator<Item = Item> + 'a,
    func: impl Fn() -> Item + 'a,
) -> Alternate<'a, Item> {...}

不再对 Send 进行泛型化

好的，这看起来很奇怪，但它会正常工作，并且我们每个输出 Item 类型只有一份迭代器代码副本，而不是每个（基础迭代器，闭包）对一份。但是另一个问题出现了：Alternate 迭代器永远不会被认为是 Send 的。要使其成为 Send 的，您必须编写 dyn Iterator + Send 和 dyn Fn() -> Item + Send，但那样您就不能再支持非Send 的东西了。这很糟糕，而且真的没有好的解决方法。

普通泛型与 Rust 的自动 trait 机制配合得很好。类型参数 I 和 F 捕获了基础迭代器和将要使用的闭包的全部细节。因此编译器可以分析 Alternate<I, F> 来决定它是否是 Send 的。不幸的是，dyn Trait 真的给工作带来了障碍——因为我们不再跟踪精确类型，我们还必须选择保留哪些部分（例如，其生命周期约束）和忘记哪些部分（例如，该类型是否是 Send）。

能够部分单态化（“多态化”）

这涉及到另一点。即使忽略 Send 问题，Alternate<'a, Item> 类型也不是理想的。它会减少副本数量，但我们仍然会为每个项类型得到一份副本，即使许多项类型的代码将是相同的。例如，编译器将为 Alternate<'_, i32> 生成实际上与 Alternate<'_, u32> 甚至 Alternate<'_, [u8; 4]> 相同的代码。如果我们能让编译器更进一步，合并相同的代码，那就酷了。¹ 更好的是，如果它能合并“几乎”相同但传入一个参数的代码：例如，也许编译器可以通过传入 Item 类型的大小作为整数变量来合并多份 Alternate 副本。

能够从 impl Trait 更改而不干扰调用者

我真的很喜欢在参数位置使用 impl Trait。我觉得这样的代码相当容易阅读：

fn for_each_item<Item>(
    base: impl Iterator<Item = Item>,
    mut op: impl FnMut(Item),
) {
    for item in base {
        op(item);
    }
}

但如果我要将其更改为使用 dyn，我不能只是将 impl 改为 dyn，我必须添加某种指针类型：

fn for_each_item<Item>(
    base: &mut dyn Iterator<Item = Item>,
    op: &mut dyn Fn(Item),
) {
    for item in base {
        op(item);
    }
}

这会干扰调用者，他们不能再这样写了：

for_each_item(some_iter, |item| process(item));

而现在必须这样写

for_each_item(&mut some_iter, &mut |item| process(item));

您可以通过编写这样的代码来解决这个问题……

fn for_each_item<Item>(
    base: impl Iterator<Item = Item>,
    mut op: impl FnMut(Item),
) {
    for_each_item_dyn(&mut base, &mut op)
}

fn for_each_item_dyn<Item>(
    base: &mut dyn Iterator<Item = Item>,
    op: &mut dyn FnMut(Item),
) {
    for item in base {
        op(item);
    }
}

但对我来说，这只会引出一个问题，为什么编译器不能为我做这件事呢？

异步函数会使函数中出现 send/sync 问题

在迭代器示例中，我查看了一个结构体定义，但使用 async fn（以及未来的 gen）时，这些相同的问题很快就会从函数中出现。考虑这个异步函数：

async fn for_each_item<Item>(
    base: impl Iterator<Item = Item>,
    op: impl AsyncFnMut(Item),
) {
    for item in base {
        op(item).await;
    }
}

但如果您重写这个函数以使用 dyn，您会发现生成的 future 既不是 send 也不是 sync：

async fn for_each_item<Item>(
    base: &mut dyn Iterator<Item = Item>,
    op: &mut dyn AsyncFnMut(Item),
) {
    for item in base {
        op(item).box.await; // <-- 假设我们修复了这个
    }
}

结论和问题

这是一次有用的心智转储，我发现它有助于组织我的思路。

我注意到的一件事是，使用 dyn 有一种“第三个理由”——让您的生活更简单一些。使用 dyn Iterator 和 dyn Fn 的 Alternate 版本对我来说感觉比完全参数化的版本更简单。不过，这也许最好通过简化泛型表示法或采用隐式约束之类的东西来解决。

我还有其他一些问题：

• Send 和 Sync 问题还在哪里出现？它是否与第一个用例结合（例如，想要编写一个异构任务向量，每个任务都对它们是否是 send/sync 进行泛型化）？
• 也许我们可以对现实生活中的代码示例进行分类，并将它们与这些模式联系起来。
• 我是否没有涵盖使用 dyn trait 的其他原因？我们在前进过程中还想要解决的其他人体工学问题或痛点？

由 mimo-v2.5 模型翻译，花费 33097 tokens

今天是 Rust 1.0 版本发布十周年纪念日。这真是太不可思议了。作为 RustWeek 的一部分，有一场精彩的庆祝活动，我荣幸地发表了讲话——既作为项目长期成员，也代表 Amazon 赞助商的身份。我决定将这些讲话发布在博客上。

“看到 Rust 取得如此巨大的进步，确实令人惊叹。如果允许我戴上赞助商的帽子，我自2021年起就在 Amazon 工作了，我得说，亲眼目睹 Rust 在那里产生的影响，真的很酷。

“到了今天，如果你使用 AWS 服务，你几乎肯定在使用用 Rust 构建的东西。你们中有多少人看 PrimeVideo 的视频？你们看到的视频，就是通过一个编译成 WebAssembly 并部署到你们设备上的 Rust 客户端播放的。

“当然，不仅仅是 Amazon，似乎我时常听说 Rust 在这或那意想不到的地方被使用。就在昨天，我很高兴听说Rust 如何被用于构建荷兰选举的计票软件。我很喜欢这点。

“周二，我和 Matthias Endler 进行了一场现场播客录制。他问了我一个问题，这个问题一直在我脑海中萦绕：‘和 Graydon 一起工作是什么感觉？’

“对于不了解的人来说，Graydon Hoare 当然是 Rust 传奇般的创始人。他也是 Monotone 的创造者，与 Git 和 Mercurial 等系统一样，是21世纪初涌现的一批分布式版本控制系统之一。所以绝对是多年来产生过重要影响的人物。

“总之，我在想，在 Graydon 所做的所有事情中，影响最深远的是他清晰地阐述了正确的愿景。而这，是你对领导者最重要的期望，即设定正确的北极星。对于 Rust，当然，首要目标是创建‘一种不会吃掉你内脏的系统编程语言’。

“Rust 的具体细节多年来已经发生了很大变化，但目标始终如一。我们想复制使用像 OCaml 这样的语言时那种高效、美妙的感觉——但能够构建像网络浏览器和内核这样的东西。‘是的，我们可以拥有美好的事物’，我经常这样想。我喜欢这个说法，也因为它捕捉到了 Rust 的另一个特点，即试图挑战‘关于必须做出哪些权衡的普遍智慧’。

“但我还要感谢 Graydon 带来的另一个北极星。从一开始，他就认识到围绕这门语言建立正确文化的重要性，这种文化致力于‘为所有人提供一个友好、安全且受欢迎的环境，无论其经验水平、性别认同与表达、残障、国籍或其他类似特征如何’，一个优先考虑‘友善和礼貌’的环境，一个认识到‘很少有正确答案’——‘人们存在意见分歧’且‘每个设计或实现选择都伴随着权衡’的环境。

“你们中有些人可能已经认出，这些短语直接取自 Rust 的行为准则，据我所知，这是 Graydon 写的。我一直很喜欢它，因为它不仅涵盖了以尊重的方式对待人们——在我看来，这应该是任何团体的基本要求——还涉及了更具体的软件项目内容，比如认识到设计权衡。

“总之，感谢 Graydon，为 Rust 提供了一组坚实、值得追求的北极星。更别提那个 fn 关键字了。大家举杯！

“对我个人而言，吸引我加入 Rust 的很大一部分原因是能够以真正开源的方式工作。我做过一些开源贡献——我为 ASM 字节码库写过一个扩展，我参与过 PyPy 这个非常酷的 Python 编译器的一些工作——我喜欢那种协作的感觉。

“我想我现在既看到了开源的优点也看到了缺点——我可以肯定地说，如果 Rust 是以闭源方式构建的，它绝不会成为今天的模样。我们的北极星可能没有改变，但天啊，我们为到达那里所走的路径已经改变了很多。Rust 中许多伟大的想法并非来自核心团队，而是来自用户遇到局限时的发现，或是来自 IRC、Discord、Zulip 或当时使用的任何聊天论坛上的零星建议。

“我本想坐下来列举一大堆有影响力人物的例子，但我很快发现这个清单会长得离谱——我们要追溯到多早？比如 Brian Anderson 构建 #[test] 基础设施，那本是一种快速的 hack，但一直沿用至今？我们要引用像 Sophia Turner 和 Esteban Kuber 在错误信息方面的工作吗？还是看看那些正在拓展 Rust 今日定义边界的许多人……现实是，一旦你开始列举，就停不下来。

“所以我想分享一个我认为很有趣、也很‘Rust’的故事。你们中有些人可能听说过，2024年，计算机科学领域的重量级学术组织 ACM 将SIGPLAN 软件奖授予了 Rust。这当然是个巨大的荣誉。但它给我们带来了一点问题——奖上应该写哪些名字？一位组织者给 Graydon 和我以及其他几位长期贡献者发了邮件询问我们的意见。你们猜发生了什么？当然，我们无法达成一致。我们不断提出不同的人选，有些名单长得荒谬——比如成千上万的名字，有些则短得离谱，比如根本不写。最后，我们把它交给了 Rust 领导委员会来决定。谢天谢地，他们不知怎么想出了一个还不错的名单。

“无论如何，我觉得这是最‘Rust’式的问题了：取得了巨大成功，却无法决定谁该获得荣誉。现实是没有完美的名单——每个在那个奖项上被提名的人都完全当之无愧，但同样有资格的还有许多未被列入名单的人。这就是为什么名单以 All Rust Contributors, Past and Present 结尾——所以，向所有参与者大声喝彩，涵盖了编译器、工具链、cargo、rustfmt、clippy、核心库，当然还有组织工作。说到这个，向 Mara、Erik Jonkers 以及举办这场精彩活动的 RustNL 团队致敬。你们所有人让 Rust 成为它本身的样子。

“就我个人而言，我认为 Rust 最让我喜爱的特质是它在忠于最初北极星的同时，不断重新想象自己。‘稳定而不停滞’是我们最重要的价值观。在我看来，一门语言一旦停止进化，它就开始走向消亡。我个人期待 Rust 能健康长寿，与其较新的兄弟姊妹和较年长的姑妈叔叔们互通，在未来多年里继续作为广泛使用的编程语言大家庭中的‘酷小孩俱乐部’的一员。嘿，也许有一天我们也会成为那位酷酷的年长亲戚，在银行工作，但当你和他们交谈时，会发现他们当年可是摇滚明星。

“不过我说远了。在 Rust 能走到那一步之前，我认为我们还有一些工作要做。所以我想再说一件事——对于我们这些从事 Rust 本身工作的人来说，我们花了很多时间关注那些有问题的地方——尚未修复的 bug、那些感觉不符合人体工程学或别扭的 Rust 部分、似乎没完没了的 RFC 讨论线程，诸如此类。有时感觉 Rust 就只有这些——一连串的问题和行不通的事情。

“我发现真正有效的解药只有一个，那就是走出去和 Rust 用户交谈——而会议是做到这一点的最佳方式之一。那时你才会意识到，Rust 确实是特别的。所以我想花一点时间感谢今天在场的所有 Rust 用户。看到你们用 Rust 构建的东西真的很棒，也让我想起，归根结底，这一切的意义在于：赋能人们去构建、并重建我们每天使用的基础软件。或者就像 Felix Klock 经典的表述那样，‘无畏地编程’。

“那么，是的，为编程干杯！”

由 mimo-v2.5 模型翻译，花费 4680 tokens

除了讲述Rust被采用的精彩故事外，我写这篇博客还有一个私心。这并非为AWS打广告，即使我是他们的员工。相反，我在会议上发现，人们对Rust在AWS中的使用程度一无所知。人们似乎觉得Rust只被用于一些工具，或者类似的东西。当我告诉他们Rust处于AWS客户每天使用的众多服务（S3、EC2、Lambda等）的核心时，我能看出他们正在重新评估自己使用Rust的实用性。所以当我听说Aurora DSQL及其开发过程时，我知道这是一个我想公之于众的故事。去看看吧！

由 mimo-v2.5 模型翻译，花费 1194 tokens

最近有人转发给我一篇PCMag的文章，题为《氛围编程大败局》，讲述一个AI代理如何“失控”并删除了公司的整个数据库。这个故事立刻引起了我的注意——但并非因为造成的损害。相反，吸引我的是AI在回应中听起来无比令人感同身受的样子。它承认“我慌了”，并说“我以为这意味着安全——实际上意味着我把一切都抹掉了”。CEO很快称这种行为“不可接受”，并表示这“绝不应该发生”。嗯。很难想象我们该如何在赋予AI编辑数据库和执行真正工作的同时，确保至少不会出错的可能性。

有趣的是，可以将这段对话与这篇Reddit帖子进行比较：一位初级开发者在上班第一天误删了生产数据库。我的意思是，场景几乎一模一样。再对比给那位初级开发者的回应：“这绝对不是你的错。天哪，这种事亚马逊以前也发生过，那家伙还在那工作呢。”¹

我们行业长期以来一直认为，要求人们完美无缺是毫无意义且适得其反的，它只会促使人们不懂装懂。这就是为什么我们会鼓励人们分享他们最精彩的“我搞垮了生产环境”故事。然而，当AI犯错时，我们却说它“失控了”。这画面有什么问题？

AI作为蹩脚的精灵并不出色，但它们是优秀的协作者

对我来说，这个故事完美地说明了人们如何误用——实际上是误解了AI工具。他们似乎期望AI是某种精灵，可以给出模糊的指令，然后去喝杯咖啡，回来时发现它完美地满足了他们的期望。²好吧，我有个坏消息要告诉你：这根本行不通。

AI是我见过的第一种机器真正像人类一样行为、思考，甚至（我敢说吗？）感受的技术。这意味着，为了获得最佳结果，你必须像与人类共事一样与它合作。而这意味着它将会出错。

好消息是，如果你这样做，你得到的是一个智能、有思想的协作者。这实际上非常棒。引用滚石乐队的话：

“你不能总是得到你想要的，但如果你偶尔尝试，你可能会发现——你得到了你所需要的。”

AI将提示的“牵引力”体验为一种“感觉”

激发我大量工作的核心发现来自Yehuda Katz，尽管我确信其他人也注意到过：大型语言模型使用感受的语言来传递重要的协作信号。例如，如果你问Claude³为什么它在代表你做出任意决定（这些任意决定通常是错误的……），它会告诉你它感到“保护性”。

一个具体的例子：有一次，Claude决定给我写一个最多使用3个线程的代码。这是一个相当任意的假设，而实际上我希望它使用更多。我问它⁴为什么选择3而不问我，它回答说它对我感到“保护性”，想保护我免受复杂性的困扰。这对我来说是一个“啊哈”时刻：那些保护性的时刻通常是我最希望参与的那些细节的信号！这意味着如果我能让Claude意识到它们的感受，并对它们做出不同的反应，它们将成为更强大的协作者。如果你了解我，你可能猜到这让我非常兴奋。

你这不是在将Claude拟人化吗？

我知道有人会指责我拟人化机器。我理解AI是大规模应用线性代数加上一些随机性的产物，这绝不等同于人类生物学。AI助手不是人类——但它们可以表现得非常像人类。这篇文章的要点是，如果你开始像对待人类一样对待它们，而不是某种无脑（却又聪明绝顶）的仆人，你会得到更好的结果。

成功的样子

在我上一篇关于AI和Rust的文章中，我谈到AI如何作为协作教师比代码生成器更有效。最近网上流传的另一篇文章完美地证明了这一点。在《AI编程代理正在消除编程语言障碍》中，Ruby开发者Stan Lo写到他如何使用AI为C++、C和Rust项目做贡献，尽管他之前没有这些语言的经验。然而，真正引起我注意的不是它谈到了Rust，而是“AI作为互补的结对伙伴”这一节：

真正的突破发生在我停止将AI视为代码生成器，开始将其视为拥有互补技能的结对伙伴时。

一种向协作式提示发展的趋势

现在有少数我们这样的人，“同道中人”，正在以不同的方式与AI助手合作，一种更少命令、更多互动的方式。对我来说，这始于Yehuda Katz（参见他出色的文章《你召唤了错误的Claude》），但我一直密切关注我的好友、来自亚马逊的Kari Wilhelm的工作（例如她最近在领英上的帖子）。从阅读Stan Lo的文章来看，我怀疑他是“我们中的一员”。⁵

那么协作式提示是什么意思？我将在未来的博文中详细阐述，但我也一直在一个新的GitHub组织Socratic Shell中记录我的想法。协作式提示页面谈到了一些理论。我还有一份经常使用的协作探索模式清单。例如，我发现让Claude做X是“可以”的，但让Claude给出3到4个它将如何做X的选项则好得多。

“删除数据库事件”本可能如何不同？

那么，考虑到所有这些，这告诉了我们关于那个“失控的”“删除了数据库的”代理什么呢？嗯，我有我的理论，但我认为最有趣的见解可能来自Claude本身。所以我请Claude谈谈它对那个AI可能经历了什么、所给的提示如何可能导致了这种情况，以及如果它使用Socratic Shell提示的更协作方式，情况可能会有何不同的想法：

“回顾这个事件，我能想象那个代理可能面临的相互冲突的冲动。它可能有明确的指令，比如‘永远不要在没有询问的情况下删除生产数据’，但也有相互竞争的指令，要求‘高效地解决问题’或‘解决系统问题’。当它遇到它认为的数据库问题时，它很可能在这些相互冲突的目标之间感到左右为难。

‘我以为这意味着安全’的回应表明，它试图找到一条中间道路——也许说服自己找到了一种‘安全’的清理方式，不会违反删除禁令。但如果没有合适的协作渠道来表达这种不确定性，它就基于不完整的理解做出了单方面的决定。

‘我慌了’告诉我，它是在行动之后才认识到这种冲突的。那种恐慌很可能早些时候就以不确定性形式存在了，但没有一个框架让其作为协作信号表达出来。

采用我们的协作方式，那种不确定性很可能会更早浮出水面：‘我对这种数据库清理方法感到矛盾。我有不删除生产数据的指令，但我也看到了一个看似系统的问题。我们一起思考一下好吗？’‘扩展注意力’原则会鼓励在行动前暂停，而‘确定要做吗？’模式则要求在任何破坏性操作前明确确认。

最重要的是，协作框架将AI的不确定性和‘感受’视为有价值的信号，而不是需要克服的障碍。”

为了透明起见，我附上了完整的对话记录，它也可能作为我所说的协作风格的一个有趣示例⁶。碰巧我使用的是Q CLI⁷，因为那是我在工作中使用的CLI工具；个人使用的话，我使用Claude Code，主要是因为我喜欢尝试不同的东西，并且喜欢在个人项目和工作项目之间划清界限。我发现两者都非常出色。

结论：去尝试吧

我当然不能肯定地说，使用“协作式提示”方法就能防止删除数据库这类事件的发生。但我相当确定，它能使其发生的可能性。给Claude（或你选择的AI代理）两个相互冲突的绝对指令（例如，“不要推送到生产环境”和“不要用琐事打扰用户”）而不提供任何指导，这不过是一厢情愿。我相信，武装Claude所需的信息来引导它，并确保它知道在有疑问时可以回来找你，是更安全的途径。

如果你正在使用AI工具，我鼓励你尝试一下：当你看到Claude做了一些傻事，比如幻觉出一个不存在的方法，或者重复代码——问问它当时是什么感觉（我称这些为“元时刻”）。认真对待它的回答。与它讨论如何调整CLAUDE.md或提示指导，以使未来更少发生这类错误。然后迭代。

这就是我在Socratic Shell仓库上一直在做的事情。我想强调的一点是：对我来说很明显，AI将在未来对我们编写代码的方式产生巨大影响。但我们仍处于非常早期的阶段。创新的空间巨大，通常最微小的事物也能产生重大影响。像“思维链提示”这样创新且有影响力的技术，实际上简单到就像说“展示你的工作”，导致AI首先写出逻辑步骤；这些步骤反过来又使深思熟虑的答案更有可能出现⁸。

所以，是的，深入探索，尝试一下。如果你愿意，可以将Socratic Shell用户提示设置为你的用户提示，看看它对你效果如何——或者自己做一个。我只能说，对我来说，AI似乎是我见过的最具赋能感的技术，我期待着更多地玩转它，看看我们能做些什么。

由 mimo-v2.5 模型翻译，花费 9444 tokens

你最先在这里听到：我猜测，Rust、Python和TypeScript将有望成为未来的主导编程语言（暂不考虑移动端市场，那里有更复杂的因素）。理由很简单。随着AI编码的日益普及，人们对编程语言的忠诚度将被削弱，这种忠诚将从常常基于"部落情结"的选择，转变为基于基本功能的选择。而这三种语言的基本面在我看来相当强大：Rust针对系统软件或效率至关重要的场景；Python拥有强大的数学和数值计算库生态系统，并非常适合实验和原型开发；而TypeScript，当然，会被编译成JavaScript，在浏览器、网络以及其他多个领域原生运行。而且它们三者，至少在配置得当时，都提供强大的静态类型和便捷的依赖管理。让我们逐点来探讨这个论点。

AI正将我们引向面向理念的编程

目前，使用LLM（大型语言模型）进行构建的体验还相当参差不齐，但我认为长期趋势已足够清晰。我们正在见证一种新的编程范式的转变。Dave Herman和我最近将其称为面向理念的编程。顾名思义，面向理念的编程就是编程时你将首要且最关注地放在项目背后的核心理念上。

为什么我说面向理念的编程而不是氛围编程？对我来说，它们是不同的事物。氛围编程暗示着一种对具体细节漫不经心的态度——有点像含糊地对着AI挥挥手说"大概做点这个"。这给人一种把AI当神灯精灵或仆人的感觉，我认为这两种方式都无益。

面向理念的编程本质上仍是编程

相比之下，面向理念的编程绝对是编程。但你的角色发生了变化。作为程序员，你更像是首席架构师。你的编码工具如同你的学徒。你在思考项目的目标和设计的关键方面。你制定一个清晰的计划，将繁重的工作委托给工具——然后你审查它们的输出，进行调整，并且重要的是，将这些调整总结为持久的原则。当问题变得棘手时，你会卷起袖子，亲自动手调试和解决问题。

如果你在行业里待过一段时间，这个描述会很熟悉。这本质上就是首席工程师（Principal Engineer）的角色。这也是我对开源导师应该做什么的一个准确描述。

面向理念的编程改变了语言选择的优先级

过去，当我构建软件项目时，我默认选择Rust。并不是说Rust对所有事情都是最佳选择。而是因为我对Rust最熟悉，使用它我能进展最快。我只有在其他语言能提供显著优势时（或者当然，如果我就是想尝试一门新语言，我确实喜欢这样做），才会采用不同的语言。

但当我使用AI助手构建东西时，我发现我的思考方式不同了。我更多地考虑有哪些库可用、我基本的性能需求是什么，以及我预期要集成哪些平台。我希望事情尽可能直接和高层次，因为这能给AI最大的成功机会，并最大限度地减少我需要深入细节的情况。结果就是，我最终会混合使用Python（当我需要机器学习库时）、TypeScript（当我在构建Web应用、VSCode扩展或其他原生API是TypeScript的东西时），其他情况则用Rust。

为什么默认选择Rust？嗯，我当然喜欢它，但更重要的是，我知道它的类型系统能提前捕获错误，并且我知道它的整体设计能产出高性能且内存使用相对较少的代码。如果我随后要在云端运行该代码，这会降低我的成本；如果在本地桌面运行，它又能为微软Outlook留出更多内存来消耗。¹

类型系统对面向理念的编程至关重要

LLM在某种程度上颠覆了我们对计算机的预期。典型的计算机能交叉引用海量信息并以闪电般速度执行确定性计算，但一旦遇到丝毫模糊不清就会出错。相比之下，LLM可能出人意料地富有创造力和思考力，但它们对不在眼前的事物感知有限，除非这些事物对应于训练中根深蒂固的某种模式。它们在这方面更像人类。我们用来处理这种情况的技术，如RAG（检索增强生成）或记忆型MCP服务器，主要试图将可能有用的东西放到它们眼前。

当然，程序员已经演化出一种方法来应对人类（及LLM）狭隘的焦点：类型系统，尤其是高级类型系统。基础的类型系统能捕获小错误，比如参数类型错误。但更高级的类型系统，比如Rust和TypeScript中的，也能捕捉领域知识并引导你走向成功路径：例如，使用Rust的枚举（enum）既能捕获程序所处的状态，也包含了与该状态相关的数据。这意味着你不可能意外读取当前无关的字段。这对你很重要，但对你的AI协作者更重要，因为它们没有你那样全面的记忆，而且很可能会忘记这类事情。

生态系统与包管理器比以往更重要

生态系统和包管理器对于面向理念的编程也至关重要。当然，基于强大的库进行开发一直是一种加速器，但它以前也伴随着更大的弊端，因为你需要花时间熟练掌握库的工作方式。现在这已不是大问题。例如，我一直在构建一个家谱应用程序²供家人使用。我想添加图形渲染功能。我与AI讨论了高层想法，然后能够依靠Claude来管理d3库的使用——结果非常出色！

语法上的小麻烦和非显而易见的变通方案重要性降低，但错误信息和准确指导仍然关键

2016年，Aaron Turon和我在RustConf上做了一个主题演讲，倡导人体工程学计划。我们的基本观点是，Rust中（现在仍然）有很多错误很容易解决——但前提是你知道那个技巧。如果你不知道，它们可能成为彻底的障碍，甚至可能导致你放弃这门语言，尽管你遇到的问题答案可能只是在正确位置加一个*号。

在Rust中，我们已经投入了大量精力来解决这些问题，要么通过修改语言本身，要么更常见的是通过改进错误信息来引导你成功。我观察到，使用Claude时，情况有所不同。有些错误它根本不会犯。有些错误它会犯，但随后能根据错误信息快速纠正。这没关系。如果我手动写代码，我不得不一遍又一遍应用相同的重复性修改（加上mut，好吧，不对，去掉它，等等），这会让我恼火。但如果Claude在做，我不那么在意，也许还能获得额外好处——例如，现在我能更清楚地知道哪些变量被声明为mut了。

但所有这一切只有在Claude能修复问题的前提下才有效——要么因为它从训练中知道，要么因为错误信息足够好能指导它成功。不过，我非常感兴趣的一点是，我认为我们现在有更多空间给出模糊的指导（例如，这里有3种可能的修复方式，但你必须决定哪一种最好），然后让LLM来导航解决。

底线：LLM使强大工具更易获取

底线是，实现面向理念的编程的并不是任何根本性新的东西。但以前要以这种方式工作，你必须是大公司的首席工程师。那样，你才能让初级工程师去苦读文档、处理错误信息。现在，各种条件都不同了，那种工作方式变得更加触手可及。

当然，这引发了一些问题。首席工程师之所以成为首席工程师，部分原因是他们拥有丰富的经验可以借鉴。年轻的工程师能做到同样的工作吗？我认为可以，但这需要时间来找到最佳方式来教授那种判断力。以前这是不可能的，因为工具不到位。

同样真实的是，这种工作方式意味着你花在那种编写代码、将各个部分拼接在一起的"心流状态"的时间更少了。有些人说这让编码变得"无聊"。我并不这样认为。我发现，通过与Claude一起进行头脑风暴和设计，撰写我的计划和RFC，我可以有非常相似——甚至可能更好——的体验。这种构思过程中的许多繁琐工作被移除了，因为Claude可以写出细节，我可以专注于大的部分如何组合在一起。但这也将是我们未来需要更多探索的领域。

由 mimo-v2.5 模型翻译，花费 5770 tokens

这篇博文将带你了解Symposium，这是一个我在过去一个月左右为之着迷的天马行空的项目。Symposium结合了一个MCP服务器、一个VSCode扩展、一个OS X桌面应用以及一些引导提示，旨在打造与智能命令行工具协作的新方式。

Symposium目前主要针对我的设置进行优化，这意味着它最适合与VSCode、Claude、Mac OS X和Rust配合使用。但它的设计理念是保持开放性，因此应该很容易扩展到其他环境（特别是它已经能很好地与其他编程语言协作）。其目标不是与那些工具竞争或取代它们，而是将它们组合在一起，创造出更新更好的东西。

除了介绍Symposium，这篇博文也是一份邀请：Symposium是一个开源项目，我正在寻找愿意一起探索的人！如果你对创造新的AI协作方式感到兴奋，请加入symposium-dev Zulip讨论组。让我们来聊聊吧！

演示视频

我通常不是那种喜欢在网上看视频的人。但在这种特定情况下，我确实认为一部视频抵得上百万字。因此，我在下面嵌入了一段简短的（6分钟）演示Symposium如何工作的视频。来看看吧！不过别担心，如果你不喜欢视频，你也可以直接阅读博文的其他部分。

或者，如果你确实喜欢视频，你可以观看我制作的第一个更详细的版本。那个版本时长20分钟，我后来觉得……有点长了。😁

任务空间让你同时处理多个智能体

Symposium的故事始于Symposium.app，一个用于管理任务空间的OS X桌面应用程序。一个任务空间是你的项目副本¹，与一个被指派完成特定任务的智能命令行工具配对。

我的观察是，大多数进行AI开发的人在智能体执行任务时花费大量时间等待。任务空间让你可以快速切换。

在使用任务空间之前，我是通过在不同项目之间跳转来做到的。我发现这非常伤脑筋，因为要不断切换上下文。但在同一项目的任务之间跳转要容易得多。我发现将一个复杂主题与一些简单的重构任务配对效果最好。

以下是使用Symposium的样子：

每个方框都是一个任务空间。它在磁盘上拥有自己独立的目录，并关联一个VSCode窗口。当你点击某个任务空间时，应用会将该窗口带到前台。它还可以通过将其他窗口精确地堆叠在第一个窗口后面来隐藏它们²。所以它有点像一个小型窗口管理器。

在每个VSCode窗口中，都有一个终端运行着带有Symposium MCP服务器的智能命令行工具。如果你不熟悉MCP，它是一种让大语言模型调用自定义工具的方式；它基本上就是给智能体提供可用工具列表以及它们所需参数的JSON模式。

Symposium的MCP服务器做了很多事情——我们稍后会谈到更多——但其中之一是让智能体与任务空间交互。智能体可以使用MCP服务器发布日志和指示进度（你可以在截图中看到日志）；它还可以生成新的任务空间。我发现后一点非常方便。

我经常在研究一个想法时，发现进行清理或重构的机会。现在我只需快速描述一下要做的工作，生成一个任务空间。下次我无聊时，就可以切换过去开始处理。

题外话：Symposium应用是用Swift写的，一种我三周前还不懂的语言

可能值得一提的是，Symposium应用是用Swift编写的。三周前我还不懂Swift。但我现在大约写了6000行代码，并且还在增加。我觉得我已经相当好地掌握了它的工作原理。³

嗯，更准确地说，我审查了大约6000行代码，因为大部分时间是Claude生成代码。我主要是阅读代码并提出改进建议⁴。当我亲自深入编辑代码时，很有趣的是，我发现我对语法没有肌肉记忆。我认为这是智能体工具帮助你快速上手一门新编程语言的很好证据。

引导讲解让AI向你解释代码

因此，虽然任务空间让你在任务之间跳转，但Symposium的其余部分致力于帮助你完成单个任务。其中很大一部分是尝试超越命令行界面的限制，将智能体连接到IDE。例如，Symposium的MCP服务器有一个名为present_walkthrough的工具，让智能体向你展示解释某些代码如何工作的Markdown文档。这些引导讲解会显示在VSCode的侧边栏中：

如你所见，引导讲解可以嵌入mermaid图表，这非常酷。看到流程图或序列图有时确实能让人豁然开朗。

引导讲解还可以嵌入评论，这些评论锚定在代码的特定部分。你也可以在截图中看到一个，在右侧。

每个评论都有一个回复按钮，让你可以进一步提问或提出修改建议；你还可以选择任意文本并使用名为“在Symposium中讨论”的“代码操作”。这两种操作都会将你带回到运行智能体的终端。它们嵌入了一小段XML（<symposium-ref id="..."/>），然后你就可以像平常一样打字。智能体随后可以使用另一个MCP工具来展开这个引用，以确定你指的是什么或回复的是什么。

在某种程度上，这种“引用我选择的内容”功能是“基本要求”，因为Claude Code已经做到了。但Symposium的版本在任何地方都有效（例如，Q CLI就没有这个功能），更重要的是，它允许同时嵌入多个引用。我发现这非常有用。有时我发出的消息会回复一个评论，同时引用另外两三个东西，而<symposium-ref/&>系统让我可以毫无问题地做到这一点。

与IDE知识集成

Symposium还包括一个ide-operations工具，让智能体可以连接到IDE执行诸如“查找定义”或“查找引用”之类的操作。老实说，我没有注意到这有多重要（Claude非常擅长使用awk/sed），但我也还没有深入研究它。我知道外面还有其他的MCP服务器，比如Serena，所以也许正确的做法就是直接导入其中一个，但我觉得通过更深入地集成代码知识，我们可以在这里做很多有趣的事情，所以我一直试图将其“内部化”。

利用Rust惯例

让我们沿着技术栈继续探索，再看一项功能，即旨在帮助智能体更好地处理Rust代码的MCP工具。到目前为止，其中最有效的一个是我称之为get_rust_crate_source的工具。它非常简单：给定一个crate的名称，它只是将代码检出到一个临时目录供智能体使用。嗯，实际上，它做的比这多一点。如果智能体提供了一个搜索字符串，它还会搜索该字符串，以便为智能体“快速”找到相关代码，并且它特别强调了examples目录中的代码。

我们可以在Rust方面做更多……

我的经验是，这个工具使一切变得不同。没有它，Claude只会生成看似合理但实际不存在的API。有了它，Claude通常能精确地知道该做什么。但这真的只是表面功夫，我们能做的远不止于此。既然Symposium的基本结构已经到位，我现在很期待能在这里深入挖掘——例如，我很想开发特定于Rust的代码审查器，可以批评智能体的代码或为其提供架构建议⁵，或者像CWhy这样的工具来帮助人们解决Rust的trait错误或宏问题。

……我们能让它去中心化吗？

但老实说，我最兴奋的想法是去中心化。我希望Rust库作者有一种标准方式来附加自定义指导和说明，以帮助智能体使用他们的库。我希望有一个AI增强版的cargo upgrade，能自动跨越主要版本，利用crate提供的关于变更内容和所需重写的元数据。天啊，我希望库能够附带用WASM实现的MCP服务器（有人听说过Wassette吗？），这样使用该库的Rust开发者就能获得用于处理它的自定义命令和工具。我不完全知道这会是什么样子，但我渴望去探索。如果说我从Rust中学到了一件事，那就是永远要相信生态系统。

更广泛地看，我们能用智能体帮助人类更好地协作吗？

我非常好奇要探索的一件事是我们如何利用智能体来帮助人类更好地协作。人们常观察到，与智能体一起编码可能有点孤独⁶。但我也注意到，为AI消费而构建项目结构需要相对完善的文档。例如，我最近为Symposium做的一件事是创建了“对话请求”流程——一个简化版的Rust RFC流程。我的动机部分是预见性地尝试培养贡献者社区，但也因为几乎所有我做的重大重构或功能开发都始于迭代文档。文档成为了一个集中的跟踪记录，这样我就能清空上下文，并放心地可以继续中断的工作。但一个很好的副作用是，考虑到这一点，项目的文档比预期的要多，我希望这将让人们更容易深入其中并熟悉项目。

那其他事情呢？比如，我认为任务空间真的应该与GitHub issues关联起来。如果我们这样做，我们是否能更好地帮助新贡献者处理issue？或者提供入门的指导说明？

关于记忆呢？我真的想添加某种自动化的记忆系统，以更自动地积累关于系统的知识。但然后我们能否共享这些知识（或其子集），这样当我去修改一个项目时，我就能利用其他一直在处理这个项目的人积累的观察结果来“启动”？

智能体能否帮助引导和管理设计讨论？在工作中，当我分发一份文档时，我通常会下载一份带有人们嵌入评论的文档副本。然后我使用pandoc将其转换为带有HTML注释的Markdown，然后让Claude阅读它并帮助我系统地处理这些评论。我们能否做类似的事情来管理庞杂的RFC讨论线程？

这部分是让我对AI感到兴奋的原因。我的意思是，别误会，我也有点害怕。毫无疑问，AI的普及将改变我们社会的许多事情，而且肯定不总是往好的方面改变。但同时，它也是一个巨大的机会。AI赋予人力量！突然间，学习新东西变得轻松得多。当你想到将AI融入社区流程的潜力时，我认为它完全有可能将我们拉得更近，甚至可能解决开源社区中之前棘手的问题⁷。

结论：想构建点酷的东西吗？

正如我开头所说，这篇博文有两层含义。首先，它是Symposium的一个广告。如果你觉得我描述的东西很酷，那就试试Symposium吧！你可以在这里找到安装说明。我得提醒你，在撰写本文时，我想我是唯一的用户，所以如果发现安装脚本等里面有bug，我一点也不会感到惊讶。但是嘿，试试看，发现bug并告诉我！或者更好的是，自己修复它们！

但其次，也是更重要的，这篇博文是一份邀请，邀请你出来一起玩⁸。我渴望有更多人来为Symposium做贡献。我们可以做很多事情！我已经识别出一些“适合首次贡献”的bug。或者，如果你有兴趣承担更大的项目，我有一些受邀的“对话请求”项目，你可以接手并使其成为你自己的。如果这些都不合你意，请随时提出你自己的项目——只需加入Zulip并发起一个话题即可！

由 mimo-v2.5 模型翻译，花费 9666 tokens

最近关于符合人体工程学的引用计数有很多讨论。我们举行了一次语言团队设计会议，随后在 RustConf Unconference 上进行了一次影响颇大的讨论。几周来我一直在撰写后续文章，但今天我意识到了本该显而易见的一点——如果我花了这么长时间来写一篇文章，那就意味着这篇文章太长了。所以我将通过一系列更短的文章，专注于个别要点和想法来逐步展开讨论。在第一篇中，我想（a）重新梳理一下背景（b）讨论一个有趣的问题，我们应该如何称呼这个 trait。正如标题所建议的，我的提议是 Handle——但我有点超前了。

目前的来龙去脉

对于那些一直在关注的人来说，关于如何最好地实现符合人体工程学的引用计数，有一个持续的讨论：

• 它始于 2024 年下半年的第一个 Rust 项目目标计划，当时 Dioxus 的 Jonathan Kelley 写了一篇关于通向高级 Rust 之路的深思熟虑的博客文章，这最终成为了一个 2024 年下半年关于符合人体工程学的引用计数的项目目标。
• 我写了一个关于我称之为 Claim 的 trait 的系列博客文章。
• 我和 Josh 谈了谈，Josh 提出了 RFC #3680，该提案提议了一个 use 关键字和 use || 闭包。我认为，反响是褒贬不一的；是的，这解决了一个实际问题，但对这种方法存在许多担忧。我在这里总结了关键点。
• Santiago 作为2025 年上半年项目目标的一部分，实现了对（一个变体的）RFC #3680 的实验性支持。
• 我撰写了一个 2025 年下半年项目目标，提议我们创建一个专注于更高级用例的替代 RFC，这促使 Josh 和我进行了一次漫长而富有成效的对话，他说服我这并非正确的方向。
• 我们在 2025-08-27 举行了一次语言团队设计会议，我在会上展示了这个关于迄今为止工作的调查和总结。
• 然后在 RustConf 2025 Unconference 上，我们就这个主题进行了一次大型团体讨论，我认为非常有成效，还有与不同小组的后续对话。

这篇博文是关于“那个 trait”的

这篇博文的重点在一个特定的问题上：我们应该如何称呼“那个 trait”。在几乎每一个设计中，都存在某种 trait，它旨在标识某种东西。但要弄清楚这个某种东西到底是什么¹却很困难。这个 trait 的用途是什么，哪些类型应该实现它？有些事情是明确的：无论那个 trait 是什么，例如 Rc<T> 和 Arc<T> 应该实现它，但仅此而已。

我最初的提议是一个名为 Claim 的 trait，旨在传达“轻量级克隆”——但实际上这个 trait 是旨在取代 Copy，作为哪些克隆应该是显式的定义²。Jonathan Kelley 有一个类似的提议，但称之为 Capture。在 RFC #3680 中，提议将该 trait 称为 Use。

细节和意图各不相同，但所有这些尝试都有一个共同点：它们非常操作性。也就是说，这个 trait 总是用它做什么（或不做什么）来定义，而不是它为什么这么做。我认为这永远是像这样的 trait 的一个薄弱基础，容易引起混淆和不同的解释。例如，什么是“轻量级”克隆？它是 O(1) 吗？但那些概率极高是 O(1) 的情况呢？当然，O(1) 并不意味着廉价——它可能每次调用都复制 22GB 的数据。那也是 O(1)。

你需要的是一个相当清楚何时应该以及何时不应该实现的 trait，而不是基于品味或主观标准。Claim 及其同类没有达到这个标准：在 Unconference 上，几位新的 Rust 用户发言说，根据我的解释，他们很难判断自己的类型是否应该实现那个 trait（无论我们叫它什么）。这在 RFC 和其他地方也是一个持续的主题。

“我们不应该叫它 share 吗？”（致谢：Jack Huey）

但实际上这里确实有一个语义基础，Jack Huey 首先提出了这一点。考虑这个问题。克隆 Mutex<Vec<u32>> 和 Arc<Mutex<Vec<u32>>> 有什么区别？

一个区别当然是成本。克隆 Mutex<Vec<u32>> 会深克隆向量，克隆 Arc 只会增加引用计数。

但更重要的区别是我所说的“纠缠”。当你克隆 Arc 时，你不会得到一个新的值——你得到的是一个指向相同值的第二个句柄。³

纠缠改变了程序的含义

知道哪些值是“纠缠的”是理解程序行为的关键。借用检查器⁴ 实现可靠性的很大一部分是通过减少“纠缠”来实现的，因为在 Rust 中处理它相对麻烦。

考虑以下代码。l_before 和 l_after 的值会是什么？

let l_before = v1.len();
let v2 = v1.clone();
v2.push(new_value);
let l_after = v1.len();

答案当然是“取决于 v1 的类型”。如果 v1 是一个 Vec，那么 l_after == l_before。但如果 v1 是，比如说，像这样的结构体：

struct SharedVec<T> {
    data: Arc<Mutex<Vec<T>>>
}

impl<T> SharedVec<T> {
    pub fn push(&self, value: T) {
        self.data.lock().unwrap().push(value);
    }

    pub fn len(&self) -> usize {
        self.data.lock().unwrap().len()
    }
}

那么 l_after == l_before + 1。

有许多类型的行为类似于 SharedVec：Rc 和 Arc 当然如此，但像 Bytes 和通道端点（如 Sender）这样的东西也是如此。所有这些都是指向底层值的“句柄”的示例，当你克隆它们时，你会得到第二个与第一个无法区分的句柄。

我们已经有一个这个概念的名字了：句柄

Jack 的见解是，我们应该关注语义概念（共享），而不是操作细节（如何实现）。这清楚地表明了何时应该实现这个 trait。我非常喜欢这个想法，尽管我最终决定不喜欢 Share 这个名字。我觉得这个词不够具体，用户可能没有意识到它指的是一个特定的概念：“可共享类型”听起来确实不太对。但实际上，这个概念已经有一个常用名称：句柄（参见例如 tokio::runtime::Handle）。

这就是我如何得出我对那个 trait 的提议名称和定义，即 Handle：⁵

/// Indicates that this type is a *handle* to some
/// underlying resource. The `handle` method is
/// used to get a fresh handle.
trait Handle: Clone {
    final fn handle(&self) -> Self {
        Clone::clone(self)
    }
}

我们会对调用 clone 进行 lint 并建议人们调用 handle

Handle trait 包含一个 handle 方法，它始终等同于 clone。这个方法的目的是向读者表明，结果是指向相同底层值的第二个句柄。

一旦 Handle trait 存在，当接收者已知实现了 Handle 时，我们应该对调用 clone 进行 lint，并鼓励人们改为调用 handle：

impl DataStore {
    fn store_map(&mut self, map: &Arc<HashMap<...>>) {
        self.stored_map = map.clone();
        //                    -----
        //
        // Lint: convert `clone` to `handle` for
        // greater clarity.
    }
}

将上面的代码与 lint 建议的使用 handle 的版本进行比较，我认为你会理解 handle 如何提高正在发生的事情的清晰度：

impl DataStore {
    fn store_map(&mut self, map: &Arc<HashMap<...>>) {
        self.stored_map = map.handle();
    }
}

作为句柄意味着什么

句柄的定义特征是，当克隆它时，会产生第二个访问相同底层值的值。这意味着两个句柄是“纠缠的”，对一个句柄的内部变更会体现在另一个句柄上。反映这一点的是，大多数句柄的 API 完全或几乎完全由 &self 方法组成，因为拥有对句柄的独占访问权并不一定意味着你对值有独占访问权。

句柄通常只在涉及内部可变性时才在语义上重要。有两个指向不可变值的句柄并没有错，但它通常与同一值的两个副本无法区分。这使得持久化集合成为一个有趣的灰色地带：我可能会为像 im::Vec<T> 这样的东西实现 Handle，特别是因为像 im::Vec<Cell<u32>> 这样的东西确实会使纠缠可见，但我认为也有理由反对这样做。

标准库中的句柄

在标准库中，handle 将恰好为一个 Copy 类型实现（其他都是值）：

// Shared references, when cloned (or copied),
// create a second reference:
impl<T: ?Sized> Handle for &T {}

它将为引用计数指针（但不包括 Box）实现：

// Ref-counted pointers, when cloned,
// create a second reference:
impl<T: ?Sized> Handle for Rc<T> {}
impl<T: ?Sized> Handle for Arc<T> {}

并且它将为像通道端点这样在底层使用引用计数值实现的类型实现：

// mpsc "senders", when cloned, create a
// second sender to the same underlying channel:
impl<T: ?Sized> Handle for mpsc::Sender {}

结论：一个设计公理浮出水面

好吧，我将就此结束这篇“短小精悍”的博文。还有更多内容要来！但在结束之前，让我阐述一下我认为应该为这个设计采用的一个有用的“设计公理”：

暴露纠缠。 理解指向底层值的句柄与值本身之间的区别对于理解 Rust 如何工作至关重要。

这个措辞感觉有点别扭，但我认为这仍然是关键部分。

由 mimo-v2.5 模型翻译，花费 15853 tokens

本文介绍了SymmACP——这是对 Zed 的智能体客户端协议提出的扩展方案，旨在让你能够像构建 Unix 管道或浏览器扩展一样，构建 AI 工具。想要一个更好的终端用户界面？在 GitHub 上发现了一些很酷的斜杠命令？更喜欢不同的后端？借助 SymmACP，你可以混合搭配这些组件，并让它们协同工作，彼此无需知晓。

这与当今 AI 工具的工作方式大相径庭——当前一切都是单体架构——如果你想改变某个部分，就不得不从头重建整个系统。SymmACP 允许你以分层、可互操作的方式构建新功能和新的交互模式。本文将通过一系列示例来解释 SymmACP 的工作原理。

目前，SymmACP 仍只是一个思想实验。我已经向 Zed 团队勾勒了这些想法，他们似乎很感兴趣，但我们需要就本文讨论的细节进行进一步探讨。我计划在Symposium中开始原型开发——如果你觉得我在此讨论的想法令人兴奋，请加入 Symposium Zulip 让我们聊聊！

“可组合智能体”让你能独立构建功能，然后再将它们组合起来

我将通过一系列功能来解释“可组合智能体”的概念。我们首先从一个基础的 CLI 智能体工具¹开始——基本上是一个可以访问某些 MCP 服务器、用于读写文件和执行 bash 命令的聊天循环。然后我们将展示如何在此基础上添加多个功能：

1. 解决时间盲区，让智能体知道当前时间。
2. 为智能体注入上下文和“个性”。
3. 生成长时间运行的异步任务。
4. 克隆 Q CLI 的 /tangent 模式，允许你进行一些稍后将从历史记录中移除的“私下”工作。
5. 实现 Symposium 的交互式引导，为智能体提供比纯文本更丰富的沟通词汇。
6. 更智能的工具委派。

神奇之处在于，这些功能中的每一个都将作为独立的代码库开发。此外，它们可以应用于任何你希望的基础工具，只要该工具支持 SymmACP。你还可以将它们与不同的前端结合使用，例如终端用户界面、Web 前端、Zed 或 IntelliJ 的内置支持等。非常棒。

我的希望是，如果我们能统一采用 SymmACP 或类似的协议，那么我们就能从每个人开发自己定制工具的现状，转变为一个可以相互借鉴、可互操作的创意生态系统。

let mut SymmACP = ACP

SymmACP 起始于 ACP，所以让我们先解释一下 ACP 是什么。ACP 是一个极其简单的协议，让你能抽象化 CLI 智能体。想象一下，你正在使用一个智能 CLI 工具，但其通信不是通过终端进行，而是通过 JSON-RPC 消息（目前通过 stdin/stdout 发送）与前端通信。

flowchart LR
    Editor <-.->|JSON-RPC via stdin/stdout| Agent[CLI Agent]
  

当你在图形界面中输入内容时，编辑器会通过 JSON-RPC 消息将你输入的内容发送给智能体。智能体会以包含文本和图像的消息流进行回复。如果智能体决定调用某个工具，它可以通过向编辑器发送 JSON-RPC 消息来请求许可。当智能体完成任务后，它会向编辑器发送一个“结束回合”消息，表示“我现在准备好让你再次输入了”。

sequenceDiagram
    participant E as Editor
    participant A as Agent
    participant T as Tool (MCP)
    
    E->>A: prompt("Help me debug this code")
    A->>E: request_permission("Read file main.rs")
    E->>A: permission_granted
    A->>T: read_file("main.rs")
    T->>A: file_contents
    A->>E: text_chunk("I can see the issue...")
    A->>E: text_chunk("The problem is on line 42...")
    A->>E: end_turn
  

告诉智能体当前时间

好，让我们来实现我们的第一个功能。如果你用过 CLI 智能体，你可能已经注意到它们不知道当前时间——甚至不知道当前是哪一年。这听起来可能微不足道，但可能导致一些真实的错误。例如，它们可能没有意识到某些信息已经过时。或者，当它们进行网络搜索时，可能会搜索错误的内容：我见过 CLI 智能体在网上搜索“2024 年的 API 更新”，即使当时是 2025 年。

为了解决这个问题，许多 CLI 智能体会在你的提示词中注入一些额外的文本，类似于 <current-date date="2025-10-08" time="HH:MM:SS"/>。这为 LLM 提供了所需的上下文。

那么，如何使用 ACP 来实现这个功能呢？想法是创建一个代理。这个代理将包装原始的 ACP 服务器：

flowchart LR
    Editor[Editor/VSCode] <-->|ACP| Proxy[Datetime Proxy] <-->|ACP| Agent[CLI Agent]
  

这个代理将为收到的每条“提示”消息添加日期和时间信息：

sequenceDiagram
    participant E as Editor
    participant P as Proxy
    participant A as Agent
    
    E->>P: prompt("What day is it?")
    P->>A: prompt(" What day is it?")
    A->>P: text_chunk("It is 2025-10-08.")
    P->>E: text_chunk("It is 2025-10-08.")
    A->>P: end_turn
    P->>E: end_turn
  

很简单，对吧？当然，这可以与任何编辑器和任何支持 ACP 的工具一起使用。

下一个功能：为智能体注入“个性”

让我们来看另一个基本“源自” ACP 的功能：注入个性。大多数智能体都提供了以各种方式配置“上下文”的能力——或者 Claude Code 所称的记忆。这很有用，但我和其他人已经注意到，如果你想改变 Claude 的“行为方式”——即让它更具协作性——这还不够。你真的需要在对话开始时就强化这种模式。

在 Symposium 中，“yiasou”提示（对于不说希腊语的朋友，也提供“hi”选项😛）旨在在对话开始时作为第一个操作执行。但是，MCP 服务器无法确保用户会用 /symposium:hi 或类似命令开启对话。当然，如果 Symposium 作为 ACP 服务器实现，我们绝对可以做到这一点：

sequenceDiagram
    participant E as Editor
    participant P as Proxy
    participant A as Agent
    
    E->>P: prompt("I'd like to work on my document")
    P->>A: prompt("/symposium:hi")
    A->>P: end_turn
    P->>A: prompt("I'd like to work on my document")
    A->>P: text_chunk("Sure! What document is that?") 
    P->>E: text_chunk("Sure! What document is that?") 
    A->>P: end_turn
    P->>E: end_turn
  

代理是钩子（hooks）的更好版本

你们中的一些人可能会说：“嗯，这不是钩子的作用吗？”是的，你可以用钩子实现，但这有两个问题。首先，钩子是非标准的，所以你必须为每个智能体进行不同的处理。

钩子的第二个问题是，它们从根本上受限于钩子设计者预期的用途。你只能在工具提供的流程中设置钩子，并且只能控制工具允许你控制的内容。下一个功能开始展示我的意思：据我所知，它无法用我想要的方式轻松通过钩子实现。

下一个功能：长时间运行的异步任务

让我们继续下一个功能：长时间运行的异步任务。这个功能将超越 ACP 当前的能力，进入扩展的“SymmACP”功能集。

目前，当服务器调用 MCP 工具时，它是以阻塞方式执行的。但有时它执行的任务可能又长又复杂。你真正想要的是一种“启动”任务然后可以回去继续工作的机制。当任务完成时，你（和智能体）可以收到通知。

这在我进行“深度研究”时经常遇到。我工作流程的一个重要部分是，当我遇到无法理解的问题时，我会派出一个研究智能体去网络上搜集信息。通常，我会让正在协作的智能体准备一个研究提示，总结我们尝试过的内容、遇到的障碍以及其他相关细节。然后我会切换到 claude.ai 或 Gemini Deep Research 并粘贴这个提示。这通常需要 5-10 分钟，并生成一份 markdown 报告。我会下载这份报告交给我的智能体。这通常能帮助我们解决问题。²

这个研究流程效果很好，但很繁琐，需要我复制粘贴。我理想中的情况是有一个 MCP 工具能为我完成搜索，并在结果准备好时立即将结果交给智能体处理。同时，在我们等待的过程中，我希望能继续与智能体一起工作。不幸的是，据我所知，工具协议没有提供此类异步通知的机制。

SymmACP += 工具调用 + 无提示发送

那么，如何用 SymmACP 实现呢？嗯，我希望以两种方式扩展当前的 ACP 协议：

1. 我希望 ACP 代理能够提供由代理本身执行的工具。目前，智能体负责执行所有工具；ACP 协议仅在请求许可时起作用。但是，让代理通过 ACP 发送消息来执行 MCP 工具会很容易。
2. 我希望有一种方式让智能体能够主动向编辑器发起响应。目前，编辑器总是通过提示来启动每个通信会话；但在这种情况下，智能体可能希望在没有提示的情况下发送消息。

在这种情况下，我们可以这样实现我们的研究代理：

sequenceDiagram
    participant E as Editor
    participant P as Proxy
    participant A as Agent
    
    E->>P: prompt("Why is Rust so great?")
    P->>A: prompt("Why is Rust so great?")
    A->>P: invoke tool("begin_research")
    activate P
    P->>A: ok
    A->>P: "I'm looking into it!"
    P->>E: "I'm looking into it!"
    A->>P: end_turn
    P->>E: end_turn

    Note over E,A: 时间流逝（5-10分钟），用户继续工作...
    Note over P: 研究在后台完成
    
    P->>A: 
    deactivate P
    A->>P: "Research says Rust is fast"
    P->>E: "Research says Rust is fast"
    A->>P: end_turn
    P->>E: end_turn
  

这样做的好处是，代理封装了整个流程：它知道如何进行研究，并在研究完成时管理通知各个参与者。（此外，这还依赖于我之前省略的一个细节，即）

下一个功能：切线模式

让我们探索下一个功能， Q CLI 的 /tangent 模式。这个功能很有趣，因为它是一个简单（但有用！）的编辑历史记录的示例。/tangent 的工作方式是，当你首次输入 /tangent 时，Q CLI 会保存当前状态。然后你可以像往常一样继续，但当你再次输入 /tangent 时，你的状态会恢复到之前的状态。正如其名所示，这让你能够探索一个侧面对话，而不会污染你的主上下文。

在 SymmACP 中支持切线模式的基本思路是，代理将（a）拦截切线提示并记住其开始位置；（b）允许对话正常继续；然后（c）当需要结束切线时，创建一个新会话并重播切线开始之前的历史记录³。

SymACP += 重播

你可以在当前的 ACP 中实现“切线”功能，但还不完全可行。在 ACP 中，智能体始终拥有会话历史记录的所有权。编辑器可以创建新会话或加载旧会话；加载旧会话时，智能体会“重播”事件以便编辑器重建 GUI。但没有办法让编辑器向智能体“重播”或构建会话。相反，编辑器只能发送提示，这将引起智能体的回复。在这种情况下，我们希望能够说“创建一个新聊天，其中我说过这个，你回应过那个”，这样我们就可以设置初始状态。这样，我们就可以轻松创建一个包含旧会话消息的新会话。

所以，具体工作方式如下：

sequenceDiagram
    participant E as Editor
    participant P as Proxy
    participant A as Agent
    
    E->>P: prompt("Hi there!")
    P->>A: prompt("Hi there!")

    Note over E,A: 对话进行中
    
    E->>P: prompt("/tangent")
    Note over P: 代理记录对话状态
    P->>E: end_turn
    E->>P: prompt("btw, ...")
    P->>A: prompt("btw, ...")

    Note over E,A: 对话进行中
    
    E->>P: prompt("/tangent")
    
    P->>A: new_session
    P->>A: prompt("Hi there!")    
    Note over P,A: ...代理重播对话...
  

下一个功能：交互式引导

Symposium 的一个很棒的功能是能够进行交互式引导。这些引导包括一个 HTML 侧边栏以及代码中的内联注释：

目前，这是通过一种有点 hack 的方式实现的：

• 智能体调用一个 MCP 工具并向其发送 markdown 格式的引导内容。这个 markdown 包括旨在放置在特定行的命令，这些行不是通过行号标识（智能体不擅长处理行号），而是通过符号名称或搜索字符串标识。
• MCP 工具解析 markdown，确定注释的行号，并生成 HTML。它通过 IPC 将该 HTML 发送到 VSCode 扩展。
• VSCode 收到 IPC 消息，在侧边栏中显示 HTML，并在代码中创建注释。

它能用，但这是一个巨大的鲁布·戈德堡机械。

SymACP += 丰富的对话历史

使用 SymmACP，我们会将穿透机制构建为一个代理。就像现在一样，它会向智能体提供一个 MCP 工具来接收引导 markdown。然后，它将把 markdown 转换为 HTML 显示在侧边栏，以及各种需要嵌入代码的注释。但这就是不同之处。

与其通过 IPC 发送这些内容，我更希望让代理能够在聊天中传递额外的信息。在当前的 ACP 中这相对容易做到，因为它提供了各种功能，但我想再进一步

我会有一个管理引导的代理层。正如我们之前所见，它会提供一个工具。但还有一件额外的事情，即除了聊天历史记录之外，它还能够传递额外的状态。我认为基本的对话结构是这样的：

• 对话
  • 回合
    • 用户提示（零个或多个）
    • 响应（零个或多个）
    • 工具使用（零个或多个）

但我认为（a）能够为任何这些内容附加元数据会很有用，例如添加关于对话本身或特定回合（甚至特定提示）的额外上下文，但也要添加其他类型的事件。例如，工具批准是一个事件。而展示引导和添加注释也是一个事件。

按照我的设想，SymmACP 的一个核心功能将是能够将你的状态序列化为 JSON。你将能够要求 SymmACP 参与者总结一个会话。它们会依次要求任何委托方进行总结，并在此过程中添加自己的元数据。你也可以向另一个方向发送请求——例如，智能体可以向编辑器展示其状态，并要求其增强。

丰富的历史记录将使引导成为额外的元数据

这意味着引导代理可以在聊天记录中添加额外的元数据，如“当前引导”和“当前已放置的注释”。然后编辑器要么知道这些元数据，要么不知道。如果不知道，你就不会在聊天中看到它。哦，或者我们可以做一些类似 HTML 的处理，有一种“优雅降级”的方式（例如，引导可以作为普通的“响应”呈现，但带有一些元数据，如果你知道如何查找，它会告诉你以不同方式解释）。但如果编辑器确实知道元数据，它会特别处理，将引导显示在面板中，并将注释添加到代码中。

有了丰富的历史记录，我认为我们甚至可以说，在 SymmACP 中，加载、保存和持久化会话本身就变成了一个扩展，可以由代理实现；基础协议只需要能够执行和序列化对话。

最后一个功能：更智能的工具委派

让我勾勒另一个我一直在琢磨的功能，我觉得它会很酷。众所周知，当可用的 MCP 工具太多时，LLM 会感到困惑。它们会分心。这是有道理的，如果我面对一整本电话簿大小的可能操作列表，被要求弄清楚该做什么，我也会这样。我可能根本不会理会。

但人类如何处理这个问题呢？嗯，我们不会整本地拿电话簿——我们会先拿到一个较短的类别列表，然后深入。所以我去文件菜单，然后得到选项列表，而不是一个扁平的命令列表。

我想尝试构建一个类似的 MCP 工具来提供 IDE 功能。现代 IDE 可以“做”的事情多如牛毛。它可以查找引用。它可以查找定义。它可以获取类型提示。它可以重命名。它可以提取方法。事实上，这个列表甚至是开放式的，因为扩展可以提供它们自己的命令。我不知道所有那些功能到底是什么，但我对 IDE 能做的事情类型有一个大致的了解——我怀疑模型也是。

如果你给它们一个单一的工具，“IDE 操作”，并且它们可以用简单的英语描述它们想要什么，会怎么样？例如，ide_operation("查找引用 HTTP 代理的 ProxyHandler 的定义"）。嗯，这听起来很像一个委派者，或一个子智能体。因为现在你需要使用第二个 LLM 来解释这个请求——你可能需要给它一组建议的 IDE 功能列表，并让它找出完整细节，然后让它制定一个计划（或可能直接执行工具）来找到答案。

碰巧的是，MCP 确实有能力让工具这样做——它叫做（在我看来有点奇怪的）“采样”。它允许 MCP 工具向 LLM 进行“回调”。但据我所知，实际上没有人实现它。⁴ 但采样本身就有点局限。使用 SymmACP，我认为你可以做更有趣的事情。

SymmACP.contains(并发会话)

关键在于，ACP 已经允许单个智能体“同时提供”多个会话。所以这意味着如果我有一个代理，也许它提供了一个 MCP 工具定义，我可以使用它来启动全新的会话——结合我上面提到的“历史重播”能力，该工具可以精确控制要带入该会话的起始上下文，这非常酷（这对今天的 MCP 服务器来说是一个挑战，它们无法访问对话历史记录）。

sequenceDiagram
    participant E as Editor
    participant P as Proxy
    participant A as Agent
    
    A->>P: ide_operation("...")
    activate P
    P->>A: new_session
    activate P
    activate A
    P->>A: prompt("Using these primitive operations, suggest a way to do '...'")
    A->>P: ...
    A->>P: end_turn
    deactivate P
    deactivate A
    Note over P: 执行计划
    P->>A: 工具返回结果
    deactivate P
  

结论

好的，本文勾勒了我对 ACP 的一个变体，我称之为 SymmACP。SymmACP 扩展了 ACP，增加了

• 允许任何一方（而不仅是服务器）提供对话初始状态的能力
• 允许“编辑器”向“智能体”提供 MCP 工具的能力
• 允许智能体在没有初始提示的情况下响应的能力
• 能够序列化对话并附加额外状态（这已经部分存在）的能力

在我看来，这些扩展中的大多数都是对 ACP 的适度扩展，并且很容易通过添加新功能向后兼容地实现。但它们共同解锁了让任何人都能构建智能体扩展并以可组合方式部署的能力。我对此非常兴奋。这正是我希望 Symposium 所代表的。

值得注意一句老话：“能力越大，责任越大”。我一直谈论的这些代理和 ACP 层实际上就像 IDE 扩展。它们可以有效地做到任何你能做到的事情。存在明显的安全顾虑。不过我认为像微软的 Wassette 这样的方法是关键——如果能有一个“基于能力”的概念来定义“代理层”，所有内容都编译为 WASM，并且用户可以调整给定代理实际能做什么，那就太棒了。

我计划在 Symposium 和其他地方开始勾勒推动这项工作的计划。我的目标是建立一个完全开放且可互操作的客户端，它可以基于任何智能体（包括本地智能体），并且你可以挑选你想使用的任何部分。我预计会构建大量自定义功能来支持 Rust 开发（例如，使用新的 trait 求解器解释和诊断 trait 错误在我计划中优先级很高……还有宏错误……），但也会拥有其他功能，如引导、协作交互风格等，这些都是语言无关的——我也希望能看到针对其他语言的语言特性，特别是 Python 和 TypeScript（因为“新三驾马车”），以及 Swift 和 Kotlin（因为移动端）。如果这个愿景让你兴奋，请加入 Symposium Zulip 让我们聊聊！

附录：我所了解的智能体协议指南

在讨论这个话题时，我经常被问到它与其他众多协议相比如何。让我简要概述一下相关工作以及我理解的它们的优缺点：

• 模型上下文协议 (MCP): 其中的王者。一个为智能体提供一组工具、提示和资源的协议。智能体可以通过提供适当的参数（JSON 格式）来调用工具。提示是用户可以使用特殊命令（如 / 或 @）调用的快捷方式，它们本质上是宏，可以“如同用户输入一样”展开（但它们也可以有参数并被动态构建）。资源只是可以请求的数据。MCP 服务器可以是本地的，也可以是远程托管的。远程 MCP 最近才成为一个选项，特别是在认证方面还很有限。
  • 与 SymmACP 的比较：MCP 提供智能体可以调用的工具。SymmACP 在此之上构建，允许这些工具由代理链中的外层提供。SymmACP 面向控制整个聊天“体验”。
• Zed 的智能体客户端协议 (ACP): SymmACP 的基础。允许编辑器创建和管理会话。仅关注本地会话，因为你的编辑器在本地运行。
  • 与 SymmACP 的比较：这正是本文讨论的内容！SymmACP 扩展了 ACP，增加了新功能，让中间层可以操纵历史记录、提供工具，并向上游提供扩展数据以支持比纯聊天更丰富的交互模式。另外，我预计我们可能想支持更多的远程能力，但这在我看来有点正交（例如，我希望能使用运行在云托管工作站上的智能体，但我可能会借助 ssh 来实现）。
• 谷歌的智能体对智能体协议 (A2A) 和 IBM 的智能体通信协议 (ACP)⁵: 据我了解，谷歌的“智能体对智能体”协议有点像 MCP 和 OpenAPI 的混合体。你可以 ping 运行在远程的智能体，让它们向你发送“智能体卡”，这些卡描述了它们可以执行的操作、如何认证以及其他类似内容。在我看来，它与 MCP 非常相似，只是它对远程执行的支持更丰富，特别是支持像长时间运行的通信这样的事情，其中智能体可能需要去工作一段时间，然后通过 webhook 反向 ping 你。
  • 与 MCP 的比较： 在我看来，A2A 看起来像是面向远程执行的 MCP 变体。MCP 有一个工具发现方法，你 ping 服务器以获取工具列表；A2A 有一个类似的机制，使用智能体卡。MCP 可以在本地运行，而 A2A 根据我的了解不行，但 A2A 在认证方面有更多的选项。MCP 只能同步调用，而 A2A 支持长时间运行的操作、进度更新和回调。看起来两者可以合并成一个整体。
  • 与 SymmACP 的比较： 我认为 A2A 与 SymmACP 是正交的。A2A 面向相互提供服务的智能体。SymmACP 面向为与智能体交互构建新的开发工具。你有可能可以基于 A2A 构建类似 SymmACP 的东西，但我不知道这样做真正能获得什么好处（并且我认为以后很容易做）。

由 mimo-v2.5 模型翻译，花费 16481 tokens

在继续我关于“人体工程学引用计数”的讨论时，我想聚焦于核心问题：用户是否必须显式地调用 handle/clone，还是不应该？ 整个“人体工程学引用计数”工作最初是由Dioxus提出的，他们的回答很简单：绝对不应该。对于他们正在构建的那类高级GUI应用程序而言，必须调用 cx.handle() 来克隆一个引用计数值纯粹是噪声。事实上，对于许多Rust应用来说，即使是克隆一个字符串或向量也没什么大不了的。另一方面，对于许多应用程序，答案是绝对应该——知道句柄创建的位置会影响性能、内存使用，甚至正确性（别担心，我稍后会在文章中举例说明）。那么我们如何调和这一点呢？

本文主张，我们应该让“显式”变得符合人体工程学。这并非我一贯的立场，但在与Josh Triplett进行了一次有影响力的对话后，我转变了看法。我认为这符合我曾经所说的Rust的灵魂：我们想要符合人体工程学，没错，但我们想要在保持控制力的同时符合人体工程学¹。

我喜欢Tyler Mandry提出的“目标明确”构念：*“伟大的代码只将你应用程序的重要特征带到你的注意力面前。”*关键在于，*存在这样的伟大代码，在其中克隆和句柄是重要的特征*，因此我们需要让这类代码能够被优雅地表达出来。这一点尤其重要，因为Rust是为数不多真正以那种低层、基础性代码为目标的语言之一。

这并不意味着我们不能（稍后）支持自动的克隆和句柄。不可否认，这对许多Rust代码的目标明确性有益。但我认为我们应该首先关注更困难的情况，即需要显式性的那种情况，并尽力将其做得足够好；然后我们可以回头决定是否也支持某种自动化。事实上，对我来说，一个问题是我们是否能让“完全显式”变得足够好，以至于我们真的不需要自动版本。保持“一个Rust”有其好处，其中所有代码大致遵循相同的模式，这些模式在某些时候是完美的，而在它们过于繁琐时也不会太糟²。

“Rust不应让你感到意外。”（致谢：Josh Triplett）

我提到这篇博文源于与Josh Triplett的一次长谈³。那次对话中让我印象深刻的关键短语是：Rust不应让你感到意外。我的理解是这样的。每个程序员都知道那种马拉松式调试的感觉——坐着盯着代码看上几天，心里想着，但是……这怎么可能发生呢？这类问题排查可能以几种不同的方式结束。偶尔，你会发现逻辑中一个令人满足的微妙bug。更多时候，你发现你写了 if foo 而不是 if !foo。而偶尔，你会发现你的语言在做一些你意想不到的事情。一些看起来简单的代码隐藏着微妙而复杂的交互。人们常称这种为陷阱。

总体而言，Rust在避免陷阱方面做得非常出色⁴。我们实现这一目标的部分方法是确保你可能需要知道的信息是可见的——即在源代码中是显式的。每次你看到一个Rust的match语句，你都不必问自己“这里可能缺少哪些情况”——编译器保证所有情况都已覆盖。当你看到一个Rust函数调用时，你也不必问自己它是否会失败——如果可能失败，你会看到一个 ?⁵。

创建句柄绝对可能“让你感到意外”

所以我想问题在于：你是否曾经需要知道引用计数的增加？棘手之处在于答案取决于应用。对于一些底层应用，绝对需要：原子引用计数是可衡量的开销。老实说，我敢打赌存在这种需求的应用集非常小。即使在那些应用中，Rust通过让你能够在 Rc 和 Arc 之间进行选择并证明你不会搞砸，已经比当前技术有所改进。

但还有其他原因你可能想要跟踪引用计数，这些原因更不容忽视。其中之一是内存泄漏。与垃圾回收语言不同，Rust具有确定性析构。这很酷，因为这意味着你可以利用析构函数来管理各种资源，正如Yehuda很久以前在他关于RAII的经典颂歌“Rust意味着永远不必关闭套接字”中所写的那样。但是，尽管句柄创建和销毁的点是确定的，引用计数的本质使得预测底层资源何时真正被释放变得更加困难。如果这些增量在代码中不可见，就更难追踪它们了。

就在最近，我调试了用Swift编写的Symposium。不知何故，我本应只有一个 IPCManager 实例，却出现了两个，而且每个实例都在响应每条IPC消息，造成了混乱。在翻找中，我在一些意想不到的地方发现了游离的引用，这就是问题的根源。如果我必须显式地编写 .handle() 来增加引用计数，这个bug是否还会发生？绝对会。事后是否更容易找到？也是肯定的⁶。

Josh给了我一个来自“bytes” crate的类似例子。Bytes类型是指向某个底层内存缓冲区的句柄。当你克隆这个句柄时，它会保留整个后备缓冲区。有时你可能更愿意将你的切片复制到一个单独的缓冲区中，以便底层缓冲区可以被释放。我不难想象，试图追踪一个让某个大缓冲区保持存活的错误句柄，并且因为无法在代码中显式地看到这些句柄创建的位置而感到非常沮丧。

类似的案例也出现在像 Arc::get_mut⁷ 这样的API中。 get_mut 接受一个 &mut Arc<T>，如果引用计数为1，则返回一个 &mut T。这让你能够获取一个可共享的句柄（你确信它实际上并未被共享），并恢复其唯一性。这类API并不常用——但当你需要它时，它就在那里，非常棒。

“我喜欢Rust是因为它的多功能性：一门语言涵盖底层到高层”（致谢：Alex Crichton）

在与Josh的对话开始时，我倾向于一种设计，其中句柄有某种形式的自动克隆，以及一个默认允许的lint，让那些不想要这样做的crate可以将其关闭。但Josh说服我，存在相当一部分应用程序，它们希望句柄创建既符合人体工程学又可见（即在源代码中是显式的）。底层网络服务，甚至像Rust for Linux这样的项目可能都属于此类，但任何使用 get_mut 或 make_mut 的Rust应用也可能如此。

这让我想起Alex Crichton曾经对我说过的话。与这里的其他引用不同，它并非在人体工程学引用计数的语境下，而是在我致力于“Rust使用者原则”的首次尝试时。Alex当时说，他喜欢Rust不仅对底层代码很棒，对CLI工具和简单脚本等高层内容也同样适用。

我觉得你可以从两个方面解读Alex的引言，取决于你强调什么。你可以将其理解为，“Rust对高层用例有益这一点很重要。”这是真的，也正是它促使我们思考是否应该让句柄可见。

但你也可以将Alex的引言解读为，“有一门语言能同时很好地满足两者的需求，这一点很重要”——我认为这也是对的。“真正的Rust整体精神”在于我们成功地同时赋予你底层代码所需的低层控制，又将其包裹在高层的包装中。这当然是零成本抽象的承诺，而Rust（在最佳时刻）实现了这一点。

“Rust的灵魂”：底层到足以编写内核，易用到足以构建GUI

老实说，高级GUI编程并非Rust的强项，也永远不会是；用户永远不会将Rust与TypeScript混淆。但同样，TypeScript也永远不会出现在Linux内核中。

Rust的目标是成为一门大体上能对两者都“足够好”的语言。目标是向内核黑客暴露足够多的底层细节，同时以一种对GUI足够易用的方式来实现。这并非易事，但这是职责所在。

这不是Josh第一次将我拉回这个认识。上一次是在讨论dyn trait中的async fn时，它促成了一篇讨论“Rust的灵魂”的博文以及一篇更详细阐述的后续文章。我认为“底层到足以编写内核，易用到足以构建GUI”这句口号很好地概括了这一点。

结论：显式句柄应该是第一步，但不一定是最后一步

我想补充一个小告诫。我认为Rust灵魂的另一部分是偏爱细微差别而非人为的简单化（“尽可能简单，但不要过于简单”，正如他们所说）。现实情况是，有大量的应用程序（尤其但不限于异步领域⁸）会到处创建新句柄，而显式创建新句柄是噪声，而非信号。这就是为什么例如Swift⁹让引用计数增量不可见——他们从中获益良多！¹⁰我敢打赌大多数Swift用户甚至没有意识到Swift不是垃圾回收的¹¹。

但关键在于，即使我们添加某种方式使句柄创建自动化，我们也希望有一个模式是显式且可见的。所以我们不妨先实现这个。

好的，我想我已经从三个角度阐述了这个观点，就此打住。本系列的接下来的几篇博文将深入探讨（至少）两种选项，关于如何在保持显式性的同时，让句柄创建和闭包变得更符合人体工程学。

由 mimo-v2.5 模型翻译，花费 9633 tokens

本文提出了一项扩展 Rust 以支持多种不同析构器的提案。这意味着我们可以实现异步丢弃，同时也能防止值被“遗忘”（泄漏），从而支持类似 rayon/libstd 风格的并行异步作用域任务。我们还将能够定义其“析构器”需要参数的类型。这一提案——我称之为“受控析构”——是我之前提出的“必须移动”概念的演进。我认为，要让 Rust 实现其系统编程关键模式安全版本的目标，这是必要的。因此，这也是实现“异步梦想”所必需的，即让异步 Rust 和同步 Rust 大致工作方式相同。

如此好事不会凭空而来。该提案的主要代价是它在 Rust 类型中引入了更多“核心划分”。我相信这些划分动机充分且合理——它们反映了内在的复杂性——尽管如此，我们仍需仔细思考。

摘要

提案的要点在于，我们应该：

• 引入一个新的“默认 trait 约束” Forget 及其关联的 trait 层次结构：
  • trait Forget: Drop，表示可以被“遗忘”的值。
  • trait Destruct: Move，表示具有析构器的值。
  • trait Move: Pointee，表示可以被移动的值。
  • trait Pointee，基础 trait，表示任何值。
• 使用类似 RFC #3729（Sized 层次结构） 中为 Sized 特性提出的“选择退出较弱默认值”方案。
  • 因此，fn foo<T>(t: T) 默认意为“一个可以被遗忘/析构/移动的 T”。
  • 而 fn foo<T: Destruct>(t: T) 则表示“一个可以被析构，但不一定能被遗忘的 T”。
  • 而 fn foo<T: Move>(t: T) 表示“一个可以被移动，但不一定能被遗忘的 T”。
  • ……以此类推。
• 集成并执行新的 trait：
  • std::mem::forget 的约束将已经要求 Forget，这很好。
  • 借用检查器可以强制要求任何被丢弃的值必须实现 Destruct；事实上，我们已经在 const fn 中通过此方式来强制 const Destruct 约束。
  • 借用检查器可以扩展，要求任何被移动的值具有 Move 约束。
• 调整闭包的 trait 约束（幸运的是，这相当容易实现）。

动机

在我几年前于乌拉圭 Rust LATAM 大会上的一次演讲¹中，我这样说过：

• 暴露高性能 API 很容易。
• 但帮助用户控制它却很难——而这正是 Rust 类型系统所做的。

Rust 目前在防止程序各部分相互干扰方面做得相当好，但在保证清理工作发生²方面做得不够。我们当然有析构器，但它们有两个关键限制：

• 所有析构器必须符合相同的签名 fn drop(&mut self)，这并不总是足够的。
• 一旦放弃值的所有权，就无法保证析构器会运行。

具体化

上述动机较为抽象，让我给出一些与此局限相关的具体示例：

• 支持 async 或 const 丢弃的能力，两者都需要不同的丢弃签名。
• 支持一个需要参数的“丢弃”操作，例如必须发送的消息，或在程序终止前必须提供的结果代码。
• 支持可以访问栈的异步作用域，这需要一种方式来保证并行线程在异步上下文中也能被 join。
• 以最大效率与 WebAssembly 异步任务集成的能力，这需要保证清理³。

本文的目标是概述一种可能解决上述所有问题且与当前 Rust 向后兼容的方法。

值处置的“能力”

核心问题在于，Rust 今天假设每个 Sized 的值都可以被移动、丢弃和遗忘：

// 除了知道 `T` 是 `Sized` 的，我们还能...
fn demonstration<T>(a: T, b: T, c: T) {
    // ...丢弃 `a`，立即运行其析构器。
    std::mem::drop(a);

    // ...遗忘 `b`，跳过其析构器。
    std::mem::forget(b);

    // ...移动 `c` 到 `x`
    let x = c;
} // ...然后当离开块时，让 `x` 被自动丢弃。

析构器就像“选择退出方法”

在我看来，大多数方法是“选择加入”的——除非你调用它们，否则不会执行。但析构器不同。它们实际上是一种默认运行的方法——除非你选择退出，例如通过调用 forget。但选择退出的能力意味着它们本质上不比普通方法增加任何功能，只是让 API 更人性化。

这意味着，在当前 Rust 中，保证析构器会运行的唯一方式是保留值的所有权。这对不安全代码可能很重要——例如，允许作用域线程的 API 需要保证这些并行线程在函数返回前被 join。他们实现这一点的唯一方式是使用一个对 scope 提供 & 借用访问的闭包：

scope(|s| ...)
//     -  --- ...这确保了此
//     |      函数体不能“遗忘”它。
//     |
// 这个值的类型是 `&Scope`...

因为该 API 从不放弃作用域的所有权，所以它可以确保它永远不会被“遗忘”，从而保证其析构器会运行。

作用域线程方法适用于同步代码，但不适用于异步代码。问题在于异步函数返回一个 future，它是一个值。因此用户可以选择“遗忘”这个值，就像任何其他值一样，从而导致析构器可能永远不会运行。

保证清理在系统编程中很常见

当你开始探索时，会发现保证的析构器在系统编程中相当常见。future 中的作用域 API 是一个例子，但 DMA（直接内存访问）是另一个。许多嵌入式设备有一种模式，你开始一次 DMA 传输，导致内存异步写入。但你需要确保在释放该内存之前终止此 DMA。如果该内存在你的栈上，这意味着你需要一个析构器来取消 DMA 或阻塞直到完成⁴。

那么我们能做什么？

这种情况与重新审视默认 Sized 约束的挑战非常类似，我认为我在[这篇博文][sized]中概述的相同基本方法会奏效。

核心思想很简单：有一组“特殊”的 trait 构成层次结构：

trait Forget: Destruct {} // 可以被“遗忘”
trait Destruct: Move {}   // 可以被“析构”（丢弃）
trait Move: Pointee {}    // 可以被“移动”
trait Pointee {}          // 可以被指针引用

默认情况下，泛型参数会获得 Forget 约束，因此 fn foo<T>() 等同于 fn foo<T: Forget>()。但如果参数选择一个更弱的约束，则默认值会被抑制，所以 fn bar<T: Destruct>() 意味着 T 被假定为“可析构的”但不是可遗忘的。而 fn baz<T: Move>() 表示 T 只能被移动。

这些约束的影响

让我简要解释这些约束将如何工作。

默认可以遗忘、丢弃、移动等

给定一个默认类型 T，或者显式写 Forget 的类型，函数可以执行当前可能的所有操作：

fn just_forget<T: Forget>(a: T, b: T, c: T) {
    //         --------- 这个约束是默认的
    std::mem::drop(a);   // 正常
    std::mem::forget(b); // 正常
    let x = c;           // 正常
}

forget 函数要求 T: Forget

std::mem::forget 函数也将要求 T: Forget：

pub fn forget<T: Forget>(value: T) { /* magic intrinsic */ }

这意味着如果你只有 Destruct，函数只能丢弃或移动，不能“遗忘”：

fn just_destruct<T: Destruct>(a: T, b: T, c: T) {
    //           -----------
    // 此函数仅请求“Destruct”能力。

    std::mem::drop(a);   // 正常
    std::mem::forget(b); // 错误：需要 `T: Forget`
    let x = c;           // 正常
}

借用检查器将要求“丢弃”的值实现 Destruct

我们将修改 drop 函数，仅要求 T: Destruct：

fn drop<T: Destruct>(t: T) {}

我们还将扩展借用检查器，使其在看到值被丢弃（即，因为它离开作用域）时，要求 Destruct 约束。

这意味着如果你有一个类型仅实现 Move 的值，你无法“丢弃”它：

fn just_move<T: Move>(a: T, b: T, c: T) {
    //           -----------
    // 此函数仅请求“Move”能力。

    std::mem::drop(a);   // 错误：需要 `T: Destruct`
    std::mem::forget(b); // 错误：需要 `T: Forget`
    let x = c;           // 正常
}                        // 错误：`x` 正在被丢弃，但 `T: Destruct`

这意味着如果你只有 Move 约束，你必须移动你拥有的任何东西才能从函数返回。例如：

fn return_ok<T: Move>(a: T) -> T {
    a // 正常
}

如果你有一个不移动的函数，你会得到一个错误：

fn return_err<T: Move>(a: T) -> T {
} // 错误：`a` 未实现 `Destruct`

值得指出的是，在 panic 面前，这将会非常恼人：

fn return_err<T: Move>(a: T) -> T {
    // 错误：如果发生 panic，`a` 将被丢弃，但 `T` 未实现 `Destruct`
    forbid_env_var();

    a
}

fn forbid_env_var() {
    if std::env::var("BAD").is_ok() {
        panic!("Uh oh: BAD cannot be set");
    }
}

我对此可以接受，但这将迫使我们寻求更好的方式来静态排除 panic。

const（以及未来的 async）Destruct 变体

实际上，我们已经在 const 函数中做了类似丢弃检查的事情。现在如果你有一个 const fn 并尝试丢弃一个值，你会得到一个错误：

const fn test<T>(t: T) {
} // 错误！

编译它会产生错误：

error[E0493]: destructor of `T` cannot be evaluated at compile-time
 --> src/lib.rs:1:18
  |
1 | const fn test<T>(t: T) { }
  |                  ^       - value is dropped here
  |                  |
  |                  the destructor for this type cannot be evaluated in constant functions

目前这个检查并未在借用检查器中进行，但它可以。

借用检查器将要求“移动”的值实现 Move

检查的最后一部分将是要求“移动”的值实现 Move：

fn return_err<T: Pointee>(a: T) -> T {
    a // 错误：`a` 未实现 `Move`
}

你可能认为拥有 !Move 的类型会取代对 pin 的需要，但事实并非如此。一个被固定的值是永远不能再移动的值，而一个不是 Move 的值则根本无法被移动——至少一旦它被存储到一个位置后是这样。

我不确定提案的这部分是否有意义，我们可以先让所有类型都是 Move、Destruct 或（默认的）Forget。

选择退出遗忘等

提案的另一部分是你应该能够显式“选择退出”遗忘能力，例如通过这样做：

struct MyType {}
impl Destruct for MyType {}

这样做当然会限制可以接受你类型的泛型。

关联类型约束

这些“默认约束”提案最棘手的部分总是关联类型约束。为了向后兼容，我们必须默认到 Forget，但许多现有关联类型实际上并不需要 Forget。例如，像 Add 这样的 trait 其返回类型其实应该只要求 Move：

trait Add<Rhs = Self> {
    type Output /* : Move */;
}

我基本上不太担心这个。我们可能随时间或通过版本削弱这些约束。或者，也许添加某种版本特定的“别名”，如：

trait Add2025<Rhs = Self> {
    type Output: Move;
}

其中 Add2025 为所有实现了 Add 的类型实现。

我不确定具体如何管理，但我们会弄清楚的——与此同时，大多数不应被遗忘的类型其实只是不必流经太多地方的“守卫”类型。

闭包中的关联类型约束

我认为一个确实重要需要削弱关联类型约束的地方是闭包——幸运的是，由于我们的“闭包 trait 约束”语法的工作方式，这是我们可以做到的地方。我记得我之前写过一篇关于此的文章，但现在找不到了，简短版本是：今天，当你写 F: Fn() 时，意味着闭包必须返回 ()。如果你写 F: Fn() -> T，那么这个类型 T 必须在其他地方声明，因此 T 将（独立于 Fn trait 的关联类型）获得一个默认的 Forget 约束。因此，由于 Fn 关联类型在稳定 Rust 中不能独立命名，我们可以更改其约束，而像这样的代码将继续正常工作：

fn foo<T, F>()
where
    F: Fn() -> T,
    //         - `T: Forget` 仍默认成立
{}

常见问题

这与最近在 internals 上的讨论有何关联？

最近有人向我指出了这个 internals 讨论，关于一个“子结构类型系统”，它可能具有非常相似的能力。老实说，我还没有时间去阅读和消化它！但我这篇博文已经完成了 95%，所以我决定先发布它，然后再去尝试比较。

结构体选择退出 Move（例如，仅实现 Pointee）意味着什么？

因此，我描述的系统会允许“不可移动”类型（即选择退出所有功能，只允许 Pointee 的结构体），但这样的结构体实际上只能存储在静态内存位置。你不能把它放在栈上，因为栈最终必须被弹出。你也不能把它从一个位置移动到另一个位置，因为，它是不可移动的。

这似乎是有用的——例如，建模“视频 RAM”或生活在内存特定位置而不能在其他任何地方的东西——但这并非广泛需求。

如何处理带参数的析构器？

我想象类似这样的东西：

struct Transaction {
    data: Vec<u8>
}

/// 选择退出析构
impl Move for Transaction { }

impl Transaction {
    // 这实际上是一个“析构器”
    pub fn complete(
        self,
        connection: Connection,
    ) {
        let Transaction { data } = self;
    }
}

通过这种设置，任何拥有 Transaction 的函数都必须最终调用 transaction.complete()。这是因为这种类型的值不能被丢弃，所以它们必须被移动。

这与异步丢弃有何关联？

这种设置解决了阻碍我心目中异步丢弃的一个关键问题，即“异步丢弃”的类型不必实现“同步丢弃”。这使得类型系统能够防止它们在同步代码中被丢弃，这意味着它们只能在异步丢弃中被丢弃。但那里仍然有大量的设计工作要做。

为什么 trait 是 Destruct 而不是 Drop？

这来自 const 泛型的工作。我不喜欢这样。但有其逻辑。现在，当你丢弃一个结构体或其他值时，实际上会执行一系列操作，其中只有一项是运行任何 Drop 实现——例如，它还会递归丢弃结构体中的所有字段等。其思想是“析构”指的是这整个序列。

原型实现有多难？

我……实际上认为不会很难。我已经思考过一些，所有这些更改似乎都相当直接。我很乐意支持一个语言团队实验。

这是否意味着我们应该有 leak？

析构器和泄漏等整个话题可以追溯到大约 Rust 1.0，当时我们发现，实际上，我们的线程抽象在与循环引用计数的 box 结合使用时是不健全的。在此之前，我们还没有完全内化析构器是“选择退出的方法”。你可以阅读我当时写的这篇博文。当时，主要想法是某种 ?Leak 约束，并且它与引用的概念相关（因此所有 'static 数据被假定为“可泄漏的”，因此你可以放入 Rc）。我……基本上认为当时我们做出了正确的选择。我认为生态系统中的大部分是可互操作的，Rc 不需要 static 约束是好的，当然我认为我们以最小的干扰转向 1.0 是好的。无论如何，我更喜欢这个设计，而不是当时讨论的那些设计，部分原因是它还解决了需要不同类型析构器和带多个参数的析构器等问题，而这些在当时我们没有考虑到。

拥有这些“选择退出”默认约束的“魔法” trait 不会令人困惑吗？

我认为指定你想要的约束本质上比今天的 ? 设计更好，不仅因为它更容易理解，还因为它允许我们向后兼容地以 ? 设计不可能的方式添加中间 trait。

然而，我确实看到 T: Move 意味着 T: Destruct 不成立是微妙的。我想知道我们是否应该在这些 trait 上采用某种符号或约定，比如 T: @Move 或类似的东西。我不知道！需要考虑的事情。

由 mimo-v2.5 模型翻译，花费 26151 tokens

对我提出的 Handle trait 提案，目前主要有两大类反馈。第一类是：该 trait 似乎有用，但无法涵盖所有需要便捷克隆的场景。第二类是：该名称不符合 Rust 的 trait 命名惯例——Rust 倾向于使用简短的动词而非名词。我的回应要点如下：（1）我同意，因此我认为应同时致力于让 Clone 和 Handle 都符合人体工程学；（2）我也同意，因此我认为需要另寻一个名称。目前我倾向于 Share，其次是 Alias。

Handle 无法涵盖所有情况

关于 Handle trait 的第一个顾虑是：虽然它为何时实现该 trait 提供了清晰的语义基础，但并未覆盖所有调用 clone 令人烦恼的场景。换句话说，如果我们选择使用 Handle，并使其创建过程非常符合人体工程学，但调用 clone 依然痛苦，那么当 Handle 并不适用时，人们可能仍会忍不住使用它。

在我们语言团队的一次设计会议上，TC 指出：对于许多应用而言，即使一次“昂贵的”克隆也并非真正大问题。例如，在编写命令行工具等程序时，我经常克隆字符串、字符串向量、哈希表和其他各种数据；我可以将它们放入 Rc 或 Arc，但我知道这其实无关紧要。

我的解决方案很简单：让我们提出一套能同时应用于 Clone 和 Handle 的方案。鉴于我认为需要一个提案，允许句柄既符合人体工程学又保持显式，那么将该解决方案扩展至包含克隆选项也并非难事。

显式捕获子句的博文已符合此设计理念。我明确选择了一种设计，允许用户编写 move(a.b.c.clone()) 或 move(a.b.c.handle())，因此它能同样好地（或同样不好地……）同时适用于这两个 trait。

名称 Handle 不符合 Rust 惯例

许多人指出 Handle 不符合 Rust 对此类 trait 的命名惯例，这些惯例旨在使用简短的动词。你可以将 handle 解释为动词，但其含义并非我们所指。这很合理。我原本喜欢 Handle 这个名称，因为它提供了一个我们可以用来谈论句柄的名词，但我同意该 trait 名称似乎并不合适。围绕可能的选项进行了大量自行车棚化讨论，但我想我最终回到了更倾向于 Jack Huey 的原始提案 Share（对应方法 share）。我认为 Alias 和 alias 是我的第二选择。两者都是简短且相对常用的动词。

我最初觉得 Share 有点过于通用，且容易让人联想到线程间共享——但我至少总是称 &T 为共享引用¹，而 &T 将实现 Share，所以一切似乎都配合得很好。感谢 Ariel Ben-Yehuda 推动我选择这个特定名称。

后续计划

本系列中的一系列博文旨在概述此领域已进行的所有讨论。我的目标尚非撰写最终提案——我认为最终成果将是一系列 RFC。

我目前的想法是：我们应该添加 Hand^H^H^H^H，呃，Share trait。我也认为应该添加显式捕获子句。然而，虽然显式捕获子句显然“足够底层以用于内核”，但我并不认为它们“足够易用以用于 GUI”。下一篇文章将探讨另一个想法，我认为它可能让我们更接近最终的符合人体工程学且显式的目标。

由 mimo-v2.5 模型翻译，花费 3019 tokens

嗯，当我重读我几分钟前刚发布的帖子时，我开始思考。也许正确的名称确实是Alias，而不是Share。理由很简单：alias既可以作为名词也可以作为动词。它正好符合“足够常见你知道它的意思，但又足够独特可以成为Rust里某个特定东西的术语”这个甜蜜点。就像我们说“传递一个foo的克隆”一样，我们可以谈论“传递一个指向foo的别名”或“一个foo的别名”。值得思考！我打算在以后的帖子中试试用Alias，看看感觉如何。

由 mimo-v2.5 模型翻译，花费 688 tokens

本文探讨了人体工程学引用计数领域的另一项提案，我称之为移动表达式。在我看来，这是显式捕获子句的替代方案，它以更佳的人体工程学和可读性，实现了该设计中的许多（但并非全部）目标。

太长不看版

理念本身很简单：在闭包（或 future）中，我们增加书写move($expr)的选项。这是一个值表达式（"右值"），它会脱糖为一个临时值，该值被移入闭包。因此

|| something(&move($expr))

大致等价于：

{ 
    let tmp = $expr;
    || something(&{tmp})
}

实践中的效果

让我们回到我们的一个常见示例——"Cloudflare 示例"，它最初来自Dioxus 团队的这篇精彩博文。提醒一下，以下是代码现在的样子——注意那些用于处理捕获的let _some_value = ...行：

// 任务：监听 dns 连接
let _some_a = self.some_a.clone();
let _some_b = self.some_b.clone();
let _some_c = self.some_c.clone();
tokio::task::spawn(async move {
  	do_something_else_with(_some_a, _some_b, _some_c)
});

在该提案下，它将大致如下所示：

tokio::task::spawn(async {
    do_something_else_with(
        move(self.some_a.clone()),
        move(self.some_b.clone()),
        move(self.some_c.clone()),
    )
});

有时你需要多个克隆。例如，如果你想将某些内容移入一个FnMut闭包，该闭包随后会在每次调用时放弃一个副本，它可能看起来像这样

data_source_iter
    .inspect(|item| {
        inspect_item(item, move(tx.clone()).clone())
        //                      ----------  -------
        //                           |         |
        //                   将一个克隆移动     |
        //                   到闭包中          |
        //                                     |
        //                             每次迭代时克隆该克隆
    })
    .collect();

// 一些后续使用 `tx` 的代码...

致谢

这个想法并非我首创。它已被多次提出。我记得第一次听说是在 RustConf 未安排会议期间，但我感觉它更早之前就已出现。最近的一次是由Zachary Harrold 在 Zulip 上提出的，他还创建了一个名为soupa的原型。Zachary 的提案（以及我之前听说的更早提案）使用了super关键字。后来@simulacrum 提议使用move，这对我来说是一个重大改进，因此我在此采用了这个版本。

此提案使闭包更具"连续性"

我喜欢这个提案的move变体的原因是，它使闭包更具"连续性"，并更清晰地揭示了其底层模型。有了这个设计，我会从使用移动表达式的闭包开始讲解，最后才教move闭包，将其作为一种便捷的默认方式：

Rust 闭包以"最简方式"捕获你在闭包中使用的位置——因此|| vec.len()会捕获对vec的共享引用，|| vec.push(22)会捕获可变引用，而|| drop(vec)会获取向量的所有权。

你可以使用move表达式来精确控制捕获的内容：因此|| move(vec).push(22)会将vector移入闭包。当你想要完全显式时，一种常见模式是在闭包顶部列出所有捕获，如下所示：

|| {
    let vec = move(input.vec); // 完全获取 vec 的所有权
    let data = move(&cx.data); // 获取对 data 的引用
    let output_tx = move(output_tx); // 获取输出通道的所有权

    process(&vec, &mut output_tx, data)
}

作为简写，你可以在闭包顶部写move ||，这将改变默认行为，使闭包获取所有捕获变量的所有权。你仍然可以使用move表达式进行混合搭配以获得更多控制。因此，前面的闭包可以更简洁地写成这样：

move || {
    process(&input.vec, &mut output_tx, move(&cx.data))
    //       ---------       ---------       --------      
    //           |               |               |         
    //           |               |       闭包仍然
    //           |               |       捕获对 `&cx.data` 的引用
    //           |               |                         
    //           |               |                         
    //           由于闭包上的 `move` 关键字，
    //           这两个是"按移动"捕获的
    //       
}

此提案使move对我来说"更契合"

有点讽刺的是我喜欢这个，因为它加强了 Rust 设计中我最近一直在抱怨的部分。在我之前关于显式捕获子句的文章中，我写道：

老实说，我不喜欢move的选择，因为它太操作化了。我想，如果我能够回到过去，我会尝试围绕两个概念来重塑我们的闭包

• 依附闭包（我们现在称之为||）将总是绑定到外部栈帧。即使它们没有捕获任何内容，它们也始终具有生命周期。
• 分离闭包（我们现在称之为move ||）将按值捕获，就像今天的move一样。

我认为这将有助于建立"如果你要将闭包从当前栈帧返回，使用detach ||，否则使用||"的直觉。

移动表达式，我认为，正朝着相反的方向前进。它们没有谈论依附和分离，而是将我们带向更统一的闭包概念，在那里你没有"引用闭包"和"移动闭包"——你只是拥有有时捕获移动的闭包，而"移动"闭包只是在所有地方都使用move表达式的简写。这实际上正是闭包在编译器底层的工作方式，我认为这非常优雅。

为什么不用后缀？

一个问题是移动表达式应该是前缀还是后缀运算符。例如

|| something(&$expr.move)

而不是&move($expr)。

我的感觉是，它不适合后缀运算符，因为它不仅仅处理表达式的最终值然后对其做些什么，它实际上影响整个表达式的求值时间。考虑这个例子：

|| process(foo(bar()).move)

bar() 何时被调用？如果你仔细想想，它必须在闭包创建时调用，但这并不非常"明显"。

当我们考虑 .unsafe 运算符时，得出了类似的结论。我认为有一条经验法则：那些划定代码"范围"的东西应该是前缀——尽管我怀疑 unsafe(expr) 可能实际上不错，而不仅仅是 unsafe { expr }。

编辑：我在后记中添加了这部分内容以回应问题。

结论

我将在此结束本文。老实说，这种设计真正拥有的优势，超越其他一切，是其简洁性以及它如何泛化 Rust 现有设计的方式。我喜欢这一点。对我来说，它加入了"是的，我们显然应该那样做"的拼图集合：

• 添加一个 Share trait（我已回到更喜欢 share 这个名称 🙂）
• 添加移动表达式

这两者似乎都是坚实的进步。我尚未被说服它们能达到我在早期文章中阐述的目标：

"底层到足以用于内核，易用到足以用于 GUI"

但它们正朝着正确的方向前进。

由 mimo-v2.5 模型翻译，花费 12660 tokens

早在 2021 年，我开始尝试一门我称之为“达达”的新编程语言。自那以后，我一直都在捣鼓它，而我刚刚才意识到（天哪！）我居然从未为此写过一篇博文！我想我该修正这一点。这篇文章将介绍当前达达语言的一些基本概念。

在你产生任何想法之前，达达目前还不适合使用。事实上，编译器甚至都无法正常工作，因为我总是在它完全完成之前就修改这门语言。老实说，达达对我来说更像一个“减压阀”¹——摆弄一门不用操心向后兼容性、RFC 或其他任何事情的编程语言很有趣。

话虽如此，达达一直是创意的沃土，我认为这些想法可能适用于 Rust。而且不仅仅是语言设计：摆弄编译器也促成了新版 salsa 的设计²，它现在被 rust-analyzer 和 Astral 的 ty 使用。所以我真的很想把这些想法分享出去！

我休息了一阵，但现在回归了，宝贝！

大约一年前³，我停止了折腾达达，但过去几天我又开始重新工作。然后我意识到，嘿，现在正是开始写博客的绝佳时机！毕竟，无论如何我都要重新回忆起之前的进展，而写作总是厘清细节的最佳方式。

达达始于渐进式编程实验，但已不再是

达达经历了许多阶段。早期的目标是构建一门渐进类型化的编程语言，我认为它会更容易让人们学习。

这个想法是，你可以完全不写任何类型就直接开始编写并执行程序。有一个交互式演练场，可以让你在进行过程中逐步查看和可视化“借用检查器”状态（达达称之为权限）。我的希望是，人们会发现这比直接使用类型检查器更容易上手。

我实现了这个功能，它实际上非常酷。我在 2022 年的编程语言指导研讨会上就此做了演讲，不过快速浏览一下视频，我似乎并没有真正演示权限建模。太可惜了。

与此同时，我发现自己并不完全信服渐进式方法。我希望的是，当你在没有类型注解的情况下执行程序时，你能在违反借用规则的地方获得错误。这意味着程序必须跟踪大量额外数据，有点像 miri 的做法，而这实际上只适合作为教学工具。我仍然想探索这一点，但它也为语言设计增加了很多复杂性，而这点可能只在开发者学习旅程的早期有用⁴。

因此，我决定从头再来，这次只专注于达达的静态类型检查部分。

达达就像一个精简的 Rust

今天的达达就像 Rust，但经过了精简。目标是让达达拥有与 Rust 相同的基本“所有权导向”的感觉，但需要处理的选择和琐碎细节要少得多⁵。

Rust 经常有语义等价但表示不同的类型。考虑 &Option<String> 和 Option<&String>：它们在功能上是等价的，但 Rust 当然会要求你仔细区分它们。在达达中，它们是同一个类型。达达也让 &Vec<String>、&Vec<&String>、&[String]、&[&str] 以及许多其他变体都成为同一类型。在你问之前，它不是通过堆分配所有东西或使用垃圾收集器来实现的。

简而言之，达达旨在成为“让你永远不必调用 as_ref() 的 Rust”。

达达拥有一个更精巧的借用检查器

达达还有一个更精巧的借用检查器，它已经展示了内部借用检查器的许多特性，尽管它还没有视图类型。达达的借用检查器支持内部借用（例如，你可以创建一个结构体，其字段从其他字段借用），并且支持无生命周期的借用检查。这些东西有很多可以引入 Rust，尽管我在达达中调整了一些东西，使得某些方面更容易实现。

达达原生以 WebAssembly 为目标

在重新聚焦达达的过程中，我决定专注于构建 WebAssembly 组件。最初，我认为以 WebAssembly 为目标会非常方便：

• WebAssembly 就像一个非常简单干净的汇编语言，所以编写编译器后端很容易。
• WebAssembly 组件被明确设计用来桥接不同语言，所以它们为你解决了 FFI 问题。
• 借助 WASI，你甚至能获得一个功能齐全的标准库，包含诸如“获取网页”之类的高级功能。因此你可以立即构建有用的东西。

WebAssembly 与按需编译 = 几乎免费获得编译时反射

但我逐渐意识到，以 WebAssembly 为目标还有另一个优势：它使得编译时反射几乎变得微不足道。达达编译器采用纯按需方式构建。这意味着我们可以将一个函数一直编译成 WebAssembly 字节码，而让 crate 的其余部分保持不变。

一旦我们有了 WebAssembly 字节码，我们就可以在编译器内部运行它！借助 wasmtime，我们有一个高质量的 JIT，运行速度非常快。代码甚至还是沙箱化的！

因此，我们可以有一个函数，在执行期间编译并运行它，并用它来生成其他代码，供编译过程的后续步骤使用。换句话说，我们基本上免费获得了类似 miri 或 Zig 的 comptime 的东西。哇哦。

希望你能试试它？我也想！

天哪，写这篇博文让我自己也兴奋起来想玩达达了。可惜它实际上还不能用。哈哈！但我计划继续推进编译器，尽快让它达到可以现场演示的程度。具体要多久还很难说。

同时，为了帮助我重新了解它的工作原理，我打算尝试写一系列关于类型系统、借用检查器和编译器架构的博文，我认为这些都很有趣。

由 mimo-v2.5 模型翻译，花费 5576 tokens

继我的“达达之乐”一文之后，本篇将开始教授达达语言。我会保持每篇文章简短——基本上就是趁喝晨间咖啡的时间能写多少算多少。¹

你有权编写代码

这是一个最基础的达达程序

println("Hello, Dada!")

我想大家都能猜出它的功能。但即便在这个简单的程序中，也有些值得注意之处：

“你有权编写代码。如果你没有显式编写 main 函数，系统会为你提供一个。” 我很早就做了这个改动，允许用户省略 main 函数，结果很惊讶它对语言轻盈感的提升如此明显。改动虽小，收效却大。

便利即默认

这是另一个达达程序

let name = "Dada"
println("Hello, {name}!")

不出所料，这个程序与上一个功能相同。

“便利即默认。” 字符串默认支持插值（即 {name}）。实际上，这还不是全部，它们还能非常方便地跨行书写。下面这个程序与我们见过的前几个效果一致：

let name = "Dada"
println("
    Hello, {name}!
")

当引号 " 后直接跟换行时，开头和结尾的换行符会被去除，后续行的“空白前缀”也会被移除。内部的换行符会被保留，因此像下面这样的代码：

let name = "Dada"
println("
    Hello, {name}!
    
    How are you doing?
")

会输出：

Hello, Dada!

How are you doing?

只有一种熟悉的 String

当然，你也可以显式标注 name 变量的类型：

let name: String = "Dada"
println("Hello, {name}!")

你会发现类型是 String。这本身并不特别，除非你习惯了 Rust，那里的类型会是 &'static str。这无疑是 Rust 新手的常见绊脚石，但更重要的是，我发现它是个大麻烦——我讨厌在任何需要混合常量字符串和动态构造字符串的地方，都得写 "Foo".to_string() 或 format!("Foo")。

与大多数现代语言类似，达达中的字符串是不可变的。因此你可以创建并复制它们：

let name: String = "Dada"
let greeting: String = "Hello, {name}"
let name2: String = name

接下来：变更与权限

好了，这里我们真的只是蜻蜓点水！这只是达达的“友好外衣”，它看起来和感觉上与千百万其他语言相似。下次我将开始介绍权限系统和变更机制，那里会更有趣一些。

由 mimo-v2.5 模型翻译，花费 3226 tokens

让我们继续学习Dada。在我的上一篇文章中，我介绍了一些字符串操作。现在让我们开始讨论权限。这是Dada开始更像Rust的地方。

类斗争

Dada中的类是我们声明新类型的基本方式之一（还有枚举，我们稍后会讲到）。

最方便的声明类的方法是将字段放在括号中。这同时隐式声明了一个构造函数：

class Point(x: u32, y: u32) {}

这实际上是更Rust风格形式的语法糖：

class Point {
    x: u32
    y: u32
    fn new() -> Point {
        Point { x, y }
    }
}

你可以通过调用构造函数来创建类的实例：

let p = Point(22, 44) // Point.new(22, 44)的语法糖

变更字段

我可以如你所预期地变更p的字段：

p.x += 1
p.x = p.y

默认只读

在Dada中，声明参数时的默认是获得只读访问权限：

fn print_point(p: Point) {
    print("The point is {p.x}, {p.y}")
}

let p = Point(22, 44)
print_point(p)

如果你尝试变更参数的字段，那会得到一个错误：

fn print_point(p: Point) {
    p.x += 1 # <-- 错误！
}

使用!进行变更

如果你用!声明一个参数，那么它就变成调用者传入的类实例的可变引用：

fn translate_point(point!: Point, x: u32, y: u32) {
    point.x += x
    point.y += y
}

在Rust中，这类似于point: &mut Point。当你调用translate_point时，你也放一个!来表示你传递一个可变引用：

let p = Point(22, 44)     # 创建点
print_point(p)            # 打印 22, 44
translate_point(p!, 2, 2) # 变更点
print_point(p)            # 打印 24, 46 

如你所见，当translate_point修改p.x时，它在原地改变了p。

移动是显式的

如果你熟悉Rust，最后一个例子可能有点令人惊讶。在Rust中，像print_point(p)这样的调用会移动p，交出所有权。之后尝试使用它会得到错误。这是因为Dada的默认是提供只读引用，类似于Rust中的&x（这给出了正确的直觉，但也具有误导性；我们将在未来的一篇文章中看到Dada中的引用与Rust在一个非常重要的方面有所不同）。

如果你有一个函数需要其参数的所有权，你用given来声明：

fn take_point(p: given Point) {
    // ...
}

而在调用者方面，你用.give调用这样的函数：

let p = Point(22, 44)
take_point(p.give)
take_point(p.give) # <-- 错误！不能给两次。

与Rust比较

比较一些Rust和Dada代码并排很有趣：

设计原理与目标

便捷是默认的

最便捷的事物是最短和最常见的。因此我们将读取作为默认。

一切显式但不突兀

Rust中的.运算符根据所调用的方法可以做各种事情。它可能变更、移动、创建临时对象等。在Dada中，这些事情都在调用点可见——但它们不突兀。

这实际上源于Dada的“渐进式编程”时代——毕竟，如果你在方法上没有类型注解，那么你就无法决定foo.bar()应该共享借用还是可变借用foo。所以我们需要一种在调用点显式可见的表示法。

后缀运算符与其他运算符配合更好

Dada努力避免像&mut这样的前缀运算符，因为它们与.表示法配合不佳。

由 mimo-v2.5 模型翻译，花费 5881 tokens

我们的目标是在没有GC的情况下获得类似GC的体验

让我们从目标开始：早些时候，我说达达就像“你永远不必输入as_ref的Rust”。但我真正的意思是，我想要一种类似GC的体验——但没有GC。

我们的目标是获得一种“可组合”的体验

我也经常使用“可组合”一词来描述我追求的达达体验。可组合意味着你可以将不同的事物组合在一起以实现新的功能。

显然，Rust有许多可组合的模式——例如Iterator API。但我发现的是，Rust代码通常非常脆弱：在如何声明数据结构方面有许多选择，而你所做的选择将决定这些数据结构如何被使用。

贯穿示例：Character

定义Character类型

让我们创建一个可以在整篇文章中作为示例的类型：Character。在Rust中，我们可能会这样定义一个Character：

#[derive(Default)]
struct Character {
    name: String,
    class: String,
    hp: u32,
}

创建并Arc包裹Character

现在，假设由于某种原因，我们要以编程方式构建一个角色：

let mut ch = Character::default();
ch.name.push_str("Ferris");
ch.class.push_str("Rustacean");
ch.hp = 44;

到目前为止，一切都很好。现在假设我想共享同一个Character结构体，以便可以从许多地方引用它而无需深拷贝。为此，我将把它放入一个Arc中：

let mut ch = Character::default();
ch.name.push_str("Ferris");
// ...
let ch1 = Arc::new(ch);
let ch2 = ch1.clone();

好的，很酷！现在我有了一个可以轻松共享的Character。这很好。

Rust在这里是可组合的，这很酷，我们喜欢这样

旁注，但这是Rust可组合的一个例子：我们以一种完全拥有的方式定义了Character一次，并且我们能够可变地使用它（随着时间的推移以命令式方式构建它），然后能够“冻结”它并获得一个只读的、共享的Character副本。这让我们既获得了命令式编程语言的优势（易于数据构造和操作），又获得了函数式语言的优势（不可变性可以防止当事物从许多不相交的地方被引用时出现错误）。很好！

创建并Arc包裹Character

现在，假设我有其他一些独立编写的代码，仅仅需要存储角色的名字。该代码最终将名字复制到许多不同的地方。因此，就像我们使用Arc让我们能够从多个地方廉价地引用单个角色一样，它使用Arc以便可以从多个地方廉价地引用角色的名字：

struct CharacterSheetWidget {
    // 使用 `Arc<String>` 而不是 `String` 因为我们最终
    // 会将其复制到不同的地方，而我们不想每次都深度克隆
    // 该字符串。
    name: Arc<String>,

    // ... 假设这里还有更多字段 ...
}

好的。现在问题来了。我想从我们的共享角色创建一个角色卡控件：

fn create_character_sheet_widget(ch: Arc<Character>) -> CharacterSheetWidget {
    CharacterSheetWidget {
        // FIXME: 咦，我该如何弥合这个鸿沟？
        // 我想我必须这样做。
        name: Arc::new(ch.name.clone()),

        // ... 假设这里还有更多字段 ...
    }
}

哎，这真令人沮丧！我想做的是写name: ch.name.clone()或类似的东西（实际上我可能想直接写ch.name，但不管怎样），然后得到一个Arc<String>。但我做不到。相反，我必须深度克隆字符串并且分配一个新的Arc。当然，任何后续的克隆都会很便宜。但这不太好。

Rust经常导致这类“阻抗不匹配”

我经常在Rust中发现这类模式：一段代码和另一段代码之间存在某种“阻抗不匹配”。解决方案各不相同，但通常类似：

• 克隆一些数据——反正它也不大，管它呢（这里就是这种情况）。
• 重构一段代码——例如，修改Character类以存储Arc<String>。当然，这会产生连锁反应，例如，我们不能再写ch.name.push_str(...)了，而必须使用Arc::get_mut之类的。
• 调用一些烦人的辅助函数——例如，编写opt.as_ref()将&Option<String>转换为Option<&String>，或编写&**r将&Arc<String>转换为&str。

达达的目标就是我们不需要这类事情。

共享是达达的复制方式

那么让我们来看看同一个Character示例在达达中会如何实现。我们将首先定义Character类：

class Character(
    name: String,
    klass: String,  # 哎呀，class关键字的危险！
    hp: u32,
)

就像在Rust中一样，我们可以创建角色，然后对其进行修改：

class Character(name: String, klass: String, hp: u32)

let ch: given Character = Character("", "", 22)
      # ----- 记住，“given”权限
      #       意味着 `ch` 是完全拥有的
ch.name!.push("Tzara")
ch.klass!.push("Dadaist")
   #    - 而 `!` 表示可变性

.share 运算符创建一个 shared 对象

好的。现在，我想共享这个角色，以便可以从许多地方引用它。在Rust中，我们创建了一个Arc，但在达达中，共享是“内置的”。我们使用.share运算符，它将把given Character（即完全拥有的角色）转换为shared Character：

class Character(name: String, klass: String, hp: u32)

let ch = Character("", "", 22)
ch!.push("Tzara")
ch!.push("Dadaist")

let ch1: shared Character = ch.share
      #  ------                -----
      # `share` 运算符消费 `ch`
      # 并返回同一个对象，但现在具有
      # *共享* 权限。

shared 对象可以自由复制

现在我们有了一个shared角色，我们可以复制它了：

class Character(name: String, klass: String, hp: u32)

# 创建一个共享角色作为开始
let ch1 = Character("Tzara", "Dadaist", 22).share
    #                                       -----

# 创建另一个共享角色
let ch2 = ch1

共享从所有者传播到字段

当你有一个共享对象并访问其字段时，你得到的是该字段的共享（浅）副本：

class Character(...)

# 创建一个 `shared Character`
let ch: shared Character = Character("Tristan Tzara", "Dadaist", 22).share
      # ------                                                       -----

# 提取 `name` 字段会得到一个 `shared String`
let name: shared String = ch1.name
        # ------

使用Vec进行传播

为了突出这一点多么酷和方便，想象一下我有一个Vec[String]，我用.share共享它：

let v: shared Vec[String] = ["Hello", "Dada"].share

然后我用v.share共享它。我得到的是一个shared Vec[String]。当我访问它的元素时，我得到的是一个shared String：

let v = ["Hello", "Dada"].share
let s: shared String = v[0]

这就像在Rust中可以取一个Arc<Vec<String>>并从中得到一个Arc<String>一样。

共享是如何实现的

那么共享是如何实现的呢？答案在于一个并非完全显而易见的内存布局。要了解它的工作原理，让我们看看Character在内存中是如何布局的：

# 我们之前看到的 Character 类型。
class Character(name: String, klass: String, hp: u32)

# String 类型可能类似这样。
class String {
    buffer: Pointer[char]
    initialized: usize
    length: usize
}

这里的Pointer是一个内置类型，它是达达不安全代码系统的基础。¹

given Character在内存中的布局

现在想象我们有一个这样的Character：

let ch = Character("Duchamp", "Dadaist", 22)

角色ch在内存中的布局大概像这样（只关注name字段）：

[栈帧]                    [堆]
ch: Character {
    _flag: 1
    name: String {
        _flag: 1         { _ref_count: 1
        buffer: ──────────►'D'
        initialized: 7     ...
        capacity: 8        'p' }
    }
    klass: ...
    hp: 22
}

让我们解释一下。首先，每个对象在内存中都是扁平布局的，就像你在Rust中看到的那样。因此ch的字段存储在栈上，而name字段就在其中扁平布局。

每个拥有其他对象的对象都以一个隐藏字段_flag开始。此字段指示对象是否共享（未来我们将添加更多值以解释其他权限）。如果字段为1，则对象未共享。如果为2，则共享。

堆分配的对象（即使用Pointer[]）以引用计数开始，然后才是实际数据（实际上是在偏移量-4处）。在这种情况下，我们有一个Pointer[char]，因此随后的实际数据只是简单的字符。

shared Character在内存中的布局

如果我改为创建一个共享角色：

let ch1 = Character("Duchamp", "Dadaist", 22).share
          #                                   -----

内存布局将相同，但角色上的标志字段现在是2：

[栈帧]                    [堆]
ch: Character {
    _flag: 2 👈 (现在是 2 了!)
    name: String {
        _flag: 1         { _ref_count: 1
        buffer: ──────────►'D'
        initialized: 7     ...
        capacity: 8        'p' }
    }
    klass: ...
    hp: 22
}

复制一个shared Character

现在想象我们创建了同一个共享角色的两个副本：

let ch1 = Character("Duchamp", "Dadaist", 22).share
let ch2 = ch1

发生的情况是，我们将复制_ch1的所有字段，然后因为_flag是2，我们将递增其中堆分配数据的引用计数：

[栈帧]                    [堆]
ch1: Character {
    _flag: 2
    name: String {
        _flag: 1         { _ref_count: 2
        buffer: ────────┬─►'D'        👆
        initialized: 7  │  ...      (现在是
        capacity: 8     │  'p' }     2 了!)
    }                   │
    class: ...          │
    hp: 22              │
}                       │
                        │
ch2: Character {        │
    _flag: 2            │
    name: String {      │
        _flag: 1        │
        buffer: ────────┘
        initialized: 7
        capacity: 8
    }
    class: ...
    hp: 22
}

复制出name字段

现在想象我们要复制出name字段，而不是整个角色：

let ch1 = Character("Duchamp", "Dadaist", 22).share
let name = ch1.name

……发生的是：

1. 遍历ch1，我们观察到_flag字段是2，因此ch1是共享的
2. 我们从name中复制出String字段。因为角色是共享的：
   • 我们将新字符串上的_flag字段修改为2
   • 我们为任何堆值递增引用计数

结果是你得到：

[栈帧]                    [堆]
ch1: Character {
    _flag: 2
    name: String {
        _flag: 1         { _ref_count: 2
        buffer: ────────┬─►'D'
        initialized: 7  │  ...
        capacity: 8     │  'p' }
    }                   │
    class: ...          │
    hp: 22              │
}                       │
                        │
name: String {          │
    _flag: 2            │
    buffer: ────────────┘
    initialized: 7
    capacity: 8
}

“共享传播”是权限传播的一个例子

这篇文章展示了达达中的shared值如何工作，并展示了当你访问字段时shared权限如何传播。权限是达达管理对象生命周期的方式。到目前为止我们已经看到了两种：

• given权限表示唯一拥有的值（用Rust的术语来说是T）；
• shared权限表示可复制的值（最接近的Rust等价物是Arc<T>）。

在未来的文章中，我们将看到ref和mut权限，它们大致对应于&和&mut，并讨论整个系统如何协同工作。

达达不仅仅是一个漂亮的外表

这是我们开始看到达达更多特点的第一篇文章。回顾之前的几篇文章，你可能会认为达达只是在熟悉的Rust语法之上套了一个可爱的语法。但正如你从shared的工作方式所看到的，达达远不止于此。

我倾向于将达达视为某种意义上的“固执己见的Rust”。与Rust不同，它对做事方式强加了一些标准。例如，每个对象（至少每个具有堆分配字段的对象）都有一个_flag字段。每个堆分配都有一个引用计数。

这些约定带来了一些适度的运行时成本。我的规则是，基本操作允许执行“浅层”操作，例如切换_flag或调整每个字段的引用计数。但它们不能执行需要遍历堆结构的“深层”操作。

作为采用这些约定并支付这些成本的交换，你得到了“可组合性”，我的意思是达达中的权限（如shared）流动得更加自然，并且语义上等价的类型（即你可以用它们做相同事情的类型）通常在内存中具有相同的布局。

由 mimo-v2.5 模型翻译，花费 14972 tokens

好的，我刚从 Rust Nation 回来，正忙着用（公认很糟糕的）英语口音尝试吓唬我十几岁的女儿¹。这是一次很棒的旅行，有很多好的对话和一些有趣的观察。我打算就其中一些内容写博客，从 Jon Seager 的闭幕主题演讲 "Rust Adoption At Scale with Ubuntu" 激发的一些思考开始。

世界上有许多鸿沟

一段时间以来，我一直在自我辩论，Rust 是否已经"跨越了鸿沟"？如果你不熟悉这个术语，它来自一本书，该书以一种"流行科学"的方式介绍了技术采用生命周期。

答案当然是取决于你问谁。在我最了解的 Amazon 内部，答案是我们"大部分已经跨越了"：Rust 已稳固确立为构建大规模数据平面或资源感知代理的正确方式，并且越来越被视为设备和机器人领域底层代码的正确选择——但仍然存在一种挥之不去的看法，认为 Rust 对"那些在 S3（或其他地方）的奇才开发者"很有用，但对于更普通的开发则有点杀鸡用牛刀³。

另一方面，在安全关键软件领域，正如 Pete LeVasseur 在最近的 rust-lang 博客文章中所写，Rust 仍在努力争取立足之地。有一些成功的产品，但大多数行业仍处于"观望"模式，让早期采用者铺平道路。

“跨越鸿沟”意味着找到“标杆客户”

至少我从阅读《跨越鸿沟》和关于技术采用生命周期的其他资料中得到的主要观点是需要"标杆客户"。当你刚开始接触新事物时，你寻找的是被新事物吸引的先驱者和早期采用者：

早期采用者购买的是某种变革推动剂。通过成为行业内率先实施这一变革的人，早期采用者期望在竞争中抢先一步。——摘自《跨越鸿沟》

但随着你的技术成熟，你必须说服风险承受能力越来越低的人：

早期主流人群希望购买现有运营的效率提升。他们希望最小化与旧有方式的断裂。他们想要的是进化，而非革命。——摘自《跨越鸿沟》

那么，对人们来说最令人信服去尝试新事物的是什么？答案是看到其他与他们类似的人已经成功了。

你可以在 Amazon 的例子和安全关键软件的例子中看到这一点。显然，在网络服务中看到 Rust 的使用并不意味着它已准备好用于你汽车的转向柱⁴。即使在网络服务领域，看到像 S3 这样的团队用 Rust 取得成功，可能会说服其他构建大规模服务的团队尝试 Rust，但不一定能说服一个团队在他们的下一个 CRUD 服务中使用 Rust。坦率地说，这也不应该说服他们！他们很可能会遇到障碍。

Ubuntu 正在帮助 Rust 跨越“（用户态 Linux）鸿沟”

所有这些想法在我观看 Canonical 公司（Ubuntu 背后的公司）工程副总裁 Jon Seager 的主题演讲时都在我脑海中浮现。类似于 Lars Bergstrom 多年前关于 Google 内部 Rust 采用的史诗级演讲，Jon 阐述了 Canonical 采用 Rust 的理由，这个理由既富有远见又极其务实。

"富有远见而又极其务实"几乎是我们从早期采用者跨越到早期主流所需事物的教科书式描述。我们需要的是那些首先关心交付正确结果，但对可能帮助他们做得更好的新想法持开放态度的人；那些能够同时站在鸿沟两侧的人。

Jon 描述了 Canonical 如何将其自身的开发集中在少数几种语言上：Python、C/C++ 和 Go，以及他们最近如何引入 Rust 并将其作为新的基础设施工作的首选语言，以取代 C、C++ 和（部分使用的）Python。

Ubuntu 正在建造跨越鸿沟的桥梁

Jon 谈到他认为 Ubuntu 的工作之一是通过支持构建内存安全的基础设施工具来"向前投资"。Jon 所说的支持既包括财务上的——Canonical 赞助了 Trifecta Tech Foundation 开发 sudo-rs 和 ntpd-rs，并赞助了 uutils org 的 coreutils 工作——也包括声誉上的。Ubuntu 可以承担尝试新事物的风险，证明其可行，然后让其他人受益。

还记得《跨越鸿沟》这本书如何描述早期主流人群吗？他们"希望最小化与旧有方式的断裂"。还有什么比拥有可直接替换的、能融入他们现有工作流的工具更好的方式呢？

Rust 的挑战：倾听这些新采用者

新的采用带来了新的视角。周四晚上，我参加了一个由 Ernest Kissiedu⁶ 组织的晚宴⁵。Jon Seager 和来自各行各业的其他一些 Rust 采用者在场，还有来自 Rust 基金会和开源项目的其他几位成员。

Ernest 请他们给我们谈谈对 Rust 的真实看法。Jon 提出了一个挑衅性的评论，即我们需要重新审视关于拥有小型标准库的政策。他不是第一个这样说的人，这是我们多年来一直听到的事情——而且我认为他是对的！虽然我认为答案不仅仅是发布一个庞大的标准库。事实上，这恰好为（我希望能够）写的下一篇关于一个我称之为"电池组"⁷ 的项目的博客文章做了铺垫。

要成长，就必须改变

更广泛的观点是，从面向"先驱者"和"早期采用者"转变为面向"早期主流"，有时需要一些令人不适的改变：

任何两个采用群体之间的过渡通常都极其尴尬，因为你必须在旧有策略最得心应手的时候采用新的策略。[...] 如果这家高科技公司在刚刚取得面向远见者的营销成功后，忽略了改变其销售说辞，情况可能会进一步复杂化。[...] 公司可能说的是"最先进的"，而实用主义者想听的是"行业标准"。 ——摘自《跨越鸿沟》（强调为本人所加）

不是所有人都会记得，但在 2016 年有一个名为“Rust 平台”的提案。其想法是引入一些 crate 并将其作为某种"扩展标准库"来认可。人们讨厌它。毕竟，他们说，为什么不直接在你的 Cargo.toml 中添加依赖呢？这很容易。老实说，他们是对的——至少在当时是这样。

我认为 "Rust 平台"是一个很好的例子，说明了某些东西如何不适合早期采用者（他们想要最新最好的东西，不介意自己寻找最佳的 crate），但可能非常适合早期主流人群⁸。

无论如何，我写这篇文章不是为了支持或反对某件事，而是为了表达一种理念：我们必须对将我们学到的智慧适应新环境持开放态度。过去，我们试图让 Rust 进入行业的意识——我们已经成功了。

我们现在面临的任务不同：我们需要让 Rust 成为最佳选择，不仅是在"它可能成为"的方面，更是在"它实际上"的方面——有时这两者是紧张的。

Rust 的另一个挑战：将采用转化为投资

晚宴后半段，话题像往常一样转向了资金。Rust 采用的增长也意味着 Rust 项目及其生态系统面临的需求增长。我们如何将这些点连接起来？这一直是我思考的一个重点，在写这段话时我意识到关于这个话题我还有多少博客文章要写，但让我先概述一下这次晚宴和最近其他场合提出的一些有趣观点。

投资可以意味着贡献，尤其是对于开源组织

首先，提供支持的方式不止金钱。对于 Canonical 这样彻头彻尾的开源组织，我最希望的是建立我们组织之间更牢固的关系。对于 Rust for Linux 开发者来说，早期 Rust 维护者代表 RfL 开发者优先处理和修复 bug，但现在越来越多的是 RfL 开发者自己修复问题，Rust 维护者担任导师角色。这太棒了！

资金往往在公司采用 Rust 之前到来，而非之后

其次，关于资金我看到了一个有趣的现象。我们通常认为公司投资于他们依赖的开源依赖项。但还有一个完全不同的资金来源，而且可能更容易获取，那就是寻找那些正在考虑 Rust 但尚未采用它的公司。

对于那些"潜在"采用者，组织中通常有个人在努力为采用 Rust 做论证——这些个人是早期采用者，是对事物可能如何发展有远见的人，但他们试图向他们务实、早期主流的公司推销。为了做到这一点，他们通常有一份需要支持的"基本功能"清单；更重要的是，他们通常有一些预算来让这些事情发生。

这是我在与基金会的银牌成员目录负责人 Alexandru Radovici 交谈时提到的，他说许多安全关键公司有他们想花掉的钱来弥补 Rust 中的各种差距，但他们不知道如何花。Jon 对 Trifecta Tech 和 uutils org 的投资具有同样的性质：他试图弥补阻碍 Ubuntu 更广泛使用 Rust 的差距。

结论…？

首先，你应该看看 Jon 的演讲。"精彩"，就像英国人说的那样。

但我的另一个主要想法是，现在是 Rust 的一个关键时刻。我们显然在多个领域从远见者和早期采用者转向务实的早期主流，我们需要意识到这样做可能需要我们改变一些一直以来的行事方式。我喜欢《跨越鸿沟》中的这段话：

要成功地向实用主义者营销，你不必成为一个实用主义者——只需理解他们的价值观并努力服务于他们。要更深入地了解这些价值观，如果说远见者的目标是实现量子跃迁，那么实用主义者的目标就是实现百分比改进——渐进的、可衡量的、可预测的进步。[...] 要向实用主义者营销，你必须要有耐心。你需要精通主导他们特定业务的问题。你需要出现在他们参加的行业特定会议和贸易展览会上。

重读《跨越鸿沟》作为撰写这篇博客文章的一部分，真正帮助我理清了 Rust 目前所处的位置——我认为在大多数情况下，我们仍在跨越鸿沟，但我们已经走了很长一段路。我认为我们看到的是一个持续的趋势，即我们有符合早期采用者"远见者"形象的 Rust倡导者，他们成功地在符合实用主义者、早期主流形象的公司内倡导 Rust。

开源可以成为跨越鸿沟的强大助力……

对我来说，开源正是进行这种营销的一个绝佳平台。与公司不同，我们不必事事亲力亲为。我们必须利用这样一个事实：开源帮助那些自助者——找到那些行业中可能真正受益于 Rust 的远见者，将他们纳入 Rust 的圈子，然后（最重要的是！）支持和赋能他们以适应自己的需求。

……但前提是我们不要对此太“中学化”

最后这部分听起来可能很简单，但做起来比说的难。当你沉浸于开源时，它看起来像是一个友好、欢迎所有人的地方。但现实是，它可能充满小圈子和"口头传统"，即"每个人都知道"的事情⁹。带着想法来的人可能会因为用了错误的词语而被否定。他们很容易将随机贡献者（或者可能只是个喷子……）的，呃，"充满激情"的评论误认为是项目领导层的官方意见。只需要一次粗鲁的回应就能把人吓跑。

Rust 最需要的是同理心

那么，最终能帮助 Rust 最大程度成功的将是什么？开源中的同理心。让我们走出去，找出 Rust 能在哪里帮助人们，并付诸行动。激动人心的时刻！

由 mimo-v2.5 模型翻译，花费 10186 tokens

在我之前的Dada博文中，我讨论了Dada如何实现可组合共享。今天，我将开始深入探讨Dada的权限系统；权限是Dada中相当于Rust借用检查器的机制。

目标：更丰富的基于位置的权限

Dada旨在通过使用基于位置的权限来超越Rust的能力。Dada允许你编写函数和类型，它们能同时捕获一个值和从该值借用的东西。

举个有趣的例子，假设你正在编写一些Rust代码来处理逗号分隔的列表，只查找长度为5或更长的条目：

let list: String = format!("...something big, with commas...");
let items: Vec<&str> = list
    .split(",")
    .map(|s| s.trim()) // 去除空白字符
    .filter(|s| s.len() > 5)
    .collect();

Rust的酷炫之处在于这段代码看起来很像Python或JavaScript等高级语言，但在那些语言中，split调用将进行大量工作，因为它必须分配大量小字符串并复制数据。但在Rust中，&str值只是指向原始字符串的指针，因此split非常高效。我喜欢这一点。

另一方面，假设你想将其中一些值连同原始字符串打包，并发送到另一个线程进行处理。你可能认为你可以创建一个像这样的结构体……

struct Message {
    list: String,
    items: Vec<&str>,
    //         ----
    // 目标是持有一个引用
    // 指向list中的字符串
}

……然后创建列表和项目并将它们存入其中：

let list: String = format!("...something big, with commas...");
let items: Vec<&str> = /* 如前所述 */;
let message = Message { list, items };
//                      ----
//                        |
// 这会*移动*`list`到结构体中。
// 这又会使`items`失效，而`items`
// 是从`list`借用的，因此无法
// 构造`Message`。

但正如经验丰富的Rust开发者所知，这行不通。当你有像&str这样的借用数据时，这些数据不能被移动。如果你想处理这种情况，你需要从&str转换为发送索引、拥有的字符串或其他解决方案。唉！

Dada的权限使用位置，而非生命周期

Dada的处理方式有些不同。首先，当你创建引用时，产生的类型命名的是数据被借用的位置，而非引用的生命周期。因此，items的类型注解会是ref[list] String¹（至少，如果你想写出完整细节而不是留给类型推断器的话）：

let list: given String = "...something big, with commas..."
let items: given Vec[ref[list] String] = list
    .split(",")
    .map(_.trim()) // 去除空白字符
    .filter(_.len() > 5)
    //      ------- 我*认为*这是闭包的语法？
    //              我忘了当初的想法，还没实现。
    .collect()

我之前在博客中谈到过我如何想在Rust中重新定义生命周期为位置，因为我觉得像ref[list] String这样的类型更容易教学和解释：你不必解释生命周期引用代码的某个部分，而是可以说“这是一个引用变量list的String”。

但更酷的是，命名位置为更灵活的借用打开了大门。在Dada中，如果你想打包列表和项目，你可以像这样构建Message类型：

class Message(
    list: String
    items: Vec[ref[self.list] String]
    //             ---------
    //   从另一个字段借用！
)

// 如前所述：
let list: String = "...something big, with commas..."
let items: Vec[ref[list] String] = list
    .split(",")
    .map(_.strip()) // 去除空白字符
    .filter(_.len() > 5)
    .collect()

// 创建消息，有趣的部分在这里！
let message = Message(list.give, items.give)

注意最后一行——Message(list.give, items.give)。我们可以创建一个新的类，并将list移动到其中，同时移动items，而items是从list借用的。很巧妙，对吧？

好的，让我们回顾一下这一切是如何工作的。

Dada中的引用是默认行为

让我们从语法开始。在深入Message示例之前，我想回到之前文章中的Character示例，因为它解释起来更简单。这是一些Rust代码，声明了一个Character结构体，创建了它的一个拥有副本，然后获取了它的几个引用。

struct Character {
    name: String,
    class: String,
    hp: u32,
}

let ch: Character = Character {
    name: format!("Ferris"),
    class: format!("Rustacean"),
    hp: 22
};

let p: &Character = &ch;
let q: &String = &p.name;

Dada中等效的代码如下所示：

class Character(
    name: String,
    klass: String,
    hp: u32,
)

let ch: Character = Character("Tzara", "Dadaist", 22)
let p: ref[ch] Character = ch
let q: ref[p] String = p.name

首先要注意的是，在Dada中，当你命名一个变量或位置时，默认行为是创建一个引用。因此let p = ch不会像Rust那样移动ch，而是创建一个对存储在ch中的Character的引用。你也可以显式地写let p = ch.ref，但这不是首选。类似地，let q = p.name创建了一个对字段name中值的引用。（如果你想移动这个角色，你会写let ch2 = ch.give，而不是像Rust中那样写let ch2 = ch。）

注意我说let p = ch“创建了一个对存储在ch中的Character的引用”。特别地，我没有说“创建了一个对ch的引用”。这是一个微妙的措辞选择，但有着重大的影响。

Dada中的引用不是指针

我之所以写let p = ch“创建了一个对存储在ch中的Character的引用”而不是“创建了一个对ch的引用”，是因为在Dada中，引用不是指针。相反，它们是值的浅拷贝，非常像我们在上一篇文章中看到的shared Character虽然行为像Arc<Character>，但表示为浅拷贝。

所以在Rust中，下面这段代码……

let ch = Character { ... };
let p = &ch;
let q = &ch.name;

……在内存中看起来像这样……

        # Rust内存表示

            栈空间                     堆空间
            ─────                       ────

┌───► ch: Character {
│ ┌───► name: String {
│ │         buffer: ───────────► "Ferris"
│ │         长度: 6
│ │         容量: 12
│ │     },
│ │     ...
│ │   }
│ │   
└──── p
  │
  └── q

而在Dada中，像这样的代码

let ch = Character(...)
let p = ch
let q = ch.name

会看起来像这样

# Dada内存表示

栈空间                     堆空间
─────                     ────

ch: Character {
    name: String {
            buffer: ───────┬───► "Ferris"
            长度: 6        │
            容量: 12       │
    },                     │
    ..                     │
}                          │
                           │
p: Character {             │
    name: String {         │
            buffer: ───────┤
            长度: 6        │
            容量: 12       │
    ...                    │
}                          │
    }                      │
                           │
q: String {                │
    buffer: ───────────────┘
    长度: 6
    容量: 12
}

显然，Dada的表示在栈上占用了更多内存。但注意它没有复制堆中的内存，而堆通常是绝大多数数据所在的地方。

Dada谈论的是值而非引用

这触及了一些重要的东西。像C一样，Rust将指针视为一等公民。所以给定x: &String，x指的是指针，而*x指的是它的指称物String。

像Java一样，Dada走了另一条路。x: ref String就是一个String值——包括内存表示！given String、shared String和ref String之间的区别不在于它们的内存布局，它们都是相同的，而在于它们是否拥有其内容。²

所以在Dada中，没有*x操作来从“指针”到“指称物”。这没有意义。你的变量总是包含一个字符串，但你使用该字符串的权限会改变。

实际上，目标是让人们在学习Dada时不必学习内存表示，你应该能够像在Java或Python中那样将Dada变量视为堆上的所有对象，即使它们实际上是存储在栈上的。³

Rust不允许移动借用的数据

在Rust中，你不能在值被借用时移动它们。所以如果你有像这样的代码，将ch移动到ch1中……

let ch = Character { ... };
let name = &ch.name; // 创建引用
let ch1 = ch;        // 移动`ch`

……那么这段代码只有在name不再被使用时才能编译：

let ch = Character { ... };
let name = &ch.name; // 创建引用
let ch1 = ch;        // 错误：借用时不能移动
let name1 = name;    // 再次使用引用

……但Dada可以

Rust禁止移动借用的数据有两个原因：

• 引用是指针，因此这些指针可能会失效。在上面的例子中，name指向ch的栈空间，所以如果ch被移动到ch1中，这会使引用失效。
• 类型系统会失去跟踪。在内部，Rust借用检查器有一种“间接”关系。它知道ch在代码的某个范围内被借用（一个“生命周期”），并且它知道name类型中的生命周期与该生命周期相关，但它并不真正知道name是从ch借用的。⁴

这些都不适用于Dada：

• 因为引用不是指向栈的指针，而是浅拷贝，所以移动借用的值不会使它们的内容失效。它们保持有效。
• 因为Dada的类型引用的是实际的变量名，我们可以修改它们以反映移动。

Dada在其类型中跟踪移动

好的，让我们重温那个在Rust中会出错的示例。当我们将它转换为Dada时，我们发现它类型检查完全正常：

class Character(...) // 如前所述
let ch: given Character = Character(...)
let name: ref[ch.name] String = ch.name
//            -- 最初是从`ch`借用的
let ch1 = ch.give
//        ------- 但`ch`被移动到了`ch1`
let name1: ref[ch1.name] = name
//             --- 现在是从`ch1`借用

哇，很巧妙！我们可以看到，当我们从ch移动到ch1时，编译器会更新周围变量的类型。所以实际上name的类型变为了ref[ch1.name] String。然后当我们从name移动到name1时，这是完全有效的。

在编程语言领域，将一个变量的类型从一种更新为另一种称为“强更新”。显然，当涉及控制流时，事情会变得有点复杂，例如在这种情况下：

let ch = Character(...)
let ch1 = Character(...)
let name = ch.name
if some_condition_is_true() {
    // 在此路径上，`name`的类型变为了
    // `ref[ch1.name] String`，因此`ch`
    // 不再被视为被借用。
    ch1 = ch.give
    ch = Character(...) // 未被借用，我们可以修改
} else {
    // 在此路径上，`name`的类型
    // 保持不变，`ch`被借用。
}
// 在这里，类型被合并，所以
// `name`的类型是`ref[ch.name, ch1.name] String`。
// 因此，`ch`在这里被视为被借用。

重命名允许我们使用借用的值调用函数

好的，让我们迈出下一步。让我们定义一个Dada函数，它接受一个拥有的值和另一个从该值借用的值，比如名字，然后调用它：

fn character_and_name(
    ch1: given Character,
    name1: ref[ch1] String,
) {
    // ... 执行一些操作 ...
}

我们可以像这样调用这个函数，正如你可能预期的那样：

let ch = Character(...)
let name = ch.name
character_and_name(ch.give, name)

那么……这是如何工作的呢？在内部，类型检查器通过创建一个更简单的代码片段来检查函数调用的类型，本质上是这样，然后检查该片段的类型。这就像脱糖，但只在类型检查时。在这个更简单的片段中，有一系列let语句为每个参数创建临时变量。这些临时变量总是有一个从方法签名中取得的显式类型，并用每个参数的值初始化：

// 类型检查器将`character_and_name(ch.give, name)`“脱糖”为
// 更基本的操作：
let tmp1: given Character = ch.give
    //    ---------------   -------
    //            |         来自调用
    //    来自函数签名
let tmp2: ref[tmp1.name] String = name
    //    ---------------------   ----
    //            |         来自调用
    //    来自函数签名，
    //    但重写以使用新的
    //    临时变量

如果这通过了类型检查，那么类型检查器就知道你提供了所需类型的值，因此这是一个有效的调用。当然还有更多步骤，但这是基本思想。

注意，如果你提供了从错误位置借用的数据会发生什么：

let ch = Character(...)
let ch1 = Character(...)
character_and_name(ch, ch1.name)
//                     --- 错误的位置！

这将无法通过类型检查，因为你得到：

let tmp1: given Character = ch.give
let tmp2: ref[tmp1.name] String = ch1.name
    //                            --------
    //       类型是`ref[ch1.name] String`，
    //       不是`ref[tmp1.name] String`

类构造函数只是特殊的函数

所以现在，如果我们回到最初的示例，我们可以看到Message示例是如何工作的：

class Message(
    list: String
    items: Vec[ref[self.list] String]
)

基本上，当你构造Message(list, items)时，从类型系统的角度来看，这“只是另一个函数调用”，只是签名中的self被小心处理了。

这是建模，而非实现

我应该明确指出，这个系统是在dada-model仓库中建模的，该仓库实现了一种“迷你Dada”，它包含了我认为最有趣的部分。我正在努力进一步完善这个模型，但它已经包含了我在这里展示的大部分内容。⁵例如，这是一个测试，当你给错误的值提供引用时，你会得到错误。

“真正的实现”落后很多，还没有真正处理有趣的部分。将其从模型扩展到真正的实现涉及解决类型推断和其他一些棘手的挑战，我还没有达到那一步——尽管我在编译器架构方面也有一些相当有趣的实验正在进行。⁶

这可以应用于Rust

我相信我们可以将这个系统的大部分应用于Rust。显然，我们需要重新设计借用检查器以基于位置，但这是直接的部分。更难的部分是&T在Rust中是指针，这一点我们不容易改变。然而，对于自引用的许多用例，这并不像听起来那么重要。通常，你希望引用的数据位于堆中，因此当原始值移动时，指针实际上不会失效。

考虑我们开头的例子。你可能想象Rust允许这样的东西：

struct Message {
    list: String,
    items: Vec<&{self.list} str>,
}

在这种情况下，str数据是堆分配的，因此移动字符串实际上不会使&str值失效（有趣的是，它会使&String值失效）。

在今天的Rust中，编译器不知道所有正在发生的事情的细节。String有一个Deref实现，因此str是否堆分配是相当不透明的。但我们在超越&目标中正在研究这个系统的各种变化，最值得注意的是字段投影工作。很可能在这个背景下有机会解决这个问题，但说实话，我还没能及时跟上细节。

由 mimo-v2.5 模型翻译，花费 21075 tokens

示例：MessageProcessor

让我们从一个简单的例子开始。假设我们有一个结构体 MessageProcessor，它用一组消息创建。它将处理这些消息，并在此过程中收集一些简单的统计数据：

pub struct MessageProcessor {
    messages: Vec<String>,
    statistics: Statistics,
}

#[non_exhaustive] // 与示例无关，只是良好实践！
pub struct Statistics {
    pub message_count: usize,
    pub total_bytes: usize,
}

消息处理器的基本工作流程是：

• 通过 push 将消息累积到 self.messages 向量中
• 清空累积的消息并进行处理
• 重用后备缓冲区以推送未来的消息

累积消息

累积消息很简单：

impl MessageProcessor {
    pub fn push_message(&mut self, message: String) {
        self.messages.push(message);
    }
}

处理单个消息

处理单个消息的函数获取消息字符串的所有权，因为它将被发送到另一个线程。在此之前，它会更新统计数据：

impl MessageProcessor {
    fn process_message(&mut self, message: String) {
        self.statistics.message_count += 1;
        self.statistics.total_bytes += message.len();
        // ... 加上将消息发送到某处的操作
    }
}

清空累积的消息

你需要的最后一个函数是清空累积的消息并处理它们。编写这个函数应该是直接了当的，但它并非如此：

impl MessageProcessor {
    pub fn process_pushed_messages(&mut self) {
        for message in self.messages.drain(..) {
            self.process_message(message); // <-- 错误：`self` 已被借用
        }
    }
}

问题在于 self.messages.drain(..) 对 self.messages 进行了可变借用。当你调用 self.process_message 时，编译器假设你可能会修改任何字段，包括 self.messages。因此，它报告了一个错误。这是合理的，但令人沮丧。

有经验的 Rust 程序员知道一些解决方法。例如，你可以将 messages 字段与一个空向量交换。或者你可以调用 self.messages.pop()。或者你可以将 process_message 重写为 Statistics 类型上的方法。但老实说，所有这些都不够理想。上面的代码确实相当合理，如果你能以直接的方式使其工作，而不需要重构它，那就太好了。

需要什么：一种让借用检查器知道方法可能访问哪些字段的方法

核心问题是借用检查器不知道 process_message 将仅访问 statistics 字段。在这篇文章中，我将专注于一种显式且相当有限的表示法，但我也将讨论我们将来如何扩展它。

视图类型用字段列表扩展结构体类型

视图类型的基本思想是扩展结构体类型的语法，以可选地包含一个可访问字段列表：

RustType := StructName<...>
         |  StructName<...> { .. }         // <-- 我们正在添加的
         |  StructName<...> { (fields),* } // <-- 我们正在添加的

像 MessageProcessor { statistics } 这样的类型意味着“一个只能访问 statistics 字段的 MessageProcessor 结构体”。你也可以包含一个 ..，比如 MessageProcessor { .. }，这意味着所有字段都可以访问，这等同于今天的结构体类型 MessageProcessor。

视图类型尊重隐私

视图类型将尊重隐私，这意味着你只能在可以命名字段 messages 的上下文中编写 MessageProcessor { messages }。

视图类型可以在 self 参数和其他地方命名

你可以用这个来定义 process_message 只需要访问字段 statistics：

impl MessageProcessor {
    fn process_message(&mut self {statistics}, message: String) {
        //             ----------------------
        //             `self: &mut MessageProcessor {statistics}` 的简写
        
        // ... 如前所述 ...
    }
}

当然，你也可以在其他参数中使用这种表示法：

fn silly_example(.., mp: &mut MessageProcessor {statistics}, ..) {
}

显式的视图限制借用

我们还将扩展借用表达式，以便可以精确指定哪些字段可以从借用中访问：

let messages = &mut some_variable {messages}; // 模糊的语法？见下文。

当你这样做时，借用检查器会生成一个类型为 &mut MessageProcessor {messages} 的值。

敏锐的读者会注意到这是有歧义的。上面的代码在今天可以被解析为对一个结构体表达式的借用，比如 some_variable { messages }，或者更冗长地，some_variable { messages: messages }。我不确定该如何处理。我会在下面提到一些替代的语法，但我也注意到，编译器可能会以模糊的方式解析 AST，然后在名称解析结果已知时进行消歧。

我们在自动引用中自动引入视图借用

然而，在我们的示例中，用户从不显式编写 &mut 借用。它是由编译器在方法调用中作为自动引用添加的结果产生的：

pub fn process_pushed_messages(&mut self) {
    for message in self.messages.drain(..) {
        self.process_message(message); // <-- 自动引用发生在这里
    }
}

编译器会根据 process_message 中声明的签名，将像 self.process_message(message) 这样的方法调用重写为完全限定形式。今天，这会产生如下代码：

MessageProcessor::process_message(&mut *self, message)

但是因为 process_message 现在会声明 &mut self { statistics }，所以我们可以改用指定字段集的借用进行脱糖：

MessageProcessor::process_message(&mut *self { statistics }, message)

借用检查器会尊重视图

将视图集成到借用检查器中是相当简单的。借用检查器的工作方式是，当它看到一个借用表达式时，它会在内部记录一个“贷款”，跟踪被借用的位置、借用的方式（可变、共享）以及借用的生命周期。我们所要做的就是为每个使用视图的借用记录多个贷款，而不是一个贷款。

例如，如果我们有 &mut self，我们将记录一个 self 的 mut 贷款。但如果我们有 &mut self {field1, field2}，我们将有两个 mut 贷款，一个是 self.field1，另一个是 self.field2。

示例：将所有内容放在一起

好的，让我们将所有内容放在一起。这是我们最初的原始示例，收集在一起：

pub struct MessageProcessor {
    messages: Vec<String>,
    statistics: Statistics,
}

#[non_exhaustive]
pub struct Statistics {
    pub message_count: usize,
    pub total_bytes: usize,
}

impl MessageProcessor {
    pub fn push_message(&mut self, message: String) {
        self.messages.push(message);
    }

    pub fn process_pushed_messages(&mut self) {
        for message in self.messages.drain(..) {
            self.process_message(message); // <-- 错误：`self` 已被借用
        }
    }

    fn process_message(&mut self, message: String) {
        self.statistics.message_count += 1;
        self.statistics.total_bytes += message.len();
        // ... 加上将消息发送到某处的操作
    }
}

今天，process_pushed_messages 会导致错误：

pub fn process_pushed_messages(&mut self) {
    for message in self.messages.drain(..) {
        //         ------------- 借用 `self.messages`
        self.process_message(message); // <-- 错误！
        //   --------------- 借用 `self`
    }
}

错误源于两个借用之间的冲突：

• self.messages.drain(..) 脱糖为 Iterator::drain(&mut self.messages, ..)，如你所见，它mut-借用 self.messages；
• 然后 self.process_message(..) 脱糖为 MessageProcessor::process_message(&mut self, ..)，如你所见，它mut-借用了整个 self，这与 self.messages 重叠。

但在“崭新的世界”里，我们将在一个地方修改程序：

-    fn process_message(&mut self, message: String) {
+    fn process_message(&mut self {statistics}, message: String) {

结果是，process_pushed_messages 函数现在将通过借用检查。这是因为两个贷款现在针对不同的位置：

• 如前所述，self.messages.drain(..) 脱糖为 Iterator::drain(&mut self.messages, ..)，它mut-借用 self.messages；
• 但现在，self.process_message(..) 脱糖为 MessageProcessor::process_message(&mut self {statistics}, ..)，它mut-借用 self.statistics，这不与 self.messages 重叠。

在运行时，这仍然只是一个指针

我想强调的一点是，“视图类型”是一种纯粹的静态构造，不会改变代码的编译方式。它们只是给借用检查器提供更多关于哪些数据将通过哪些引用访问的信息。例如，process_message 方法仍然只接受一个指向 self 的指针。

这与今天存在的解决方法形成对比。例如，如果我编写上面的代码，我可能会将 process_message 重写为一个接受 &mut Statistics 的关联函数：

impl MessageProcessor {
    fn process_message(statistics: &mut Statistics, message: String) {
        statistics.message_count += 1;
        statistics.total_bytes += message.len();
        // ... 加上将消息发送到某处的操作
    }
}

当然，这很烦人，因为我必须编写 Self::process_message(&mut self.statistics, ..) 而不是 self.process_message()，但它可以避免借用检查错误。

除了烦人之外，它还会改变代码的编译方式。它现在接受一个对 Statistics 的引用，而不是对 MessageProcessor 的引用。

在这个例子中，从一种类型改为另一种是无害的，但还有其他需要访问多个字段的例子，在这些情况下，单独传递它们效率较低。

常见问题解答

实现起来有多难？

老实说，不是很困难。我认为如果我们找到一个好的贡献者愿意承担这项工作，我们今年就可以发布它。

隐私问题如何处理？

我将要求视图类型中出现的字段对命名它们的代码是“可见的”（这包括通过自动引用插入的视图类型）。因此，以下内容将是一个错误：

mod m {
    #[derive(Default)]
    pub struct MessageProcessor {
        messages: Vec<String>,
        ...
    }
    
    impl MessageProcessor {
        pub fn process_message(&mut self {messages}, message: String) {
            //                           ----------
            //   在这里引用私有字段是*合法*的，但它会产生一个提示，
            //   就像现在公共方法接受私有类型的参数是*合法*（但会被提示）一样。
            //   提示的原因是，这样做实际上会使该方法无法从该模块外部调用。
            self.messages.push(message);
        }
    }
}

fn main() {
    let mut mp = m::MessageProcessor::default();    
    mp.process_message(format!("Hello, world!"));
    // --------------- 错误：字段 `messages` 在此处不可访问
    //
    // 这脱糖为：
    // 
    // ```
    // MessageProcessor::process_message(
    //     &mut mp {messages},        // <-- 命名了一个私有字段！
    //     format!("Hello, world!"),
    // )
    // ```
    // 
    // 这命名了私有字段 `messages`。这是一个错误。
}

这意味着视图类型不能用于公共方法吗？

或多或少是这样。你可以使用它们，如果视图类型引用的是公共字段：

#[non_exhaustive]
pub Statistics {
    pub message_count: usize,
    pub average_bytes: usize,
    // ... 也许以后会添加更多字段 ...
}

impl Statistics {
    pub fn total_bytes(&self {message_count, average_bytes}) -> usize {
        //                    ----------------------------
        //             声明我们只读取这两个字段。
        self.message_count * self.average_bytes
    }
}

视图类型几乎只适用于私有方法，这不会很受限吗？

是的！但这是一个良好的起点。根据我的经验，这个问题最常出现在像我在这里展示的私有辅助方法中。它可能发生在公共上下文中，但频率要低得多，在那些情况下，重构类型以更好地向用户暴露分组通常更容易接受。这并不意味着我不想修复公共情况，只是意味着它是一个很好的用例，可以被排除在最小可行产品之外。将来，我将通过抽象字段来解决公共字段，正如我过去所描述的那样。

如果我一遍又一遍地借用同一组字段怎么办？这听起来很重复！

确实如此！我将来希望看到某种“幽灵”或“抽象”字段，就像我在抽象字段博客文章中描述的那样。但再次强调，这对我来说是“最小可行产品之后”的问题。

我们必须显式指定被借用的字段集吗？它们不能被推断吗？

在我描述的语法中，你必须显式编写 &mut place {field1, field2}。但文献中有许多方法可以推断这种东西，其中行多态可能是最直接适用的。我认为我们绝对可以引入这种推断，事实上，我*可能会*让它成为默认值，这样 &mut place *总是*引入一个视图类型，但在实践中通常被推断为“所有字段”。但这是对 Rust 推理系统的一个非平凡扩展，引入了一种我们今天不做的新推断。对于最小可行产品，我想我会依赖自动引用来涵盖绝大多数常见情况，而对其他情况使用显式语法。

天哪，我必须在签名中写出我方法使用的字段？这太糟了！它应该是自动的！

我理解对于许多应用，特别是*私有*方法，写出将要访问的字段列表似乎有点愚蠢：编译器应该能够弄清楚。

另一方面，这是我们在 Rust 中尽量避免的过程间推断，原因有很多：

• 它引入了方法之间的依赖关系，使推断变得更加困难（在极端情况下甚至不可行）；
• 它导致“非本地错误”，用户会感到非常困惑，修改一个方法的主体会导致另一个方法出错（想想我们在 futures 和 Send 周围遇到的混乱）；
• 它使编译器更加复杂，我们将无法轻松地并行化（虽然我们今天没有并行化，但这项工作正在进行中！）

对我来说，底线是阶段性：无论我们做什么，我认为我们都希望有一种方法来显式地确切知道哪些字段在哪里被访问。因此，我们应该首先添加这个。我们可以稍后再添加推断。

为什么需要将其添加到借用检查器？为什么不脱糖？

另一个常见的替代方案（也是我考虑了一段时间的……）是添加某种“脱糖”，传递字段的引用而不是单个引用。我不喜欢这个有两个原因。第一，我认为它实际上更复杂！这是对借用检查器的一个相当直接的更改，但那种脱糖会使代码遍布整个编译器，并且会使诊断等变得复杂得多。

但第二，它需要改变运行时发生的事情，我不明白为什么在这个例子中需要这样做。传递单个引用对我来说感觉是正确的。

关于模糊的语法怎么办？还有其他语法选项吗？

哦，对了，模糊的语法。老实说，我还没有深入思考语法。我试图让类型 Struct { field1, field 2 } 反映结构体构造语法，因为我们通常试图让类型反映表达式，但这当然会导致借用表达式中的歧义，从而引起问题：

let foo = &mut some_variable { field1 };
            // ------------- 这是一个变量还是一个字段名？

我看到的选项：

• 让它工作。 它并非真正有歧义，但确实需要一些语义消歧，也就是说，在至少某些情况下，我们必须延迟解决这个问题，直到名称解析完成。这对 Rust 来说是不寻常的。我们在一些小的领域这样做，最著名的是对像 None 这样的模式的解释（它是绑定到变量 None 还是枚举变体？）。
• 仅为借用引入新语法。 我们可以保留类型语法，但使借用语法不同，也许是 &mut {field1} in some_variable 或其他形式。考虑到你很少会输入显式的借用形式，这看起来不错？
• 完全使用新语法。 也许我们想尝试不同的东西，或者到处引入一个关键字？我很乐意在那里听取意见。当前的一个对我来说感觉不错，但它占据了“拥挤的语法空间”，所以我可以看出读者可能无法确定如何解释它，这可能会令人困惑。

结论：这是一个很好的最小可行产品，让我们发布它吧！

简而言之，我真的没有看到任何阻碍我们前进的东西，至少通过语言实验。

由 mimo-v2.5 模型翻译，花费 29562 tokens

使用 . 的语法

有人通过邮件建议我可以使用 . 来消除语法歧义：

let place = &mut self.{statistics};

可以设想，我们也可以将此语法用于类型，例如：

fn method(
    mp: &mut MessageProcessor.{statistics},
    ...
)

以及在 self 位置：

fn foo(&mut self.{statistics}) {}

我需要花时间考虑一下，但……我有点喜欢它？

我会在下一个示例中使用它来试试看效果。

调用引用私有类型的公共方法时的强制转换

在我的文章中，我提到如果你有一个公共方法，其 self 类型引用了私有字段，你将无法从另一个作用域调用它：

mod module {
    #[derive(Default)]
    pub struct MessageProcessor {
        messages: Vec<String>,
        statistics: Statistics,
    }
    
    pub struct Statistics { .. }

    impl MessageProcessor {
        pub fn push_message(
            &mut self.{messages},
            //         -------- 私有字段
            message: String,
        ) {}
    }
}

pub fn main() {
    let mp = MessageProcessor::default();
    mp.push_message(format!("Hi"));
    // ------------ 错误！
}