Carbon 语言前向声明的合并规则与extern关键字设计全解析【免费下载链接】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 仓库中的设计提案 p003762-merging-forward-declarations 展开系统讲解 Carbon 中前向声明forward declaration与定义definition如何合并、extern关键字在跨库声明中的语义与约束、修饰符关键字在声明与定义之间的匹配规则以及这些设计如何在编译器中落地。读完本文你将掌握 Carbon 前向声明的完整规则矩阵理解extern声明在库边界上的作用并能依据提案与设计文档判断一段 Carbon 声明代码是否合法。提案背景前向声明的合并存在哪些歧义在 Carbon 中前向声明可以与定义合并前提是两者匹配match。然而在提案提出之前设计上存在三处明显的语义模糊前向声明能否重复同一实体是否可以重复前向声明包括在定义之后再次出现是否需要关键字区分是否需要引入一个关键字将只是声明、由其他库提供定义的声明与本库即将给出定义的声明区分开修饰符是否必须一致前向声明与定义上的修饰符关键字modifier keywords是否需要保持匹配。前向声明在当前设计中的位置提案回顾了当时设计文档中对前向声明的既有规则包括顶层语言设计中的声明、定义与作用域规则见 docs/design/README.md#declarations-definitions-and-scopes类的前向声明规则见 docs/design/classes.md#forward-declaration类前向声明以分号;结尾声明的类型被视为不完整类型直到对应定义出现函数的前向声明规则见 docs/design/functions.md泛型体系中impl与interface的前向声明、以及匹配与一致Matching and agreeing的通用规则。ODR单一定义规则的启发C 的 ODR 要求每个实体有且只有一个定义但 C 在编译期很难检测 ODR 违规链接期检测也并不可靠。Carbon 同样遵循一个实体只能被一个库定义的原则其他库可以前向声明该实体但这种声明不构成定义。提案明确指出引入extern声明语法的部分目标就是基于声明更好地诊断 ODR 违规。匹配声明的合并前提当两个声明同名无论在同一文件内还是经由导入到达时它们必须匹配否则会被诊断为冲突。例如fn F(); fn F() {}—— 可以合并因为函数签名匹配、前向声明合法、且只有一个定义fn F(); fn F(x: i32);—— 不能合并因为参数列表不同会触发诊断。提案总览三条核心改动提案给出三项核心结论新增extern声明extern用于标记实体由不同库定义的前向声明定义实体的库必须在api文件中将该实体声明为 public定义库本身将实体声明为extern是非法的extern只能用于不包含该实体定义的库中的声明在修饰符序列中extern紧跟访问控制关键字之后、其他关键字之前实体在一个文件中被声明为extern则整个文件内都必须以extern方式使用它且在该extern声明之前实体完全不可被使用即使存在导入的声明——这保证了增删声明时的重构安全若一个库在api或impl中以非extern方式声明了某实体则该库内其他地方将其声明为extern均为非法。前向声明只能出现一次且必须在定义之前同一实体在给定文件内至多前向声明一次前向声明只允许出现在定义之前。修饰符关键字的合并规则按实体类型逐个裁定详见下文修饰符关键字一节。extern关键字详解extern是一个新的修饰符关键字加在前向声明上表示该实体不由声明它的库定义。使用extern声明实体的库不能定义该实体只有定义实体的库可以省略extern而省略extern就意味着必须提供定义。extern声明形成的实体没有定义、也没有存储。例如extern fn—— 形成一个可以被调用的函数extern class—— 形成一个不完整类型incomplete typeextern interface—— 形成一个未定义的接口extern var或extern let—— 绑定名字但不分配存储禁止初始化器。extern关键字不能用在仅有声明语法、没有存储的实体上如alias、namespace同时它只对命名空间作用域namespace-scoped的名字合法在类型作用域内非法例如class Foo { extern fn Member(); }是不允许的。在声明修饰符中extern紧跟访问控制关键字之后、其他关键字之前例如private extern other modifiers class B;。在当前设计下当extern出现在声明上时只有访问修饰符与之合法搭配详见修饰符关键字一节。编译器中的extern关键字extern在 Carbon 工具链的词法层有明确登记见 toolchain/lex/token_kind.def 中的CARBON_KEYWORD_TOKEN(Extern, extern)。在语义检查阶段编译器多处维护实体的is_extern标记例如 toolchain/check/cpp/import.cpp、toolchain/check/function.cpp、toolchain/check/global_init.cpp 等位置均会以is_extern false构建实体信息声明名栈toolchain/check/decl_name_stack.h在处理声明时也会接收is_extern参数。这印证了extern是贯穿词法、语法与语义分析的正式语言特性而非纯文档约定。声明何时被允许五条规则判断一个声明是否被允许需要同时满足以下三条基本原则再辅以若干细化规则声明应当总是新增信息——定义之后不允许再出现声明一个实体只能由一个库以非extern方式声明支持在不影响客户端库编译的前提下将声明在已被导入的api文件之间移动。规则一前向声明不得跟在声明之后在一个文件中前向声明绝不能跟在同一实体的前向声明或定义之后。例如class A { ... } // Invalid: Disallowed after the definition. class A; class B; // Invalid: Disallowed due to repetition. class B; class C; // Valid: Allowed because the definition is added. class C { ... }规则二文件必须要么使用导入的声明要么声明自己的如果一个实体的声明或定义被导入到某文件该文件必须二选一要么使用导入的版本要么声明自己的版本不能两者兼用。示例如下package Foo library a api; class C { ... }package Foo library b api; import library a; extern class C; // Valid: Uses the incomplete type of the extern declaration. fn Foo(c: C*);package Foo library c api; import library a; // Valid: Uses the complete type of the imported definition. fn Foo(c: C);package Foo library d api; import library a; fn Foo(c: C); // Invalid: Foo used the imported C, so an extern declaration of C is now // invalid. extern class C;规则三库不能既定义实体又将其声明为extern如果某个库的impl定义了实体则其api不得以extern方式声明它package Wiz library a api; extern class C;package Wiz library a impl; // Invalid: The api file declared C as extern. class C { ... }反过来api中可以存在extern声明而impl导入并使用该实体的定义——因为impl文件并没有声明该实体所以二者并不冲突。规则四impl文件中的前向声明必须包含定义在impl文件中如果前向声明了某实体则必须同时在该文件提供定义。对于拥有多个impl文件的库这意味着在一个impl文件中使用定义于另一个impl文件的实体需要在api文件中提供可能是private的前向声明。此处不能使用extern声明因为该库本身定义了实体。这条规则让 Carbon 能够在编译期诊断impl中声明了实体却没有本地定义的问题。注意api中声明的实体除非编译器被告知已看到全部impl文件否则可能无法得到编译期诊断。package Bar library a api; class C; class D { ... }package Bar library a impl; // Invalid: Missing a definition in the impl file, but if one were added, then // this would be valid. class C; // Invalid: The api defines D. As a consequence, there is no way to make // this forward declaration valid. class D;这条规则并不禁止impl提供前向声明——当它同时提供定义时仍然允许这可用于解开依赖环。例如api中声明class D;impl中通过本地前向声明配合定义来打破两个类之间的循环依赖package Bar library a api; class D;package Bar library a impl; class D; class E { fn Fself: Self { ... } } class D { fn Gself: Self { ... } }这里impl不能直接使用api中的导入前向声明受规则二限制因此若没有class D;F的定义将不合法。规则五类型作用域内可以同时存在前向声明与定义前向声明与定义的组合在类型作用域内是允许的class C { class D; fn F() - D; class D { fn G() - Self { return C.F(); } var x: i32; } fn F() - D { return {.x 42}; } }这是必要的因为类型体type body不会像函数体那样被自动移到类外处理。extern声明与extern impl的交互非extern的impl声明不得在其类型结构中使用extern类型。考虑两个库一个定义A并将B声明为extern另一个定义B并将A声明为extern。这种情况下两个库都不应能定义同时涉及A和B的impl否则两个库都可能给出定义造成冲突。涉及extern类型的impl查找当涉及extern类型的impl查找命中一个非final的参数化impl时查找成功但该接口关联实体associated entities的取值全部未知。原因是可能存在另一个更特化的impl恰好适用但当前不可见这与受约束泛型中发生的情况一致。library a api; extern class C; extern class D(T:! type); extern impl forall [T:! type] D(T) as I where .Result i32;在上例中D(C)实现了I但.Result未知——因为它可能不是i32。修饰符关键字的合并规则提案对前向声明与定义之间的各类修饰符给出了明确裁定extern只对前向声明合法规则如前所述。extendextend impl只出现在类体中的声明上无论是前向声明还是定义。类、impl、接口修饰符abstract、base、final只存在于定义上不在前向声明上。例如base加在class C { ... }上是合法的但加在class C;上被禁止。函数修饰符impl、virtual、default、abstract、final必须在前向声明与定义之间完全匹配。这只影响类型作用域的名字因为它们在命名空间名字上非法abstract因为没有定义在此无实际影响。访问修饰符private、protected必须匹配但存在一个例外——extern名字在真实名字为 public 时可以被声明为private这允许一个库前向声明另一个库的类型而不让客户端依赖它的前向声明合并时更公开的声明优先隐藏private extern声明。该规则同时影响类型作用域与命名空间作用域的名字。一个值得注意的统一模式是定义上的修饰符通常是声明上修饰符的超集extern是例外。看声明永远只能得到不完整视图而看定义可以得到完整视图。设计动机提案与项目目标的对齐提案在 Rationale 中将其设计决策与 Carbon 项目目标逐一对应软件与语言演进docs/project/goals.md#software-and-language-evolution支持在不影响客户端编译的前提下把类在不同库之间移动。允许在导入非extern声明的同时保留冗余extern声明从而支持向已导入库中添加类要求使用本地extern声明则防止了可能阻碍从导入库中移除类的意外使用。只要求extern声明携带影响调用约定的关键字意味着大多数情况下可以在定义库中增删关键字而不破坏其他库的extern声明。易于阅读、理解与编写显式标注extern帮助读者识别库为了规避依赖环而使用外部类型的场景禁止冗余前向声明消除了混淆来源类型作用域函数要求重复关键字则提升了可读性。务实的安全与测试机制要求extern声明被清晰标记提升诊断 ODR 违规的能力帮助开发者发现微妙的正确性问题。快速可扩展的开发extern声明被视为支持库独立编译separate compilation的关键进而支撑编译规模的扩展。与现有 C 代码的互操作与迁移extern的选择与 C 保持一致语义相近但略有不同。倾向于只提供一种做事方式原则docs/project/principles/为关键字该放在前向声明还是定义上设定明确要求而非让位置可选用使得开发者可以通过看到或没看到哪些关键字来做出判断。备选方案分析为什么这样设计提案详细记录了多个被否决或搁置的备选方案理解这些权衡有助于把握规则背后的意图。其他修饰符关键字合并方案设计团队权衡了以下因素修饰符出现位置的一致性很有价值。若给一个有独立定义的实体添加关键字可能需要同时修改前向声明与定义不允许添加在不必要的位置。例如base只能加在定义上。虽然可以让关键字在不影响语义的前提下可选但设计者更希望关键字的有无承载明确含义——若允许base class C;相邻的class D;很容易被误读为D 不是 base 类而实际上它只表示D 可能是也可能不是 base 类。访问控制需要一定的一致性以保证前向声明的使用者重构后仍可使用定义。若访问控制超出 public 与private的范围extern规则需要更细化的设计例如当前语言尚没有的 package-private 类型不应能通过extern声明被公开。对类型而言声明上使用最小化修饰符被禁止的abstract、base、final、default对使用没有影响前向声明的类型不完整强制要求它们只会泄露实现细节并制造额外负担也与 C 不太一致。extern是特例因为它的存在本身是语义的内在部分。对类型作用域成员而言选择在声明与定义之间重复修饰符例如class A { private class B; } // private is required here. private class A.B { ... }这更强调函数声明可复制粘贴的价值所有参数也必须一起复制C 中static仅出现在声明上的做法被视为摩擦而非收益。virtual这类影响调用约定的修饰符必须出现在首个声明上。代价是类名被插入到类外定义的中段而非靠近开头。另一种被讨论的路径是对类型成员函数在类外定义跟随前向声明时禁止大多数修饰符——这能最大化复制粘贴能力理想情况下fn之前的内容全部可省略但会损害定义的可理解性。最终提案选择更冗长但更清晰的方案。还有一种思路是允许灵活选择关键字放置位置如函数定义上的关键字必须是声明上关键字的子集但这会损害可读性同一文件中的两个函数声明相似定义却带不同关键字会暗示并不存在的行为差异。出于只提供一种方式原则提案选择规定性更强的做法。不要extern关键字如果没有extern声明将不提供任何该库是否包含定义的线索。面对不同api文件中的两个前向声明要么都有定义、要么都没有定义有时只能在链接期且依赖一些技巧才能发现。加入extern后可以在编译期就评估更多案例并给出警告同时给读者提供实体是否预期在本库稍后声明的提示。提案用一个例子说明库 b 的api导入库 a 并写下class C {}而库 a 的api只有class C;。没有extern时这段代码预期能编译问题留给链接器加入extern后处理库 b 时就能发现与库 a 的class C;前向声明之间的冲突。结论是extern关键字主要是为了诊断与可读性而引入它并不从根本上改变可诊断问题的总量而是让一部分原本属于链接期诊断或完全漏检的问题提前到编译期。更宽松的声明限制提案选择对声明施加严格限制首要目的是避免诸如定义之后再写一个无效声明这类令人困惑的代码class C { ... } // This declaration has no effect. class C;但宽松方案还允许这样的代码package Foo library a api; class C { ... }package Foo library b api; import library a; fn F(c: C) { ... } extern class C; fn G(c: C*) { ... }这里的歧义在于G看到的是extern带来的不完整类型还是被导入的完整定义导入库 b 的第三方看到的C又是不完整还是完整为消除这些可理解性问题提案选择了更严格、同时禁止两种写法的方案。extern的命名除extern外还考虑过external。extern在 C 中隐含外部链接external linkage语义选它主要是为了与 C 保持有限的一致性。让extern默认私有曾考虑让extern自带相当于private的访问控制含义并引入export关键字来显式导出符号也可能提供export import语法以再导出导入库的全部符号。提案从三点论证了否决理由语义一致性extern声明若与其他声明访问控制不同会形成另一套可见性模型可能与external含义不符直觉export与 C 的export关键字呼应可能让开发者误以为其他语义也同于 C。与更多访问控制特性的交互未来可能引入比 public/private 更细粒度的访问控制如类似 Javapackage的 package-private。表格对比了三种默认可见性下的写法默认可见性Public提案方案Private备选方案Publicextern class C;export extern class C;库私有private extern class C;extern class C;包私有假设package extern class C;export package extern class C;提案还以 gtest 的 internal header 目录为例说明 package-private 可见性的潜在用途。public extern 的风险extern fn可被调用存在内部使用的extern函数被意外依赖的风险可通过要求extern的访问控制不宽于原符号来缓解两者同时可见时可校验。extern class是不完整类型不能被实例化但可声明指针和引用若extern class默认私有并不能阻止其使用如auto捕获返回指针。综合权衡后提案采用常规访问控制语义并保留后续根据实际语义演进重新审视的可能性。不透明类型Opaque types省略extern意味着库中必须有定义。若将来需要由库拥有、没有定义的不透明类型可能的解法是增加表示不透明类型的修饰符关键字。就目前而言在库的impl文件中给出空定义可达到类似效果package Foo library a api; // An opaque type which can be imported by other libraries. class C;package Foo library a impl; // An empty definition. This could be in its own file, or at the end after logic, // to prevent misuse. class C {}api的使用者无法提供定义。提案当前要求定义必须存在这一选择可能根据使用场景重新审视。要求库提供自己的extern声明曾有人提议限制库必须通过单独的extern文件类似api/impl或在api文件中附加标记自动生成extern子集来提供extern声明。其优点包括集中管理extern声明所有权简化重构当前计划要求extern声明与定义库的声明保持一致包括参数名等细节改动一处就需要原子地改动所有声明而限制作用域能减轻这种原子重构负担降低 C 前向声明迁移的复杂度。缺点则包括使希望使用extern声明的库难以对单个声明做最小化导入extern文件的导入集将是这些声明的导入集的超集不支持 C 中可能出现的使用场景如class C { ... }; extern fn F(c: C);同一文件中extern依赖已定义实体——虽然可以通过重构移动实体到其他库、让extern声明只用extern声明、或用泛型编程制造间接层解决但这些重构可能阻碍采用。目前评估认为缺点大于优点如果未来积累更多实际用法可能重新审视但在只提供一种方式原则下若非带来实质价值应谨慎提供第二种extern语法。允许跨包extern声明C 没有包边界跨包extern在 C 中实际存在放弃支持会制造迁移障碍。但设计团队强烈倾向于限制跨包声明以减少重构成本跨包声明要求特定名字不能改变其声明类别class必须保持class不能变成alias参数函数或泛型必须保持不变甚至不允许隐式转换。包边界在平衡重构成本方面发挥着重要作用。附录C 前向声明的迁移路径提案附录并未确定具体迁移方案但给出了迁移时的思考框架。预期迁移一个前向声明需要先识别定义该实体的 Carbon 库然后依据库与包边界调整前向声明若在 Carbon 中该前向声明被禁止可能需要删除若前向声明与定义库相同无需extern若在不同库但同一包内添加extern若在不同包内前向声明必须删除取而代之有两种按启发式选择的方案其一添加对真实定义的依赖当定义库依赖复杂时可能不可行其二在另一包中添加提供必要extern声明的库当该包不属于被迁移方时可能不可行。若前向声明的代码在 C 中需要保留 C 侧的前向声明可能的做法包括为 C 代码提供文件内前向声明的 Carbon 语法如extern cpp declaration或创建提供前向声明的小型 C 头文件并依赖它。修正参数名的有意义的差异例如将前向声明的参数名更新为与定义一致。修正修饰符关键字的差异例如将函数前向声明的修饰符补充到定义上。后续演进从提案到当前设计需要特别说明的是p003762-merging-forward-declarations 是 Carbon 前向声明设计历程中的里程碑提案其后的设计在此基础上继续演进提案 p003763-matching-redeclarations 进一步细化了声明匹配syntactic matching规则提案 p003980-singular-extern-declarations 实质上重写了extern特性其 Versus proposal #3762 一节明确写道extern特性的任何部分都不应假定仍然适用实体最多可有三个声明——可选的非持有方extern library owning_library声明必须位于定义库之外且定义库的api文件必须导入它并同时包含一个声明、可选的持有方前向声明必须先于定义api文件视为位于impl文件之前、以及必需的持有方定义并统一了extern与非extern类型的一致性type coherency。当前设计文档 docs/design/declaring_entities.md 汇总了两者的成果extern在持有方声明上限制对定义的访问必须显式导入才能获得完整类型在非持有方声明上以extern library owning_library形式允许在不依赖定义库的前提下引用实体extern仍只对命名空间作用域实体合法class C { extern fn F(); }非法对间接导入extern实体的定义不可见直接导入定义即可解决。该文档的 Alternatives considered 一节直接链接回本提案的各个备选方案小节可见 p003762 的权衡分析仍是后续设计的重要参考。对于希望跟踪实现现状的读者建议同时阅读 docs/design/functions.md函数前向声明与extern fn的使用、docs/design/classes.md#forward-declaration类前向声明、docs/design/README.md声明、定义与作用域总览以及 toolchain/lex/token_kind.defextern词法关键字登记从而从设计文档到工具链实现形成完整闭环。【免费下载链接】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），仅供参考
