Carbon 语言文档体系全景解析从设计文档、项目治理到语言规范【免费下载链接】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 官方仓库的 docs/README.md 文档体系为线索系统梳理 Carbon 项目中design/语言设计、project/项目治理、guides/用户指南、spec/语言规范四大文档目录的定位与相互关系并结合 docs/design/README.md 这份近 4000 行的语言设计总览深入剖析 Carbon 的语法、类型系统、泛型、命名体系与 C/C 互操作设计。读完本文你将掌握 Carbon 文档仓库的导航方法、设计文档与提案proposals的演进关系以及如何通过设计文档快速了解这门旨在替代 C 的实验性语言的核心技术主张。背景说明Carbon 是 Google 主导的实验性编程语言项目目标是成为 C 的继任者。本文所有内容均以当前仓库中的官方文档与源码为事实依据Carbon 仍处于快速演进阶段文中所描述的设计细节以仓库现状为准。一、Carbon 文档仓库的总体架构在 Carbon 主仓库中docs/ 目录存放的是当前已被接受的、支撑 Carbon 项目的基础文档原文表述为 current, accepted documentation underpinning Carbon覆盖从项目整体到具体语言特性的细致设计。docs 目录内部划分为四个彼此独立、面向不同读者的子目录子目录文档定位目标读者docs/design/语言设计文档与设计动机rationale评估者、语言演进者、规范/实现者、Carbon 开发者docs/project/项目治理、目标、原则、路线图与贡献指南项目参与者与社区成员docs/guides/面向最终用户的使用指南to-be-written待编写编写 Carbon 代码的开发者docs/spec/正式语言规范to-be-written待编写编译器与其他工具链的实现者docs/README.md 特别提示如果你只是想了解 Carbon 是什么官方推荐从仓库根目录的 README.md 读起而 proposals/README.md 与 design 文档互补——前者记录的是导致当前设计产生的每一个具体决策含动机与被否定的备选方案后者则是这些决策沉淀后的系统化设计现状。理解这套提案驱动设计、设计沉淀为文档的流程是高效阅读 Carbon 源码与参与演进的前提。二、语言设计文档design/Carbon 的核心技术蓝图docs/design/README.md 是 docs 体系中信息量最大的一份文档自称 up-to-date on 09-Aug-2022它面向四类读者想判断 Carbon 是否适合自己项目的人、参与语言演进的人、实现规范/编译器的人以及想知道语言规则为什么这样设计的 Carbon 开发者。下面按该文档的骨架逐层展开其核心技术内容。2.1 入门示例一个完整的 Carbon 函数文档用一个求最小因子的函数串起 Carbon 的多数基础语法import Core library io; import Math; // Returns the smallest factor of n 1, and // whether n itself is prime. fn SmallestFactor(n: i32) - (i32, bool) { let limit: i32 Math.Sqrt(n) as i32; var i: i32 2; while (i limit) { let remainder: i32 n % i; if (remainder 0) { Core.Print({0} is a factor of {1}, i, n); return (i, false); } if (i 2) { i 3; } else { // Skip even numbers once we get past 2. i 2; } } return (n, true); }这段代码透露了 Carbon 的核心设计取向——对 C/C 开发者保持熟悉感语句以分号或花括号块结尾与 C 系一致见 docs/design/blocks_and_statements.md声明以引入关键字introducer开头fn引入函数、var引入变量、let引入常量这不同于 C 的声明语法import 是模块化导入而非文本包含import Core library io;导入Core包package中名为io的库libraryimport Math;导入Math包的默认库。Carbon 的导入机制更接近 C Modules 而非#include预处理且不同包的命名空间相互隔离天然避免名字冲突注释以//开头延伸至行尾支持整行注释与行尾注释trailing comments两种形态函数定义由fn关键字、函数名、圆括号参数表、可选的-返回类型与花括号函数体组成return可带表达式执行到return或函数体末尾即结束变量声明由var引入名称: 类型的写法与函数参数完全一致可带可选初始化器let常量声明语法与变量平行但初始化器是强制的类型与表达式复用同一套语法Math.Sqrt(n) as i32是先调用再通过as显式做有损转换lossy conversion 必须显式进行作用域规则每个花括号块定义一层作用域名字从声明处一直可见到所在最内层作用域的结束。文档还用同一函数演示了**元组tuple与结构体struct**两种复合类型fn SmallestFactor(n: i32) - {.factor: i32, .prime: bool} { ... return {.factor i, .prime false}; ... }元组以逗号分隔、按位置访问成员适合返回多值结构体成员按名字访问类型中用:值中用语义更清晰。2.2 代码与注释规范Carbon 源码一律为 UTF-8 编码注释、标识符与字符串均允许非 ASCII 字符var résultat: String Succès;注释规范提案 #198 与 #7441强调整行注释用于说明文档行尾注释用于标记/注解具体某一行// Compute an approximation of π. var pi: f64 3.14159; // Accurate enough for our purposes.2.3 构建模式Build modes编译器行为取决于构建模式这一概念在 docs/design/safety/ 中有详细设计debug build开发构建以诊断问题与快速构建为优先release build性能构建以最快执行与最低内存占用为优先。构建模式会直接影响语言语义最典型的是有符号整数溢出开发构建中溢出会在运行时被立即捕获性能构建中优化器假设溢出永不发生一旦发生则行为未定义而 **hardened build加固构建**中溢出不产生未定义行为程序要么中止要么算术结果出错如二进制补码结果或 0。加固模式还会为未成形对象unformed state补充初始化例如将整数置 0见 docs/design/README.md 中 Unformed state 一节。2.4 核心设计主张类型即值Types are valuesCarbon 与 C 最深刻的区别之一是类型本身被建模为值——具体说是类型type的编译期常量值。这一设计源自提案 #2360带来一系列连锁后果类型的名字与函数、变量、命名空间共享同一个命名空间书写类型的语法就是表达式语法因此 Carbon不使用尖括号...表达泛型、留给比较运算例如参数化类型写作HashMap(String, i64)函数调用式语法类型位置如var x: 类型中的冒号后、- 返回类型后出现的值必须满足两条是编译期常量且存在到type的隐式转换。一个精妙的例子(bool, bool)本身不是类型它的类型是(type, type) as type但可隐式转换为类型(bool, bool) as type因此下面的代码合法var b: (bool, bool) (true, false);即b的真实类型是(bool, bool) as type而非(bool, bool)。同理适用于结构体类型与 facet面类型见 docs/design/generics/terminology.md。2.5 原始类型Primitive types原始类型分为四类布尔型bool、有符号/无符号整数、IEEE-754 浮点型、字符串类型。它们通过**前奏prelude**机制对每个文件可见见 docs/design/README.md Name lookup for common types 一节。bool只有true/false两个值bool、true、false均为关键字比较表达式产生boolif/while条件与if-then-else条件表达式都要求bool。整数类型位宽为 8 的倍数的有符号整数写作iN如i32无符号写作uNiN/uN是类型字面量type literals。有符号溢出行为随构建模式变化见 2.3无符号整数溢出则回绕wrap around文档强烈建议仅在确实需要回绕语义位操作、哈希、密码学、PRNG时使用——像 size 这样永远非负但回绕无意义的值应当用有符号类型。部分运算如除法受 LLVM 限制可能只支持到 128 位整数。浮点类型语义遵循 IEEE-754采用最近舍入round-to-nearest且不设置浮点异常状态f16/f32/f64恒可用f80/f128/f256依平台可用另支持BFloat16bfloat16 格式。字符串类型StringUTF-8 字节序列与StringView对 UTF-8 字节序列的只读引用存在String→StringView的隐式转换。注意此设计仍为 provisional尚无提案通过。字面量语法要点整数支持十进制、十六进制、八进制、二进制四种写法可用下划线做数字分隔符且字面量大小写敏感0x/0o/0b必须小写十六进制数字必须大写整数内绝不出现小数点。与 C 不同数字字面量没有类型后缀——其类型由值推导可隐式转换到任何能表示该值的类型。**实数浮点**字面量必须满足.两侧各有一个数字123.456十进制123.456e789e后可带/-0x1.Ap123十六进制指数用p引导同样支持下划线分隔符解释为浮点值时取最接近的可表示实数平局时取尾数为偶数的值提案 #866。字符串支持单行双引号字面量example与块字符串字面量block string literal——以开头结尾、可带文件类型指示符、缩进以终止行缩进为准的多行字符串var block: String The winds grow high; so do your stomachs, lords. ... ;反斜杠\引入转义序列需要表示大量\与时可用原始字符串字面量见 docs/design/lexical_conventions/string_literals.md。2.6 值、对象与表达式分类Carbon 区分抽象值values如42、true、i32与具有存储storage的对象objects。表达式分为三类对应 C 的 value category 概念提案 #2006值表达式value expressions产生抽象、只读的值不可修改、不可取地址引用表达式reference expressions指代有存储的对象可读写、可取地址初始化表达式initializing expressions求值需要隐式提供存储并在其中初始化对象用于建模函数返回值直接在调用方存储中构造的场景。类别之间可相互转换四种基本转换步骤为值获取value acquisition引用→值、直接初始化直接初始化值→初始化、拷贝初始化copy initialization引用→初始化、临时物化temporary materialization初始化→引用。**表达式相位expression phases**进一步把值表达式分成三档提案 #2200、#2964、#3162模板常量template constant编译期已知、类型检查时可用的值字面量、具体类型值、template参数值例如数组大小符号常量symbolic constant到代码生成/单态化monomorphization阶段才确定、类型检查期间未知的值checked 泛型参数等运行时值runtime value仅运行时可知的动态值。模板常量可自动降为符号常量任何值可降为运行时值运行时值若常量求值成功也可升格。这一相位体系是理解 Carbon 泛型2.10 节的基石。2.7 复合类型元组、结构体、指针、数组与缓冲元组tuple固定大小的异构集合按位置标识成员例如fn DoubleBoth(x: i32, y: i32) - (i32, i32)。元组类型本质是类型的元组——(i32, i32)与(2 * x, 2 * y)只是同一语法在不同类型下的两个实例。元素用编译期常量下标访问x[0]。元组类型是结构性的structural。结构体struct结构性数据类structural data class成员以.名称标识类型写作{.name: String, .count: i32}值写作{.key Joe, .count 3}。指针T*表示指向T的指针。Carbon 指针不支持指针算术仅有解引用*pp-m是(*p).m的语法糖与取地址x两种操作没有空指针可空指针用Optional(T*)表达。数组与缓冲array(T, N)是Core.Array(T, N)的简写表示直接存储、不可变大小的数组元组可隐式转换为同长度数组var a: array(i32, 3) (i, i, i);。堆分配的动态大小数组写作buf(T)即Core.Buf(T)。两者都用a[i]下标访问。2.8 表达式、声明、作用域与模式表达式涵盖字面量、名字与成员访问、各类运算符算术、位运算、位移、比较、as转换、and/or/not逻辑、下标、函数调用、指针操作、const T类型操作、~x移动、条件表达式if c then t else f以及括号。类型期望上下文会触发隐式转换见 docs/design/expressions/implicit_conversions.md。声明与定义像函数这样的实体有前向声明forward declaration与定义definition之分每个名字恰好一个定义最多一个额外前向声明。前向声明可用来分离接口与实现API 文件声明、实现文件定义也支持循环引用。已声明未定义的名字称为不完整incomplete。作用域有三类整个文件的外层作用域、花括号包围的作用域、单个声明自身的作用域例如函数参数名只在其声明内有效。**模式patterns**分为可反驳refutable可能匹配失败与不可反驳irrefutable类型检查通过即必然匹配两类绑定模式binding patterns名称: 类型是最常见的不可反驳模式可用于函数参数、var/let声明等任意不可反驳位置_匹配但不绑定名字。绑定有编译期/运行期相位之分通过上下文默认值contextual defaults减少关键字噪音接口/impl/class 的参数、[]推导参数列表默认为 checked 泛型()显式参数与局部绑定默认为运行时。可用template/generic/runtime关键字覆盖默认但与默认值一致的关键字反而被禁止。绑定默认是let绑定绑定到值不可修改var绑定则创建有专用存储的对象。auto可替代类型并依据同一声明中的值推导。解构模式destructuring patterns如元组解构var (p: i64, _: auto) Bar();各分量按模式逐一匹配。可反驳模式在match中使用的表达式模式如42、choice 模式匹配 choice 类型的一个 case与动态类型转换模式配合继承做运行时类型测试。名称绑定声明let声明初始化器必填如let x: i64 42;与var声明可修改如var x: i64 42; x 7;。有非成形状态unformed state的类型允许变量声明时不初始化、使用前赋值。auto推导类型let y: auto x 3;中y推断为i64。目前没有全局变量只有全局常量该语义为 provisional官方在探索替代全局变量的更不易出错的模式。2.9 函数与控制流函数是行为的基本单元。前向声明fn Add(a: i64, b: i64) - i64;定义则把分号换成函数体块返回空值的函数省略-与返回类型。参数默认是let绑定输入参数加var关键字则拷贝/移动至新存储、可在函数体内修改且不影响调用方输入/输出参数应使用指针类型取地址、*解引用输出应优先通过元组/结构体返回值。auto返回类型由函数体内所有return语句参数的静态类型的公共类型common type推导且不允许出现在前向声明中。控制流所有控制流语句的块都必须用花括号提案 #623不同于 C 可省略单语句花括号if/else if/else条件为boolwhile条件为真则循环for基于范围的循环如for (name: String in names) { Core.Print(name); }break立即结束循环continue立即进入下一轮循环return结束函数执行returned var用于避免拷贝类似 C 的 NRVO 命名返回值优化returned var c: Circle; ... return var;match类似 C/Swift 的 switch表达式依次与各case的可反驳模式匹配可带if守卫与defaultfn Foo() - f32 { match (Bar()) { case (42, (x: f32, y: f32)) { return x - y; } case (p: i32, (x: f32, _: f32)) if (p 13) { return p * x; } default { return Pi; } } }2.10 用户定义类型类Classes与选择类型Choice types**名义类nominal class**用class定义字段用var声明字段声明顺序即内存布局顺序类体内Self指代类自身成员用.访问。类内还可定义常量、成员类嵌套类。关键机制包括赋值与构造结构体字面量到同字段类类型存在隐式转换在可访问所有字段的范围内Carbon 没有 C 式构造函数常用非实例成员函数类似 C 静态成员函数作为工厂函数返回Self需要实例地址时用returned var如fn Make() - Self { returned var result: Self {...}; ...; return var; }方法methods把self作为参数表第一个参数即成为方法fn Distance(self, ...)只读、fn Offset(ref self, ...)可修改只能对引用表达式调用方法可类内内联定义也可fn Point.Offset(ref self, ...) { ... }类外定义继承Carbon 只支持单继承类的默认语义是final不可扩展用base class或abstract class引入器声明可扩展的基类abstract 不可实例化。派生类用extend base: MyBaseClass;声明基类。虚方法分三种关键字virtual本类有定义、abstract本类无定义、非抽象派生类必须定义、impl本类定义并覆盖基类定义。指向派生类的指针可转为基类指针配合match的case dyn p: MiddleDerived* 做运行时类型测试。构造派生类时base如同第一个字段抽象类通过返回partial Self的protected工厂函数供派生类使用访问控制类成员默认公开private限制在类内与友元friend声明只能引用编译器可解析的名字不充当前向声明protected额外开放给派生类析构函数fn destroy(self)或fn destroy(ref self)类析构先于成员析构成员按声明逆序销毁派生类先于基类销毁虚析构需virtual/impl关键字禁止通过基类指针删除派生类实例除非基类析构为virtual/impl确认无派生类型时用UnsafeDeleteconst类型const MyClass与MyClass数据表示相同MyClass*可隐式转const MyClass*const引用表达式可自动转值表达式const MyClass的 API 是MyClass的子集仅const Self的ref方法有效注意const比后缀*绑定更紧const MyClass*即(const MyClass)*非成形状态unformed state类型通过实现特定接口声明支持非成形状态对其只能做从完整值赋值与销毁且销毁必须可选不泄漏资源。示例所有平凡析构类型如i32的任何值都是合法的非成形表示移动move类型可自定义移动语义~x移动运算符将x置为非成形状态并返回其旧值provisional混入mixin用于实现复用对标 C 的 CRTP/多继承设计仍在开发中provisional。**选择类型choice types**是带标签的联合tagged unionchoice IntResult { Success(value: i32), Failure(error: String), Cancelled }。值由一个 case 及其参数构成可用.Failure(...)短路构造用match消费无参数的 choicechoice LikeABoolean { False, True }即枚举类型。2.11 命名体系包、库、文件与可见性Carbon 的模块化体系分为三层文件组成库library库组成包package库是导入/代码复用的粒度包是分发单位。每个库恰好一个API 文件声明所有公开名字 任意个实现文件定义。每个包有自己的命名空间包内库需协调避免名字冲突跨包则完全隔离。包声明文件开头的可选package声明由四部分组成——可选的impl修饰表示实现文件、可选的package 名称、可选的library 名称、结尾分号。例如package Geometry library Shapes;省略规则省略package则属于Main包不可被其他包导入省略library则属于默认库两者都省略则整个包声明必须省略此时文件是Main包默认库的 API 文件只能容纳程序入口与测试示例。Main包默认库中的Run函数即程序入口否则入口可由其他语言如 C 的main定义。入口签名尚未定案。导入import声明必须位于所有非package声明之前。同包导入省略包名import library Vertex;导入同包默认库用import library default;Main包中禁止。实现文件自动导入本库 API 文件显式重复导入报错。跨包导入import LinearAlgebra library Vector; import ArbitraryPrecision; // 导入默认库import PackageName会引入PackageName这个名字导入Main包、指定library default跨包场景应省略 library 部分、指定当前包名均为错误。可见性API 文件中的声明默认公开private前缀使其成为库私有本文件 本库所有实现文件可见实现文件中的名字默认文件私有其首次声明必须带private。私有名字不与私有区域外的名字冲突。一个程序传递使用的所有 API 文件中同一公开名字最多只能被一个文件声明。包作用域与命名空间文件顶层作用域即包作用域package.Foo可显式限定命名空间用namespace N;声明可嵌套namespace M.L;其成员可用P.N.K()这样的限定路径访问。命名约定提案 #861惯用 Carbon 代码无法有动态变化值的实体用UpperCamelCase函数、命名空间、编译期常量、虚方法运行期才知值的实体用lower_snake_case变量Carbon 自带特性关键字与类型字面量用lower_snake_case。别名aliasalias NewName SomePackage.OldName;注意右边是名字而非值alias four 4;非法因此可以给命名空间等非值实体起别名典型用途是迁移期新旧名字共存以及把接口实现中的成员纳入公开 APIclass ContactInfo { impl as Printable; alias PrintToScreen Printable.Print; ... }名字查找Carbon 的原则是在所有相关作用域中查找名字若找到多个不同实体则报错并要求显式限定而不是像 C 那样静默遮蔽shadowing。无限定查找沿语义上的外层作用域而非仅词法进行所以类外定义的方法体内仍能看到类作用域的名字。常见类型的前奏i32、bool等类型字面量指向自动导入的 prelude 包中的类型体现 All APIs are library APIs 原则docs/project/principles/library_apis_only.md。2.12 泛型Checked 与 Template 双轨制泛型允许函数/类等以编译期参数泛化。示例fn MinT: Ordered - T { return if x y then x else y; }T在[]推导参数表中由显式实参的类型自动推导T是 facet面约束为实现Ordered接口的任意类型。泛型参数分两种Checked 泛型函数体在定义时独立于具体T完成类型检查名字查找委托给约束如Ordered调用时只需验证推导值满足约束。相位为符号常量是首选方案Template 泛型以template关键字标记调用时实例化类似 C 模板的延迟类型检查、鸭子类型与惰性绑定但不采用 SFINAE而是以签名中显式声明的约束控制。相位为模板常量。模板的价值在于 C/Carbon 代码迁移以及规避 checked 泛型类型检查过于严格的一些场景。模板名字查找除了约束还会在实际实参类型中查找因此TemplateDrawtemplate T: type { x.Draw(); }在T Game时调用Game.Draw而ConstrainedTemplateDraw[template T: Renderable]因找到两个不同的Draw而报错——这一机制支持逐步加约束、编译器验证语义不变、最终移除template切换为 checked的安全迁移路径。接口interface与实现impl接口规定类型必须满足的需求集合同时充当约束与能力假设interface Printable { fn Print(self); }类型只有通过显式impl声明才算实现接口仅有同名同签名函数不够class Circle { var radius: f32; impl as Printable { fn Print(self) { Core.Print(Circle with radius: {0}, self.radius); } } }接口可含接口默认成员、final成员、关联 facet、对其它接口的需求等。实现的方法可用复合成员访问c.(Printable.Print)()限定调用用extend impl as Printable可把接口成员并入类型的直接成员。无extend的实现不必与类型定义同库但受孤儿规则orphan rule约束以保证一致性coherence。接口与实现可前向声明。约束组合用组合多个 facet 类型约束fn PrintMinT: Ordered Printable两接口都有同名成员时用x.(GameResult.Draw)()这样的复合访问消歧。关联常量associated constants接口中用无初始化器的let声明值由具体实现的where子句指定interface StackInterface { let ElementType: Movable; fn Push(ref self, value: ElementType); ... } class IntStack { extend impl as StackInterface where .ElementType i32 { ... } }泛型实体类、choice、接口、实现都可泛型化。例如泛型栈类class Stack(T: type) { var storage: buf(T); ... }。2.13 与 C/C 的双向互操作设计文档为 C/C 互操作明确了目标作为 C 继任者Carbon 需要双向互操作——既导入 C/C 代码也被 C/C 导入。关键设计点包括导入机制与#include的关系、ABI 与动态链接、运算符重载与模板的对应、标准类型映射、继承与枚举的处理。仓库中 proposals/p006254-c-interop-toolchain-implementation-for-function-calls.md、proposals/p006641-clang-irgen-in-carbon.md 等提案正在逐步落实这些设计docs/spec/ 也包含 C 互操作类型映射的规范草案如 docs/spec/lang/libs.md。示例层面examples/interop/cpp/ 提供了 C 互操作的直接代码样例。2.14 未完成的设计Unfinished tales设计文档明确列出了尚在演进的主题安全策略Safety、生命周期与移动语义、元编程、把模式匹配作为函数重载决议、错误处理、执行抽象抽象机与执行模型、Lambda、协程、并发。其中Safety是最受关注的方向之一仓库内 docs/design/safety/ 与 proposals/p005914-updating-carbon-s-safety-strategy.md、proposals/p004880-safety-milestones-and-a-2025-roadmap.md 详细阐述了其安全里程碑与 2025 路线图。阅读这些未完成章节时应结合对应的 proposals 查看最新决策。三、项目治理文档project/目标、原则与贡献流程docs/project/README.md 汇集项目相关文档结构清晰目标与原则goals.md 定义项目总体目标principles/ 收录从目标推导出的设计原则如 Errors are values、All APIs are library APIs、Information accumulation 等roadmap.md 与 roadmap_process.md 说明路线图及其更新流程项目运作evolution.md 描述演进与治理流程groups.md 列出关键贡献者联系与权限获取方式如何贡献包括 contribution_tools.md贡献工具、design_style_guide.md设计文档风格、cpp_style_guide.mdC 代码风格、code_review.md代码评审规范以及 pull_request_workflow.md基于主干分支的 PR 工作流。project 目录与 design 目录的分工值得注意design 解决语言是什么、为什么project 解决项目往哪走、怎么协作——目标 → 原则 → 路线图形成一条可追溯的决策链。四、用户指南guides/与语言规范spec/两个待编写的承诺docs/guides/README.md 明确标注该目录用于存放面向最终用户的 Carbon 编程文档当前状态为to-be-written待编写现有内容为一份 glossary.md术语表供正在使用和编写 Carbon 代码的人查阅。docs/spec/README.md 则承诺未来容纳Carbon 语言的形式化规范formal specification——其目标写得非常明确规范要详细到足以支撑语言的独立实现即除了参考实现之外让第三方也能据规范构建编译器。规范分为两部分Language specification语言规范涵盖词法lex.md、解析parsing.md、命名names.md、语义semantics.md、执行execution.md与库libs.md等主题均为进行中的草稿Library specification库规范规定标准库的契约。spec 与 toolchain 的关系在 docs/README.md 中已言明规范**补充complement**而非替代 toolchain/ 中的编译器实现。实际上当前仓库的编译器实现toolchain/ 下的 lexer、parser、checker、lower、codegen 等模块就是参考实现的主体规范文档与实现相互印证。五、设计文档与提案Proposals的演进关系docs/README.md 专门强调了一个阅读要点design 文档 ≠ proposals。docs/design/ 是当前已接受设计的系统化沉淀回答What is the design and whyproposals/README.md 记录每一个具体决策的来龙去脉含动机、备选方案与被否决的理由是设计文档的历史与证据链。proposals 目录的命名规范即体现了这种关联p######-slug.md######为提案 PR 号补齐到 6 位同号子目录存放关联文件。例如整型语义对应 proposals/p001083-arithmetic-expressions.md、类型即值对应 proposals/p002360-types-are-values-of-type-type.md、Core.Array对应 proposals/p004682-the-core-array-type-for-direct-storage-immutably-sized-buffers.md。设计文档中每个小节的 References 块都会列出支撑该设计的提案编号这是做深度研究的入口索引。仓库内设计文档还大量交叉引用具体源码与测试例如 core/prelude/ 中的前奏实现、examples/ 下的可运行示例含 2024 圣诞日历的 examples/advent2024/ 系列、toolchain/check/ 的类型检查实现等可作为验证设计落地情况的一手资料。六、阅读路线图建议综合 docs/README.md 的导航与各子文档的定位可以给出如下阅读路径快速了解项目仓库根 README.md → docs/project/goals.md评估语言本身docs/design/README.md本文第二章的内容即其浓缩与展开→ 按需深入 docs/design/expressions/、docs/design/generics/ 等专题目录理解决策历史在设计文档 References 中定位对应 proposals如 proposals/p002200-template-generics.md、proposals/p000524-generics-overview.md验证实现阅读 toolchain/ 源码与 examples/ 示例、integration_tests/ 集成测试参与治理查阅 docs/project/contribution_tools.md 与 docs/project/pull_request_workflow.md。需要提醒的是Carbon 仍处于实验阶段官方在 README 中明确标注 experimental设计文档大量使用 provisional / TODO / Open question 标记。阅读时若遇到此类标记说明该特性尚未走完提案流程应以 proposals 目录中的最新决策为准避免把未定案的设计当作既定事实。【免费下载链接】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），仅供参考