Carbon 语言「Are We Explorer Yet?」提案解读：用 AreWeYet 方法论追踪 Explorer 解释器的实现进度

Carbon 语言在早期同时维护着两套实现：面向语言设计验证的 Explorer 解释器，以及面向生产编译的 Toolchain 编译器。本文基于仓库提案 proposals/p001891-are-we-explorer-yet.md，解析 Carbon 社区如何借鉴 Mozilla 的 AreWeYet 方法论，为 Explorer 建立一个「Are We Explorer Yet?」进度仪表盘：以结构化清单呈现已完成与未完成的语言特性、界定跟踪范围、并推动为遗留工作创建 Issue。读完本文，你将理解这一提案的完整背景、方法论来源、核心功能清单与后续在仓库中的实际演进结果。

一、问题：Explorer 的进度为何难以看清

Carbon 项目公开了大量设计文档，但要快速获得一张「哪些工作已经完成、哪些工作仍待完成」的高层视图却并不容易。提案的 Problem 一节明确指出，这种模糊性会造成两方面困难：

• 难以追踪整体进展：Explorer 作为 Carbon 语言设计的可执行语义模型，其特性覆盖情况分散在代码与测试中，缺少汇总视图；
• 难以识别高影响贡献方向：贡献者无法判断哪些领域的补足对整体目标贡献最大，长此以往会导致「团队层面的微优化」——资源被投入到与高层目标不一致的地方。

值得注意的是，Explorer 在 Carbon 项目中的定位并非普通解释器。后续提案 proposals/p003532-focus-implementation-effort-on-the-toolchain.md 中对此有更完整的描述：Explorer 最初服务于两大目的——一是作为语言设计的「抽象机器」可执行语义模型，二是基于生成式解析器与极简传统架构（AST 等）的快速原型平台。前者至今仍被视为极具价值，这也正是「Are We Explorer Yet?」清单中各项特性存在意义的前提。

二、AreWeYet 方法论：从 Mozilla 到 Rust 的成熟实践

提案的背景部分详细介绍了 AreWeYet 这一方法的出处：

• 来源：Mozilla（众多开源项目背后的非营利组织）创建并实践了被称为 AreWeYet 的「迷因式」方法；
• 做法：构建一个高度结构化的仪表盘，简明扼要地陈述一个目标、其当前状态，并链接到 Issue 或其他可跟踪子目标的方式；
• 典型样例：Mozilla 的「Are We XBL Still?」项目，跟踪从 Firefox 中移除全部 XBL 绑定的工作。其通用格式是提出一个问句「Are we X still?」，随后列出若干子项，当这些子项全部完成时，问题的答案就变为「是」；
• 扩散效应：该方法论的成功促使 Rust 等其他项目也加以采用。

这套方法的核心价值在于：把「宏大目标」拆解为「可勾选的子项清单」，让任何人都能一眼看出整体进度与缺口所在。

三、起点：2022-06-29 Carbon Explorer 状态头脑风暴

提案指出，数据基础已经存在：在 2022 年 6 月 29 日 的 Carbon 每周同步会议中，社区专门拿出部分时间对 Explorer 工具进行了一次头脑风暴，梳理出「已经完成的工作」与「仍然剩余的工作」。但这次头脑风暴的产出只是一个时间截面，当时并未明确约定：

• 这份文档该如何被利用；
• 后续如何持续更新维护。

本提案正是这一工作的「逻辑下一步」：把头脑风暴的成果固化为可持续维护的仪表盘页面。

四、提案核心：创建「Are We Explorer Yet?」页面

提案的总体主张是：为 Explorer 项目创建并使用一个 AreWeYet 仪表盘。理由有二：

1. 该方法论已在 Mozilla、Rust 等项目中被验证成功；
2. Carbon 已经通过头脑风暴收集到了 Explorer 的现状数据，成本已被分摊。

具体的落地步骤（Details 一节）包括三件事：

1. 创建新页面：在 carbon-lang Wiki 上新建一个名为 “Are We Explorer Yet?” 的页面；
2. 填充内容：将 Explorer 状态头脑风暴的结果写入该页面；
3. 创建 Issue：为清单中「未完成」的部分在仓库中创建 Issue，使缺口可被跟踪、认领与关闭。

范围界定：哪些内容不纳入本清单

提案明确将以下主题排除在本次 AreWeYet 范围之外：

• C++ 互操作（C++ interop）：很可能永远不会成为 Explorer 的目标；
• 元编程（Metaprogramming）；
• 并行编程（Parallel programming）；
• 协程（Coroutines）。

其中后三项体量足够大，提案认为它们值得各自拥有独立的 AreWeYet 页面，因此不在本次清单中展开。

五、核心清单：Explorer 特性实现状态全表

提案正文完整给出了「Are We Explorer Yet?」页面的基础内容，按主题分类，使用 ✅（已完成）与 ❌（未完成）标注每一项的状态。以下完整呈现（未做任何删减）：

结构化编程（Structured programming）— ❌

子项	状态
While 循环（While loops）	✅
变量声明（Variable declarations）	✅
变量初始化跟踪（Variable initialization tracking）	❌
返回变量（Returned var）	❌
可变参数（Variadics）	❌

用户自定义类型（User defined types）— ❌

子项	状态
结构体（structs）	✅
类（classes）	✅
choice（choice）	❌

别名系统（Alias system）— ✅

面向对象编程（OO programming）— ❌

子项	状态
继承（Inheritance）	❌
带继承的参数化类方法（Parameterized class methods w/ inheritance）	❌
析构函数（Destructors）	❌
方法（Methods）	✅
静态函数 / 类函数（Static functions / Class functions）	✅

泛型编程（Generic programming）— ❌

子项	状态
泛型类（Generic classes）	✅
泛型方法（Generic methods）	❌
泛型函数（Generic functions）	✅
接口（Interfaces）	✅
泛型接口（Generic Interfaces）	✅
实现（Impls）	✅
泛型实现（Generic Impls）	✅
实现特化（Impl specialization）	❌
模板（Templates）	❌

运算符重载（Operator overloading）— ❌

子项	状态
==	✅
/=	❌
其他运算符（Other operators）	❌
约束（Constraints）	❌
隐式 as（Implicit "as"）	✅

错误处理（Error handling）— ❌

预置库（Prelude）— ✅

子项	状态
打印函数（Print function）	✅

类型（Types）— ❌

子项	状态
i32	✅
其他整型类型（Other integral types）	❌
整型类型作为库类型而非原生类型（Integral types as library types instead of native）	❌
元组（Tuples）	✅
指针（Pointer）	✅
函数（Functions）	✅
布尔（Bool）	✅
字符串（String）	✅
浮点类型（Floating point types）	❌
原始字符串字面量（Raw string literals）	❌

代码组织（Code organization）— ❌

子项	状态
混入（Mixins）	❌
导入（Imports）	❌
独立包（Separate packages）	❌
模块（Modules）	❌
命名空间（Namespaces）	❌

从整体看，这份清单透露出当时 Explorer 的能力分布：基础执行模型（while、变量、结构体/类、方法、i32、元组、指针、字符串、接口与泛型函数/类、Prelude 打印）已经就绪，而 继承、析构、模板、完整运算符重载、错误处理、代码组织与模块化等「大型特性」仍处于缺口状态——这些也正是后来 Toolchain 与设计文档持续攻坚的方向。

六、替代方案：为何不选这两种路径

提案在 Alternatives considered 一节权衡了两种替代路径：

1. 维持现状（status quo）：即继续不进行任何高层进度跟踪。鉴于 Problem 一节列出的种种弊端（难以追踪、贡献方向不清晰、易陷入微优化），该选项并不可取；
2. 使用 GitHub Issue 标签 + 自定义搜索：为未完成的子项打上标签，再通过自定义搜索聚合出未解决问题。其优点是完全自动化、无需人工维护页面；缺点则是难以获得层级化视图——而层级化（大主题 → 子项）恰恰是把握全局的关键，也是 AreWeYet 方法论的核心优势所在。

七、从仓库现状回看：提案的落地与后续演进

本提案（对应 PR #1891）已收录在仓库的 proposals/README.md 中，而该目录「只包含已接受的提案」，说明提案本身已被采纳。沿着仓库的后续提案与现状，我们可以还原这一清单在真实项目演进中的走向：

1. 实施重心转向 Toolchain（p003532）

提案 proposals/p003532-focus-implementation-effort-on-the-toolchain.md 决定在接下来 1～2 年把全部实施精力聚焦到 Toolchain 上：保留 Explorer 代码及其基本回归测试（因其构建产物对语言设计特性集覆盖仍有价值），但不再优先扩展其特性覆盖、停止积极模糊测试。这一决策事实上为「Are We Explorer Yet?」清单上剩余 ❌ 项的补足按下了暂停键。

2. Explorer 被移出主仓库并归档（p005270）

更晚的提案 proposals/p005270-move-explorer-out-of-toolchain-git-repository.md 给出了终局：Explorer 代码库不再积极开发，其价值主要在于作为「语言设计各部分的实现参照」。为避免它与活跃的 Toolchain 代码混淆（例如 Main() 与 Run() 入口的差异、clang-tidy 等工具无法区分冻结代码与活跃代码、升级 Bazel/Clang 时需连带维护 Explorer 等成本），该提案主张：

• 在主仓库打上 explorer-archived 标签；
• 在 carbon-language 组织下新建仅含 //explorer 与 //installers 及其依赖的独立 explorer 仓库；
• 停止 compiler-explorer.com 上的 "Explorer (trunk)" 编译选项；
• 删除主仓库中的 //explorer 与 //installers 目录并归档新仓库（只读）。

值得注意的是，Explorer 的模糊测试用例已被迁移至 //toolchain/*/fuzzer_corpus/，即当前仓库中 toolchain/check/fuzzer_corpus、toolchain/lex/fuzzer_corpus、toolchain/parse/fuzzer_corpus 等目录下的无扩展名语料文件——这可以视为 Explorer 资产在 Toolchain 中的延续。

3. 仓库现状印证

从当前仓库根目录的 README.md 可以看到最终状态：项目正集中精力于 toolchain/ 目录下的编译器与工具链实现（含 driver、lex、parse、check、sem_ir、lower 等完整编译流水线），而历史上曾存在的原型 Explorer 解释器「不再开发，并已被归档」。这意味着「Are We Explorer Yet?」清单中的大部分 ❌ 项，其后续实现诉求实质上转移到了 Toolchain 的实现路径上——清单本身作为一份历史快照，精确记录了 Carbon 语言设计验证早期阶段的能力边界。

八、总结：一份清单如何重塑项目叙事

「Are We Explorer Yet?」提案的核心贡献不在于代码，而在于把碎片化的实现状态结构化为可跟踪、可引用、可更新的高层视图。它的价值体现在三层：

1. 对贡献者：用 ✅/❌ 一目了然地标注高影响缺口，降低「从哪入手」的决策成本；
2. 对项目管理者：避免团队层面的微优化，使资源投入与高层目标对齐；
3. 对语言设计者：清单本身就是一份「设计特性 × 实现验证」的对应关系表，与后续 Toolchain 的特性覆盖形成可对照的演进轨迹。

当你在阅读 Carbon 的后续提案（如泛型细节系列、继承与类设计）时，回看这份清单，便能清晰感受到「设计先行、实现跟进」的节奏——而这一切，都始于 2022 年 6 月那次头脑风暴与一个简短的问句：Are We Explorer Yet?