尧图网页设计 
Carbon Language 项目目标提案解读从提案 p000051 到七大语言目标与优先级体系【免费下载链接】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 仓库中的提案 p000051-goals.md 展开系统梳理这份早期提案如何为整个实验性项目奠定目标与优先级的顶层设计框架它产出了正式的目标文档 docs/project/goals.md 与成功标准原则 docs/project/principles/success_criteria.md。读完本文你将完整掌握 Carbon 的两层项目目标、七大语言目标及其严格优先级顺序、五条显式非目标以及这套体系在路线图流程docs/project/roadmap_process.md与演进治理docs/project/evolution.md中被如何强制引用和执行。提案背景为什么要先定目标提案的问题陈述Problem非常直白Carbon 项目需要一个清晰的目标集既用于确立也用于记录项目预期走向。这些目标是愿景性的aspirational团队会尽力全部达成同时白纸黑字的目标还能让潜在用户快速判断 Carbon 是否适合自己而不用读完整个代码库或设计文档。在背景Background部分提案明确承认Carbon 的目标体系深受 C 社区的《Goals and priorities for C》一文影响并致谢其作者。这份提案本身最初是在 Google Docs 中草拟的随后以 GitHub Pull Request 形式进入仓库——这也符合 Carbon 以提案驱动演进的治理模式见 docs/project/evolution.md。提案核心目标文档 成功标准目标的落地形态提案的正文非常简短因为它把真正的内容封装在链接指向的正式文档中语言与项目目标docs/project/goals.md成功标准原则docs/project/principles/success_criteria.md。这种提案只是决策记录、正文放进活文档的做法是 Carbon 提案体系的典型特征提案文档承载为什么这样决定Problem / Alternatives / Rationale而长期有效的设计文档承载决定是什么。为什么用成功标准而不是度量指标提案的包含成功标准Including success criteria一节记录了一个重要的设计决策当时讨论过给目标附加具体度量指标metrics最终决定不放进目标文档因为预期这些度量会以独立原则principle的形式补充。成功标准原则因此被设计为具体的、可度量的关键结果用于检验目标是否达成且明确表示这份清单并非穷尽exhaustive——未来还会补充更多平台与迁移工具之外的标准。成功标准原则的实质性内容success_criteria.md 给出了两个已落地的可度量标准提案中明确提到Platforms平台和Migration tooling迁移工具两类平台维度优先支持的 OS 平台Linux含常见发行版、Android、ChromeOS、FreeBSD、Windows、macOS 与 iOS、Fuchsia、WebAssembly、裸机Bare metal优先硬件架构64 位小端硬件包括 x86-64、AArch64ARM 64 位、PPC64LEPower ISA 64 位小端、RV64IRISC-V 64 位明确不优先支持的历史平台特征非 8 位字节、非 2 的幂字长、非 UTF-8 源码编码、大端或混合端序、非补码non-2s-complement整数格式、非 IEEE 754 二进制浮点格式以及不支持文件扩展名/嵌套目录的文件系统。迁移工具维度最关键的量化指标给定一个遵循最佳实践的大型代码库目标是将需要人工介入的文件比例控制在 2% 以下该指标包含修复迁移工具引入的 Carbon 特有性能缺陷、转换迁移工具无法处理的复杂代码该指标不包含把代码清洗成惯用的idiomaticCarbon 风格例如重度使用 C 预处理宏的代码展开后可能没有对应的 Carbon 元编程构造。成功标准在 roadmap_process.md 中被明确纳入年度目标与关键结果OKR的制定依据与 goals.md 和战术特性并列未达标将被视为重大问题而可能削弱成功标准的提案会面临额外审查。目标体系全解项目目标与语言目标提案的产物 goals.md 将目标划分为两个正交的层面这一划分正是提案以不同方式处理项目目标Address project goals differently一节讨论后的结果。项目目标Project goals不参与数字排序提案记录了这样一个治理问题演进治理文档要求所有决策都要用目标来论证但行为准则code of conduct这类事务并没有对应的语言目标更极端的情形是——如果性能是最高优先级是否意味着留住一位性能专家可以优先于处理其不当行为为了回答这类问题提案决定引入项目目标但不把它们放进数字优先级列表语言目标的排序用于权衡语言设计而项目目标与语言设计正交orthogonal。项目目标分为两条社区与文化打造健康、有活力、包容、务实、欢迎的社区。关键要素包括行为准则一致的期望 真实可执行的管理机制、开放的变更流程人人可参与方向与演进决策透明可追溯并明确包容不等于把所有人都包含进来——不可避免地会有偏重某些成员的选择但会给出理由。语言工具与生态语言不能只靠设计成功必须解决让开发者高效工作的整套生态包括参考实现reference implementation但不替代正式规范、正式规范specification与参考实现必须收敛分歧被视为必须修复的 bug、易上手的开发者文档、有说服力的采用工具如 C→Carbon 翻译器、Carbon 自身演进时的代码更新工具、开发者工具格式化、重构、LSP、编辑器集成、机器可读文法、以及支持包管理与库生态的基础设施。语言目标与优先级严格排序的七项goals.md 明确写出许多语言都有这些目标的子集但 Carbon 的区别在于它们的组合并且在需要权衡时按如下顺序优先优先级目标核心内涵源自 goals.md#1性能关键软件Performance-critical software开发者对性能的每个方面都有控制权惯用代码应该快性能可预测、不意外无需切换到更低层语言#2软件与语言演进Software and language evolution支持用 Carbon 写的软件数十年的维护与演进语言自身也能数十年演进第 73 次尝试可能才正确留意遗留legacy——全球约 500 亿行 C 代码#3易读、易理解、易写的代码Code that is easy to read, understand, and write卓越的人机工效ergonomics全层次工具支持含 IDE支持主用例之外的软件鼓励恰当使用而非限制误用行为语义尽量清晰简单最少惊讶原则设计上易于实现#4实用的安全与测试机制Practical safety and testing mechanisms尽量多做编译期检查不安全的代码要在语法上显式可见常见不安全模式支持静态检查所有不安全操作支持动态检查#5快速、可扩展的开发Fast and scalable development语法解析只需有界、小的前瞻bounded, small look-ahead解析不依赖语义或上下文信息支持分离编译含并行与分布式策略#6现代 OS 平台、硬件架构与环境Modern OS platforms, hardware architectures, and environments对现代主流平台提供原生支持不仅是抽象翻译如原子操作、多套并行实现都要可直接寻址不优先支持历史平台#7与现有 C 代码的互操作与迁移Interoperability with and migration from existing C codeC 开发者熟悉、学习曲线平缓表达力与 C 相当大规模惯用 C 代码的自动源码到源码迁移高保真与现有 C 代码双向互操作互操作与迁移为何排在 #7提案的详细权衡这是整份提案中篇幅最长、论证最细的一节。提案承认有至少部分人认为互操作/迁移应进入前三甚至第一但最终结论是可以围绕 #7 形成共识前提是明确互操作的最低期望。优先级冲突的根源之一是对可读性的两种解读边缘语法解读C 互操作语法属于边缘情况大部分代码可避免因此不显著影响可读性目标全有或全无解读互操作语法可能让所有代码变得更难读即互操作目标颠覆了可读性目标此时要么互操作优先级高于可读性要么干脆不要互操作。提案作者倾向第一种解读但指出第二种解读正是有人主张互操作高优先级的原因。把互操作提到最高优先级的优点存在共识认为互操作至关重要把它放在首位能强调这一点。缺点其他目标同样关键不足以据此定序而且已有共识认为许多权衡中互操作应让位于其他目标反向的清晰案例却很少若互操作优先级高于演进甚至可能意味着从 C 起步、在其基础上增量演进——但团队已观察到 C 在演进上的困难Carbon 不应为不破坏现有代码而困在类似的局部最优local maxima上。提案还给出了当时可见的具体权衡案例这些案例现在都能在 goals.md 与设计文档中找到印证基本类型集合Carbon 的基本类型不会与 C 一一对应多个 C 类型可能映射到单一 Carbon 类型——这同时与 #2更少的类型让语言演进更容易和 #3更少的类型让代码更易读冲突IntvsintCarbon 用Int等主类型替换 C 规定的溢出行为如陷阱而非回绕——这与 #1更高性能、#3避免平台相关类型、#4溢出陷阱让代码更安全都相关平台支持Carbon 与 C/C 的平台支持优先级不同与 #6现代优先于遗留冲突宏 vs 元编程C 预处理宏将由 Carbon 元编程取代宏代码的迁移形态尚不明确——与 #2结构化元编程更利于演进、#3元编程比宏更易读相关模板有观点认为模板只是为了互操作/迁移而存在。提案认为这不算优先级冲突——模板虽然难读触及 #3但不像基本类型那样约束语言的其余部分不是核心或必需的。五条显式非目标Non-goalsgoals.md 专门列出常见语言目标中 Carbon 明确不做的部分这些不意味着不好而是权衡后无价值或代价过高稳定的语言与库 ABI提供广泛 ABI 稳定性会永久性束缚高级构造的设计、阻碍演进。但不排除提供低层特性/工具来创建特定、精选的稳定 ABI如 protobuf 式序列化、Python pickle、COM、Swift 的 resilience 模型等方向向后/向前兼容聚焦迁移而非兼容采用 live-at-head 模型承认由于海勒姆定律Hyrums Law升级必然需要主动迁移无源码或无法重建的遗留编译库不优先支持无源码的遗留代码但希望工具能帮助桥接不同 ABI含插件 ABI支持现有编译与链接模型必要时会改变 C 本身的编译/链接模型以服务互操作作为具体例子不支持无法随语言同步更新编译器和链接器的平台非现代、非惯用 C 代码的惯用迁移迁移支持优先那些遵循合理 C 最佳实践的代码避免未定义行为、有良好测试覆盖、用 sanitizer 验证。超越目标本身的优先级决策框架goals.md 还规定当目标与优先级不足以裁决时回退到成本收益分析——测量成本含复杂度与对整个项目和语言的影响收益随时间累积因此尽早提供增量方案通常总收益更高对于领域驱动的库与特性成本通常是规格与实现的工作量收益来自用户数量与效用。备选方案回顾提案讨论过的其他路线提案的 Alternatives 部分记录了三个被否决的方向完全删除社区/项目目标Status quo 之外的选项之一让本文档成为纯粹的语言目标文档。缺点需要额外文档才能理解语言目标社区与语言设计冲突时的裁决更模糊把项目目标并入数字优先级列表排序无歧义但会让原本聚焦语言设计的数字列表失焦且无法再说性能是我们的最高优先级——除非社区不是最高优先级否则会重新制造当初引入项目目标要解决的冲突重新合并项目目标与语言目标回到最初只有一个目标与优先级章节的状态文档更短更简洁工具性内容已可归入 #3 目标。缺点会重新触发社区目标为何不在优先级列表里的反对意见。提案最终维持了项目目标与语言目标分离、项目目标不进排序的现状方案。动机论证Rationale与开放问题提案的 Rationale 给出三点理由一套具体的目标对确保贡献者朝同一方向工作是必需的也是衡量项目各方面进展的标尺语言需要有连贯、被认同的愿景作为开发者与使用者之间的社会契约这些目标不仅反映核心团队想建设的社区与语言也反映大量 C 用户对 C 本身的诉求——因此这套目标可视为对C 的一个候选未来的实验方向虽然目标之间尤其是可迁移性与 C 互操作的冲突解决存在不确定性核心团队认为整体方向一致优先级可以根据实践反馈随时修订。开放问题Open questions提案记录没有开放问题但指出 GitHub issue #106 中留有待后续提案考虑/解决的点。目标体系在仓库中的实际执行证据从当前仓库看这套目标并非一纸空文而是被下游广泛引用、可验证的决策锚点路线图流程docs/project/roadmap_process.md 规定年度路线图的 OKR 必须基于 goals.md、success_criteria.md 与战术特性路线图用于让团队把精力聚焦在与当前目标一致的提案上原则体系docs/project/principles/README.md 说明原则澄清但不取代目标与优先级并列出错误即值、低上下文敏感度、单一静态开放扩展机制、成功标准等具体原则互操作设计docs/design/interoperability/philosophy_and_goals.md 开门见山引用 #7 目标并强调性能和演进是更高优先级这一关键前提同时把互操作聚焦到 C17 兼容、尽量零开销桥接代码等具体目标泛型设计docs/design/generics/goals.md 直接以性能是 Carbon 的最高优先级#1论证 checked generics 的性能要求并以 #2 演进目标论证接口的演进机制默认实现、upcoming/deprecated 标记安全设计docs/design/safety/README.md 引用目标体系指导安全策略的制定与 #4实用安全与测试机制目标呼应提案工具链新提案由 proposals/scripts/template.md 模板与 proposals/scripts/new_proposal.py 脚手架生成模板要求提案论证时引用项目目标——p000051 本身就是这一闭环的起点。总结提案 p000051 是 Carbon 项目最早的顶层设计文件之一它以极简的提案正文 活文档的方式一次性确立了项目目标正交、不排序 七大语言目标严格排序 五条非目标 成功标准可度量、非穷尽的完整决策体系。理解这套体系是阅读 docs/project 下所有设计文档、原则与路线图文档的前提本文梳理的优先级顺序、非目标边界与量化成功标准如迁移工具人工介入 2% 文件可以直接作为评估 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），仅供参考 Carbon Language 项目目标提案解读：从提案 p000051 到七大语言目标与优先级体系
Carbon Language 项目目标提案解读从提案 p000051 到七大语言目标与优先级体系【免费下载链接】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 仓库中的提案 p000051-goals.md 展开系统梳理这份早期提案如何为整个实验性项目奠定目标与优先级的顶层设计框架它产出了正式的目标文档 docs/project/goals.md 与成功标准原则 docs/project/principles/success_criteria.md。读完本文你将完整掌握 Carbon 的两层项目目标、七大语言目标及其严格优先级顺序、五条显式非目标以及这套体系在路线图流程docs/project/roadmap_process.md与演进治理docs/project/evolution.md中被如何强制引用和执行。提案背景为什么要先定目标提案的问题陈述Problem非常直白Carbon 项目需要一个清晰的目标集既用于确立也用于记录项目预期走向。这些目标是愿景性的aspirational团队会尽力全部达成同时白纸黑字的目标还能让潜在用户快速判断 Carbon 是否适合自己而不用读完整个代码库或设计文档。在背景Background部分提案明确承认Carbon 的目标体系深受 C 社区的《Goals and priorities for C》一文影响并致谢其作者。这份提案本身最初是在 Google Docs 中草拟的随后以 GitHub Pull Request 形式进入仓库——这也符合 Carbon 以提案驱动演进的治理模式见 docs/project/evolution.md。提案核心目标文档 成功标准目标的落地形态提案的正文非常简短因为它把真正的内容封装在链接指向的正式文档中语言与项目目标docs/project/goals.md成功标准原则docs/project/principles/success_criteria.md。这种提案只是决策记录、正文放进活文档的做法是 Carbon 提案体系的典型特征提案文档承载为什么这样决定Problem / Alternatives / Rationale而长期有效的设计文档承载决定是什么。为什么用成功标准而不是度量指标提案的包含成功标准Including success criteria一节记录了一个重要的设计决策当时讨论过给目标附加具体度量指标metrics最终决定不放进目标文档因为预期这些度量会以独立原则principle的形式补充。成功标准原则因此被设计为具体的、可度量的关键结果用于检验目标是否达成且明确表示这份清单并非穷尽exhaustive——未来还会补充更多平台与迁移工具之外的标准。成功标准原则的实质性内容success_criteria.md 给出了两个已落地的可度量标准提案中明确提到Platforms平台和Migration tooling迁移工具两类平台维度优先支持的 OS 平台Linux含常见发行版、Android、ChromeOS、FreeBSD、Windows、macOS 与 iOS、Fuchsia、WebAssembly、裸机Bare metal优先硬件架构64 位小端硬件包括 x86-64、AArch64ARM 64 位、PPC64LEPower ISA 64 位小端、RV64IRISC-V 64 位明确不优先支持的历史平台特征非 8 位字节、非 2 的幂字长、非 UTF-8 源码编码、大端或混合端序、非补码non-2s-complement整数格式、非 IEEE 754 二进制浮点格式以及不支持文件扩展名/嵌套目录的文件系统。迁移工具维度最关键的量化指标给定一个遵循最佳实践的大型代码库目标是将需要人工介入的文件比例控制在 2% 以下该指标包含修复迁移工具引入的 Carbon 特有性能缺陷、转换迁移工具无法处理的复杂代码该指标不包含把代码清洗成惯用的idiomaticCarbon 风格例如重度使用 C 预处理宏的代码展开后可能没有对应的 Carbon 元编程构造。成功标准在 roadmap_process.md 中被明确纳入年度目标与关键结果OKR的制定依据与 goals.md 和战术特性并列未达标将被视为重大问题而可能削弱成功标准的提案会面临额外审查。目标体系全解项目目标与语言目标提案的产物 goals.md 将目标划分为两个正交的层面这一划分正是提案以不同方式处理项目目标Address project goals differently一节讨论后的结果。项目目标Project goals不参与数字排序提案记录了这样一个治理问题演进治理文档要求所有决策都要用目标来论证但行为准则code of conduct这类事务并没有对应的语言目标更极端的情形是——如果性能是最高优先级是否意味着留住一位性能专家可以优先于处理其不当行为为了回答这类问题提案决定引入项目目标但不把它们放进数字优先级列表语言目标的排序用于权衡语言设计而项目目标与语言设计正交orthogonal。项目目标分为两条社区与文化打造健康、有活力、包容、务实、欢迎的社区。关键要素包括行为准则一致的期望 真实可执行的管理机制、开放的变更流程人人可参与方向与演进决策透明可追溯并明确包容不等于把所有人都包含进来——不可避免地会有偏重某些成员的选择但会给出理由。语言工具与生态语言不能只靠设计成功必须解决让开发者高效工作的整套生态包括参考实现reference implementation但不替代正式规范、正式规范specification与参考实现必须收敛分歧被视为必须修复的 bug、易上手的开发者文档、有说服力的采用工具如 C→Carbon 翻译器、Carbon 自身演进时的代码更新工具、开发者工具格式化、重构、LSP、编辑器集成、机器可读文法、以及支持包管理与库生态的基础设施。语言目标与优先级严格排序的七项goals.md 明确写出许多语言都有这些目标的子集但 Carbon 的区别在于它们的组合并且在需要权衡时按如下顺序优先优先级目标核心内涵源自 goals.md#1性能关键软件Performance-critical software开发者对性能的每个方面都有控制权惯用代码应该快性能可预测、不意外无需切换到更低层语言#2软件与语言演进Software and language evolution支持用 Carbon 写的软件数十年的维护与演进语言自身也能数十年演进第 73 次尝试可能才正确留意遗留legacy——全球约 500 亿行 C 代码#3易读、易理解、易写的代码Code that is easy to read, understand, and write卓越的人机工效ergonomics全层次工具支持含 IDE支持主用例之外的软件鼓励恰当使用而非限制误用行为语义尽量清晰简单最少惊讶原则设计上易于实现#4实用的安全与测试机制Practical safety and testing mechanisms尽量多做编译期检查不安全的代码要在语法上显式可见常见不安全模式支持静态检查所有不安全操作支持动态检查#5快速、可扩展的开发Fast and scalable development语法解析只需有界、小的前瞻bounded, small look-ahead解析不依赖语义或上下文信息支持分离编译含并行与分布式策略#6现代 OS 平台、硬件架构与环境Modern OS platforms, hardware architectures, and environments对现代主流平台提供原生支持不仅是抽象翻译如原子操作、多套并行实现都要可直接寻址不优先支持历史平台#7与现有 C 代码的互操作与迁移Interoperability with and migration from existing C codeC 开发者熟悉、学习曲线平缓表达力与 C 相当大规模惯用 C 代码的自动源码到源码迁移高保真与现有 C 代码双向互操作互操作与迁移为何排在 #7提案的详细权衡这是整份提案中篇幅最长、论证最细的一节。提案承认有至少部分人认为互操作/迁移应进入前三甚至第一但最终结论是可以围绕 #7 形成共识前提是明确互操作的最低期望。优先级冲突的根源之一是对可读性的两种解读边缘语法解读C 互操作语法属于边缘情况大部分代码可避免因此不显著影响可读性目标全有或全无解读互操作语法可能让所有代码变得更难读即互操作目标颠覆了可读性目标此时要么互操作优先级高于可读性要么干脆不要互操作。提案作者倾向第一种解读但指出第二种解读正是有人主张互操作高优先级的原因。把互操作提到最高优先级的优点存在共识认为互操作至关重要把它放在首位能强调这一点。缺点其他目标同样关键不足以据此定序而且已有共识认为许多权衡中互操作应让位于其他目标反向的清晰案例却很少若互操作优先级高于演进甚至可能意味着从 C 起步、在其基础上增量演进——但团队已观察到 C 在演进上的困难Carbon 不应为不破坏现有代码而困在类似的局部最优local maxima上。提案还给出了当时可见的具体权衡案例这些案例现在都能在 goals.md 与设计文档中找到印证基本类型集合Carbon 的基本类型不会与 C 一一对应多个 C 类型可能映射到单一 Carbon 类型——这同时与 #2更少的类型让语言演进更容易和 #3更少的类型让代码更易读冲突IntvsintCarbon 用Int等主类型替换 C 规定的溢出行为如陷阱而非回绕——这与 #1更高性能、#3避免平台相关类型、#4溢出陷阱让代码更安全都相关平台支持Carbon 与 C/C 的平台支持优先级不同与 #6现代优先于遗留冲突宏 vs 元编程C 预处理宏将由 Carbon 元编程取代宏代码的迁移形态尚不明确——与 #2结构化元编程更利于演进、#3元编程比宏更易读相关模板有观点认为模板只是为了互操作/迁移而存在。提案认为这不算优先级冲突——模板虽然难读触及 #3但不像基本类型那样约束语言的其余部分不是核心或必需的。五条显式非目标Non-goalsgoals.md 专门列出常见语言目标中 Carbon 明确不做的部分这些不意味着不好而是权衡后无价值或代价过高稳定的语言与库 ABI提供广泛 ABI 稳定性会永久性束缚高级构造的设计、阻碍演进。但不排除提供低层特性/工具来创建特定、精选的稳定 ABI如 protobuf 式序列化、Python pickle、COM、Swift 的 resilience 模型等方向向后/向前兼容聚焦迁移而非兼容采用 live-at-head 模型承认由于海勒姆定律Hyrums Law升级必然需要主动迁移无源码或无法重建的遗留编译库不优先支持无源码的遗留代码但希望工具能帮助桥接不同 ABI含插件 ABI支持现有编译与链接模型必要时会改变 C 本身的编译/链接模型以服务互操作作为具体例子不支持无法随语言同步更新编译器和链接器的平台非现代、非惯用 C 代码的惯用迁移迁移支持优先那些遵循合理 C 最佳实践的代码避免未定义行为、有良好测试覆盖、用 sanitizer 验证。超越目标本身的优先级决策框架goals.md 还规定当目标与优先级不足以裁决时回退到成本收益分析——测量成本含复杂度与对整个项目和语言的影响收益随时间累积因此尽早提供增量方案通常总收益更高对于领域驱动的库与特性成本通常是规格与实现的工作量收益来自用户数量与效用。备选方案回顾提案讨论过的其他路线提案的 Alternatives 部分记录了三个被否决的方向完全删除社区/项目目标Status quo 之外的选项之一让本文档成为纯粹的语言目标文档。缺点需要额外文档才能理解语言目标社区与语言设计冲突时的裁决更模糊把项目目标并入数字优先级列表排序无歧义但会让原本聚焦语言设计的数字列表失焦且无法再说性能是我们的最高优先级——除非社区不是最高优先级否则会重新制造当初引入项目目标要解决的冲突重新合并项目目标与语言目标回到最初只有一个目标与优先级章节的状态文档更短更简洁工具性内容已可归入 #3 目标。缺点会重新触发社区目标为何不在优先级列表里的反对意见。提案最终维持了项目目标与语言目标分离、项目目标不进排序的现状方案。动机论证Rationale与开放问题提案的 Rationale 给出三点理由一套具体的目标对确保贡献者朝同一方向工作是必需的也是衡量项目各方面进展的标尺语言需要有连贯、被认同的愿景作为开发者与使用者之间的社会契约这些目标不仅反映核心团队想建设的社区与语言也反映大量 C 用户对 C 本身的诉求——因此这套目标可视为对C 的一个候选未来的实验方向虽然目标之间尤其是可迁移性与 C 互操作的冲突解决存在不确定性核心团队认为整体方向一致优先级可以根据实践反馈随时修订。开放问题Open questions提案记录没有开放问题但指出 GitHub issue #106 中留有待后续提案考虑/解决的点。目标体系在仓库中的实际执行证据从当前仓库看这套目标并非一纸空文而是被下游广泛引用、可验证的决策锚点路线图流程docs/project/roadmap_process.md 规定年度路线图的 OKR 必须基于 goals.md、success_criteria.md 与战术特性路线图用于让团队把精力聚焦在与当前目标一致的提案上原则体系docs/project/principles/README.md 说明原则澄清但不取代目标与优先级并列出错误即值、低上下文敏感度、单一静态开放扩展机制、成功标准等具体原则互操作设计docs/design/interoperability/philosophy_and_goals.md 开门见山引用 #7 目标并强调性能和演进是更高优先级这一关键前提同时把互操作聚焦到 C17 兼容、尽量零开销桥接代码等具体目标泛型设计docs/design/generics/goals.md 直接以性能是 Carbon 的最高优先级#1论证 checked generics 的性能要求并以 #2 演进目标论证接口的演进机制默认实现、upcoming/deprecated 标记安全设计docs/design/safety/README.md 引用目标体系指导安全策略的制定与 #4实用安全与测试机制目标呼应提案工具链新提案由 proposals/scripts/template.md 模板与 proposals/scripts/new_proposal.py 脚手架生成模板要求提案论证时引用项目目标——p000051 本身就是这一闭环的起点。总结提案 p000051 是 Carbon 项目最早的顶层设计文件之一它以极简的提案正文 活文档的方式一次性确立了项目目标正交、不排序 七大语言目标严格排序 五条非目标 成功标准可度量、非穷尽的完整决策体系。理解这套体系是阅读 docs/project 下所有设计文档、原则与路线图文档的前提本文梳理的优先级顺序、非目标边界与量化成功标准如迁移工具人工介入 2% 文件可以直接作为评估 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），仅供参考