Carbon 语言的变量声明语法演进name: type顺序与 for 循环in关键字的确定proposal p000618【免费下载链接】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 仓库中的设计提案 proposals/p000618-var-ordering.md系统梳理 Carbon 语言在变量/参数声明中标识符与类型的书写顺序以及基于范围的 for 循环分隔符这两个核心语法点上的决策过程。提案最终确定了两项结论变量与参数声明统一采用name: type名字在前、类型在后以冒号分隔基于范围的 for 循环使用in而非:作为关键字。阅读本文后你将理解该决策的完整论证链条与 Swift、Rust、Kotlin、Python、Zig 等语言的一致性分析、解析歧义考量、与标签参数语法的兼容性并能在当前仓库的源码、示例与设计文档中验证这套语法如何被最终落地。背景一次被预留重审的语法决策提案开篇引用了 issue #542Re-evaluate core variable parameter identifier/type order中的背景说明还原了 Carbon 早期在变量语法上的决策处境Carbon 曾先后使用过Type: variable与Type variable两种写法用于变量、参数及其他声明这些选择当时主要建立在缺乏充分数据的基础上以尽量贴近 C作为退路设计组明确计划后续重审该语法预期触发条件是更广泛的用户调研数据例如对相当数量开发者的调查或真实的用户研究但随着周边语法逐步填充完毕项目获得了新的具体信息包括Type variable写法带来的一些虽可能可以克服的解析挑战同时短期内并没有一个明确的时间表来获取有用的用户数据因此负责人决定基于已获得的新信息立即重审核心变量语法不再等待数据若未来数据出现并表明需要调整仍可再次重审。这一背景说明该提案并非推翻既有设计的仓促决定而是一次在新信息已足够、数据可继续等待条件下的主动收敛——目的是统一示例与提案中的语法减少反复讨论让社区精力聚焦到语言本身。提案内容两个语法点的收敛提案 proposals/p000618-var-ordering.md 正文只包含两项变更变量声明从type: name切换为name: type基于范围的 for 循环使用in代替:。即语言中两种写法自此定型为// 变量声明名字在前类型在后 var message: String Hello world; // 基于范围的 for 循环用 in 连接模式与容器 for (name: strbuf in names) { Print(name); }提案同时说明这些变更大部分已由 PR #563 先行实现本提案是对该方向的正式确认与记录。在 docs/design/control_flow/loops.md 的 Alternatives considered 一节中这一决策被正式收编为 for 循环设计的分支记录并注明引用本提案:versusin一节。决策理由与现代语言保持一致提案给出的理由非常克制而明确Both of these changes are done for consistency with other modern languages, particularly Swift and Rust. The switch from:toinis for ease of understanding and parsing.即name: type顺序为了与 Swift、Rust 等现代语言保持一致性in代替:为了阅读理解和解析的便利性。在基于范围的 for 循环语境中:一旦同时用于var声明就会出现for (var i: Int : list)这种冒号堆叠的写法理解成本显著高于for (var i: Int in list)而in在多种语言中早已是 for 循环的惯用关键字C#、Python、Swift、Rust 等均采用类似表达。备选方案分析三种类型顺序的完整权衡提案的 Alternatives considered 一节是全文论证最密集的部分系统对比了三种可选的声明顺序写法全部示例围绕var message: String Hello world;这一句式展开。备选一type: name早期实际使用过的写法var String: message Hello world;优点大致匹配 C、C、C#、D 和 Java 的声明顺序只是额外增加了var和:类型置于最前把最重要的信息放在显眼位置名字后面紧跟默认值与赋值语句的形态接近。缺点现有使用:的语言据 Rosetta Code 的 Variables 词条统计普遍是名字在前、类型在后除简单的不一致外:在不同顺序中的混用会给同时在多种语言间切换的开发人员带来困惑无法与用冒号标记标签参数/实参的语法保持一致如 Swift 的做法。不过提案同时澄清无论本决策结果如何Carbon 当时都不计划为标签参数和实参采用冒号语法。意见分歧点有人认为这种写法对省略类型以实现自动类型推导的场景不够友好。备选二type name无分隔符var String message Hello world;优点与 C、C、C#、D 和 Java 最为接近。缺点会造成解析歧义尤其是将来要为参数名字附加标签等语法标记时两个标识符并列会让解析器难以判断哪个是类型、哪个是名字。提案对此结论明确由于它与其他选择无法兼容详见设计文档目前很难看到让这种写法成立的可能。备选三name: type最终选定var message: String Hello world;优点与 Swift、Rust、Kotlin、Python 3 以及许多较小的语言Ada、Delphi 等 Pascal 系语言、Modula-3、Eiffel、Nim、Pony、Zig 等保持一致在struct定义中字段名字能与方法名更好地对齐。缺点名字与初始化器分离默认值不再与赋值语句形态直接对应距离 C/C 常见变量声明的朴素外观更远。意见分歧点既有语言通常会把: type部分在出现 value子句时设为可选。Carbon 的最终设计中则通过auto关键字承担省略显式类型的职责见下文落地验证。落地验证语法在仓库中的真实形态虽然本提案是 2021 年前后的设计决策其结论至今仍完整地体现在仓库的代码、示例与设计文档中。以下均来自当前仓库的实际内容。1. 变量与let绑定名字在前、类型在后examples/advent2024/day10_part1.carbon 等示例代码通篇采用该语法var bit: u256 1; var total: i32 0; var terrain: Terrain Terrain.Read();设计文档 docs/design/README.md 的 Binding patterns 一节给出了权威定义最常见的不可反驳irrefutable模式是绑定模式binding pattern由名字、冒号:与类型构成绑定该类型的一个匹配值。同一节还明确了let/var绑定的语义差异let绑定将名字绑定到一个值不可修改通常也不能取地址var绑定为对象创建专属存储名字可作引用表达式使用可修改且地址稳定。同时auto可代替绑定模式中的类型前提是类型能从同一声明中某个值的类型推导出来——这正好对应提案中省略类型以实现自动推导的分歧点讨论。docs/design/values.md 同样大量呈现该语法包括混合解构let x: i64 1; var y: i64 2; let (x: i64, var y: i64) (1, 2);2. 函数参数与返回值fn Foo(param: Type) - Typedocs/design/functions.md 中的示例与提案方向完全一致fn Add(a: i64, b: i64) - i64 { return a b; }examples/advent2024/day10_part1.carbon 中亦有带ref self的方法签名如fn AddLevel(ref self, terrain: Terrain, level: i32); fn Count(self, terrain: Terrain, level: i32) - i32;3. 基于范围的 for 循环一律使用indocs/design/control_flow/loops.md 中 for 语句的语法定义即为for (patterninexpression) {statements}并给出具体示例for (name: strbuf in names) { Print(name); }还指出为了与函数参数及其他模式匹配上下文保持一致模式默认是值不可变绑定如同let可以用var关键字覆盖默认行为以获取可变绑定for (var name: strbuf in names) { // name 可以修改但这不会修改底层的 names 容器。 }文档同时强调一个实现细节in右侧的临时对象会在 for 循环执行期间保持存活以防止无效内存访问。真实示例examples/advent2024/day10_common.carbonfor (y: i32 in Core.Range(43)) { for (x: i32 in Core.Range(43)) { // ... } }4. 用户自定义类型如何支持in循环docs/design/control_flow/loops.md 的 Ranged-for for user-defined types 一节说明用户类型通过实现Iterate接口来启用 ranged-forinterface Iterate { let ElementType: type; let CursorType: type; fn NewCursor(self) - CursorType; fn Next(self, ref cursor: CursorType) - Optional(ElementType); }光标cursor跟踪遍历进度Next方法推进光标并返回Optional值空Optional表示到达末尾。for 循环在概念上等价于Optional相关 API 当时尚未批准var cursor: range.(Iterate.CursorType) range.(Iterate.NewCursor)(); var iter: Optional(range.(Iterate.ElementType)) range.(Iterate.Next)(cursor); while (iter.HasValue()) { ExecuteForBlock(iter.Get()); iter container.(Iterate.Next)(ref cursor); }注意该伪代码中每一处变量声明同样是name: type形式可见新语法在整个语言示例中的一致性。决策的后续影响与历史脉络本提案并非孤立事件它位于 Carbon 早期语法收敛序列之中docs/design/control_flow/loops.md 的 Alternatives considered 节将该决策与 while 循环proposals/p000340-while-loops.md、for 循环proposals/p000353-for-loops.md及后续的 for 语句与用户类型提案proposals/p001885-for-statement-and-user-types.md并列记录形成一条完整的语法演进链路while 循环的备选方案中讨论了非 C 语法与在while中初始化变量for 循环的备选方案中讨论了分号式 for 循环semi-semi for loops、多变量绑定以及本文主题:versusin后续 p001885 提案继续深化用户自定义类型在 for 循环中的支持原子方法、光标与迭代器选择等。对希望深入学习的设计者而言绑定模式在 docs/design/README.md 的模式匹配章节有更完整的展开与 docs/design/pattern_matching.md、docs/design/functions.md 相互补充let/var的表达式类别差异可进一步阅读 docs/design/values.md。小结提案 proposals/p000618-var-ordering.md 是 Carbon 语言在核心声明语法上的一个关键收敛点在缺乏大规模用户数据的前提下凭借语法填充过程中获得的解析经验与跨语言一致性分析Carbon 最终确定了name: type的声明顺序并为基于范围的 for 循环选定了in关键字。从当前仓库的 示例代码、for 循环设计、绑定模式定义 与函数设计 中可以看到这套决策被完整地贯彻到了语言的每个角落——这也为后来者理解 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考