Carbon 语言 0.1 里程碑定义面向 C 社区评估的 MVP 语言与互操作路线图【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang本篇文章完整解析 Carbon Language 的里程碑提案提案编号 p002759该提案为 Carbon 语言定义了0.1 / 0.2 / 1.0三个版本化里程碑并为核心里程碑 0.1 给出了一份近乎完整的特性清单目标是让 C 开发者能够据此对 Carbon 作为 C 继任语言的适配性进行真实、深入的评估。读完本文你将掌握 0.1 语言的评估目标、语言特性边界、标准库范围、项目级交付物工具链与安全策略以及 0.2、1.0 里程碑显式推迟了哪些特性及其背后的取舍逻辑并能在当前仓库中找到对应的文档与实现证据。为什么需要一份明确的 0.1 语言定义Carbon 项目早期的具体目标集中在建立项目本身上——治理、演进流程、社区、基础设施以及语言设计与实现层面的探索性工作。到本提案提出时项目已经在公开环境中健康运转设计与实现都有了足够的探索性进展此时需要挑选一个更具体的目标来有效排定后续工作的优先级。正如项目的 2023 路线图 所述顺理成章的下一步是让 Carbon 接受潜在用户的详细、深入评估检验它是否能满足用户对 C 继任语言的需求。虽然价值主张的某些方面可以抽象地讨论但它能否与我的代码协作协作效果如何这类硬问题必须通过直接评估来获得信心。因此项目需要优先确定一组足以支撑评估的特性与里程碑一旦 0.1 语言完成就可以开始推动深入评估。提案概览三个版本化里程碑提案的核心动作是为 Carbon 项目建立一套带版本号的初始里程碑每个里程碑明确主题、具体目标与预期完成的特性清单。三者概要如下里程碑主题定位0.1评估用 MVPMinimum Viable Product供 C 社区与开发者评估 Carbon 的最小可用语言0.2评估用功能完整版特性足以让初始用户完成评估项目据此结束实验1.0生产可用实验成功的结果面向生产环境需要说明的是提案只建议了这三个初始里程碑但并不排除随项目进展在合适时机增加更多里程碑。其中0.1 是唯一给出具体且接近完整特性清单的里程碑清单可能根据新信息更新0.2 与 1.0 有意保持开放、不完整将在临近时逐步填充——把它们列出来的意图是允许项目显式推迟某些重大特性到后续里程碑而不是在用户特别关心某项重大特性何时落地时将其彻底遗漏。一个重要的设计细节是Carbon 的核心目标是成为一门为持续演进做好准备的语言。因此即使达到 1.0也不意味着任何意义上的最终版本Carbon 仍会持续演进与发展其全面计划属于 明确推迟到 0.2 之后的特性 的一部分。里程碑 0.1面向评估的最小可用产品MVP0.1 是三个里程碑中最具体的——它是让 C 用户和开发者开始认真评估 Carbon 的 MVP。项目希望在保证足以支撑首轮评估的前提下让这个里程碑尽可能精简。0.1 的语言目标被概括为评估 MVP它应当足够完整以便专门评估 Carbon 作为 C 继任语言的适配性0.1 的特性相应地聚焦于C 互操作和语言基础性组件的一个最小子集。0.1 的评估目标Goals从成果角度看0.1 的目标围绕评估者能够做到什么来定义评估者能清晰了解 Carbon 的长期演进策略以及它如何应对不同的用例与需求。语言设计组件文档化、内聚、无占位符地呈现给评估者组件与语言特性必须包含语言的基础核心且足以把现有 C 代码协程除外翻译成显而易见、毫不意外的 Carbon 代码范围内还包括影响 API 设计或需要早期反馈的特性但仅限设计成本与实现成本都较低的部分示例语言组件词法结构、表达式、语句、条件、循环、用户定义类型及其依赖示例库组件整数类型、浮点类型、字符串、数组、区间、指针、可选值optionals、变体variants、堆分配及其依赖上述组件所依赖的其它语言或库设计传递性地进入范围。Carbon 使用 C与C 使用 Carbon两方向的互操作设计除协程外覆盖所有主要 C 语言特性均文档化、内聚、无占位符。评估者能构建并运行绝大多数 C 互操作的测试包括可用最新 Clang 版本编译的真实 C 代码与 Carbon 测试代码设计缺口不得削弱评估信心。评估者能有效对 Carbon 做构建速度与规模的压力测试。评估者能构建一些关键路径上包含 C 互操作的基准测试并获得有代表性的性能结果这可以是 C 互操作全部维度的更小子集围绕影响有意义基准的部分展开。内存安全方面的策略与设计能让评估者确信safe Carbon 具备强大的内存安全保护并且可以从现有 C 代码库开始增量采用。语言特性Language features0.1 语言特性聚焦于达成上述目标所必需的核心特性其中一部分由目标直接要求另一部分因依赖关系或与直接要求特性的交互而成为必需。清单不追求覆盖全部粒度——许多让整体成立的次要组件不会逐一列出除非某项被显式描述为部分或带例外否则该条目覆盖的一切都应在 0.1 语言中出现。另一重要原则这份清单不承诺任何特定设计。它只要求 Carbon 设计必须有某种东西来应对每个条目——可能是把命名设计加入 Carbon同样可能是明确声明Carbon 不包含该设计、改用其它语言特性应对其用例及 C 代码改写。代码组织与结构化Packages包Libraries库Implementation files实现文件Importing导入Namespaces命名空间类型系统用户定义类型User-defined typesC 互操作将 C 类型导入 Carbon、将 Carbon 类型导出到 C单一继承Single inheritance虚分派virtual dispatchC 互操作Carbon 与 C 之间双向继承C 与 Carbon 两端都可作为类型层级根继承特性abstract、final、virtual的映射运算符重载Operator overloadingC 互操作为导入的 C 类型合成 Carbon 重载将 Carbon 重载导出到 C和类型Sum types带判别联合联合Unions无判别C 互操作与 C union 的双向映射泛型Generics泛型函数与泛型类型Checked generics含定义期检查的变长参数 variadics集成模板integrated templates含模板式结构符合到名义约束既建模成员类似接口也建模任意谓词类似 C20 表达式有效性谓词C 互操作导入 C 模板并在 Carbon 类型上实例化导出 Carbon 模板并在 C 类型上实例化将 Carbon checked generics 作为模板导出并在 C 类型上实例化把 C20 concepts 映射为命名谓词、把命名谓词映射为 C20 concepts函数、语句、表达式等函数Functions声明与定义分离函数重载C 互操作导入 C 函数与方法并从 Carbon 调用导出 Carbon 函数与方法并从 C 调用在模型匹配封闭重载时把 C 重载集导入 Carbon 重载集把 C 开放重载集-作为-扩展点如swap按常见情况可能基于启发式合成为 Carbon 接口控制流语句Control flow statements条件conditions循环loops基于区间的循环对现有多种 C/C 循环结构提供良好等价物匹配matching对 C/C 中switch用法提供良好等价物处理和类型尤其是 Cstd::variant与std::optional互操作同时支持正向类比 Rust 的if let与负向类比 Rust 的let else的匹配控制流 变量声明组合C 互操作支持 C 的线程与原子原语、内存模型与同步工具错误处理Error handling任何专用的错误处理控制流结构C 互操作提供配置异常处理如何/是否集成到 C 互操作的机制足以同时应对-fno-except方言与标准 C 方言从 Carbon 调用会抛异常的 C 函数并自动使用 Carbon 的错误处理把 Carbon 错误处理以合理易用的方式导出到 C——std::expected、与其大致兼容的东西、C 异常等标准库组件Standard library components值得特别强调的是Carbon 初期预期通过互操作重度借用C 标准库来满足绝大多数需求因此这一领域比语言特性出人意料地更小。语言与语法支持库组件基本类型bool、iN、fN元组或数组类型中库所需的部分指针类型支撑语言语法运算符、转换等的接口具有重要语言支持的类型用于字符串字面量的 String 及相关类型Optional可选值Slices切片C 互操作Carbon 基本类型与 C 对应类型之间的透明映射Carbon 与 C非拥有型字符串相关类型之间的透明映射Carbon 与 C非拥有型连续容器类型之间的透明映射包括从一个拥有型容器出发形成非拥有视图再在两种语言间透明映射Carbon 与 C 迭代抽象之间的透明映射项目特性Project features除语言特性外0.1 还需完成若干项目级交付物可正常工作的 Carbon 工具链支持作为 Clang C 工具链的直接替代使用兼容最常见的 Make 与 CMake 派生构建系统实现上文多数语言特性含 C 互操作剩余缺口不得削弱对剩余特性的评估或对整体评估的信心可安装于 Windows、macOS、Linux并为这些平台构建可运行程序。CMake 构建系统集成以及集成 Make 或类似构建系统的文档。详细的 Carbon 安全策略包含对 unsafe C 代码与 unsafe Carbon 代码如何与 safe Carbon 代码交互的具体预期以及不同种类/层级安全之间的权衡取舍与优先级。详细而具体的 safe Carbon 设计至少覆盖大多数现代 C 已是安全的部分类型安全与初始化安全还必须覆盖空间安全、时间安全与修改mutation安全包含对 safe Rust 互操作影响的分析不要求在 0.1 中有完整实现。面向评估者的基础文档从入门指南到 FAQ。里程碑 0.2功能完整、可供评估者完成评估0.2 的完整度度量基于能否可信地应对有迁移意愿的现有 C 用户与开发者的需求因此主要由 C 中已在使用的特性、或离开 C 所必需的特性驱动。最终要求是用户能够借 0.2 完成对 Carbon 的评估语言仍会继续演进但到此时不应再存在对来自 C 的初始目标受众构成问题的特性缺口项目应能以此特性集为实验收官。该里程碑的具体需求范围将在 0.1 完成并收到反馈后定义。显式推迟到至少 0.2 的特性内存安全memory safety协程、async、生成器等处理 effects 的综合方案以及函数如何跨 effects 泛化Carbon 原生线程元编程特性的长尾部分MixinsProperties内联汇编SIMD某种跨语言版本、构建配置及其它 FFI/ABI 边界定义并共享数据的 API 能力标准库的必要组成部分为什么协程和 async 要放在这个里程碑为什么不在 0.1 中更早处理如果可以推迟又为什么不推得更远协程与异步编程是引入语言时庞大而复杂的主题。从 C、Rust、Swift、Kotlin 等语言在该领域的实践来看项目强烈相信把协程加入 0.1 语言会显著增加工作量并很可能推迟 0.1 的达成时间。同时鉴于协程是 C 中较新的特性评估者完全可以在理性看待其缺席的前提下完成对 Carbon 的大部分评估。然而随着协程在 C 中被广泛采用它预计会成为语言中极难在迁移到 Carbon 时放弃的必备特性。因此协程被视作决定Carbon 实验是否成功、能否开始规划大规模采用与迁移的必要特性。里程碑 1.0不再是实验可用于生产1.0 标志着 Carbon 不再是实验品若成功而成为可用语言目前仅是推测性命名临近时可能变更。在此仅列出预期会在 1.0 出现、但需显式推迟到 0.2 之后的特性稳健的语言演进策略与计划具体针对为应对反馈与变化的环境而对语言进行持续修改的需求长期变更与 churn 对用户的成本以及如何管理该成本为需要真正、长期、持久稳定的用户提供的机制。包管理策略与计划以及所需的早期基础工作。足够高质量的开发者体验以支撑首批生产用户包含编译器错误信息与基础开发者工具。在 0.1 与 0.2 评估过程中学到的一切经验。提案依据Rationale本提案服务于 Carbon 的两项核心目标社区与文化需要让 Carbon 社区及更广泛的 C 社区参与评估 Carbon 实验提案确定了为做到这一点而预计采取的具体步骤。软件与语言演进清晰定义里程碑有助于设定方向、让语言演进更有效——这些里程碑将为 Carbon 提供方向性清晰度并提供衡量演进有效性的标尺。备选方案与取舍Alternatives considered备选一初始只收窄到 0.1 的定义只定义 0.1 会缩小提案范围、去掉一些较含糊的方面但会让读者难以区分某物完全缺失与仅为推迟到后续里程碑。项目还预期这种显式推迟能通过避免没有推迟时可能会关注的特性干扰来帮助团队聚焦精力于下一里程碑。备选二做一个更渐进、野心更小的初始里程碑当前初始里程碑相对雄心勃勃远大于多数编程语言的 MVP更保守的初始里程碑可以更快、更高置信地达成。但更渐进的里程碑对在现有 C 语境下评估 Carbon这一内在目标价值不大——该语境迫使 0.1 必须具备更大的初始特性集否则会落入苹果对橘子式的比较特性集差异过大任何深入的比较与评估都无法成立。备选三跳过 0.1直接追求特性完整减少里程碑数量、瞄准更宏大的目标。已知 0.1 不足以完成多数真实评估可能浪费发布它再迭代到 0.2 的时间。但总体而言更多渐进式里程碑通常有助于保持专注与快速推进项目预计能把初始评估中的相当大一部分时间与 0.2 的完成并行。先发布 0.1能显著降低获得用户对 Carbon 实验是否适合其用途的初步反馈的延迟。仓库中的实现证据与后续路线里程碑定义并非孤立文档当前仓库中已有与其呼应的设计与实现证据里程碑落地文档docs/project/milestones.md 即本提案产出的正式里程碑文档上文全部特性清单均出自该文档其年度执行节奏见 docs/project/roadmap.md。C 互操作的核心性0.1 特性清单把 C 互操作置于中心这与 互操作哲学与目标 一致——互操作与迁移是语言目标之一但性能与演进拥有更高优先级。仓库提供了可直接查看的互操作示例 examples/interop/cpp/hello_world.carbon演示了从 Carbon 以import Cpp library方式导入cstdio、iostream、string_view、unistd.h并调用Cpp.putchar、Cpp.puts、Cpp.write、Cpp.std.cout 的真实代码对应构建目标定义在 examples/interop/cpp/BUILDcarbon_binary(name hello_world, ...)。工具链能力基础0.1 要求工具链作为 Clang C 工具链的直接替代当前 toolchain/driver 中已具备clang_subcommand.cpp、link_subcommand.cpp、lld_subcommand.cpp、build_subcommand.cpp等子命令结构toolchain/codegen/codegen.cpp 承担代码生成均与里程碑中工具链 构建系统集成的项目特性方向一致。时间表预期根据 docs/project/roadmap.md2025 年聚焦大部分非模板 C API 可从 Carbon 访问与内存安全的具体设计两大目标由于把内存安全设计纳入 0.10.1 的发布时间被至少推迟一年——2026 年交付 0.1 是最早可能且极具雄心0.2 的潜在时间窗是 2027–2028 年1.0 则在 2028 年之后届时还将把 Carbon 全部治理移交独立开源组织。综上0.1 里程碑的核心是为评估而最小以 C 互操作与基础语言特性为骨架配以可用的工具链、构建系统集成与安全设计文档让 C 开发者能在真实代码上检验 Carbon 作为继任语言的价值主张而 0.2 与 1.0 则以显式推迟清单的形式为协程、内存安全、包管理、长期演进策略等重大议题划定了明确的落地边界。【免费下载链接】carbon-langCarbon Languages main repository: documents, design, implementation, and related tools. (NOTE: Carbon Language is experimental; see README)项目地址: https://gitcode.com/GitHub_Trending/ca/carbon-lang创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考