文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载本篇围绕 Rust RFCs 仓库中的 RFC 2526Feature Nameconst_wildcard系统讲解「允许把常量赋给_通配符」这一语言特性的设计动机、语法变更、类型检查规则与实战价值。读者读完后将理解const _: TYPE VALUE与let _ VALUE的语义对应关系掌握其在自定义 derive 的 trait 约束断言、编译期静态断言等场景中的正确用法并能从语法层与类型检查层的角度看懂该 RFC 的完整设计。RFC 概览让常量可以匿名RFC 2526 于 2018-08-18 发起对应 Rust 跟踪 Issuerust-lang/rust#54912。它的提案非常简洁允许将常量声明中的标识符位置替换为下划线_即原本合法的const NAME: TYPE VALUE;现在也允许写作const _: TYPE VALUE;其语义与let _ VALUE完全类似不会引入任何新的绑定binding但右侧表达式仍会像普通常量一样在编译期被求值。这意味着const _可以在同一作用域内被重复书写多次而不会与任何既有标识符冲突。在仓库的 RFC 模板 中可以看到Rust 的 RFC 提案通常按 Summary、Motivation、Guide-level explanation、Reference-level explanation、Drawbacks、Rationale and alternatives、Prior art、Unresolved questions 等章节组织本文即按照 RFC 2526 自身的这一骨架展开并在仓库后续 RFC 中寻找该特性的实际印证。核心动机编译期类型检查与标识符冲突之痛Rust 中有一个被广泛使用的技巧通过让一段代码能否通过类型检查来在编译期验证某个类型是否满足某组 trait 约束。RFC 的 Motivation 给出了一个典型例子const _FOO: () { use std::marker::PhantomData; struct ImplementsMyTraitT: MyTrait(PhantomDataT); let _ ImplementsMyTrait::MyType(PhantomData); // type checking error if MyType: !MyTrait () };这段代码的运作原理是ImplementsMyTraitT是一个持有PhantomDataT的新结构体其定义本身对T: MyTrait有隐式约束结构体字段PhantomDataT要求T: Sized而T: MyTrait是作为泛型参数的 bound 被检查的——实际上这里的关键是ImplementsMyTrait::MyType这个实例化要求MyType: MyTrait成立整个const的初始化表达式在编译期被求值因此一旦MyType不实现MyTrait编译器就会直接报错const _FOO本身的值单元类型()并不重要这种模式常被用在自定义 derive过程宏生成的代码中用来对输入类型施加必须实现某 trait的静态断言。但该模式存在一个明显痛点必须为这个常量起一个独一无二的名字上例中的_FOO。无论选用什么样的标识符都存在与用户既有代码中的名字撞车的可能性——例如用户恰好也声明了const _FOO: () ...就会引发重定义错误。而如果const _: () { ... }合法这个烦恼就彻底消失了_不产生绑定可以无限次重复书写互不干扰。指南级解释像let _一样对待const _从使用者的视角看RFC 用一句话概括了新语义允许在定义常量时把名字写成_。与let _一样它不会引入任何新的绑定但仍会像其他常量一样在编译期对右值rvalue求值。也就是说程序员可以这样理解const _let _ VALUE在运行时求值VALUE结果被丢弃不创建变量const _: T VALUE在编译期求值VALUE结果被丢弃不创建具名常量但求值过程包括其中的类型检查、常量运算、assert!等照常发生。因此const _最自然的用途就是我只想借用编译期的求值副作用类型检查、静态断言而不关心产物叫什么名字。参考级解释语法变更与类型检查规则RFC 在参考级解释中给出了两处具体改动。语法Grammar变更item_const的产生式从item_const : CONST ident : ty expr ; ;改为item_const : CONST (ident | UNDERSCORE) : ty expr ; ;即常量项的名字位置从「必须是标识符ident」放宽为「标识符或下划线UNDERSCORE」。注意这里的_是词法层面的 UNDERSCORE 记号而不是标识符——这决定了它不会进入任何命名空间、不会与用户代码中的名字产生解析冲突。语法形式与let _ ...中_的处理逻辑一脉相承。类型检查Type checking规则RFC 对类型检查阶段明确区分了两种场景关联常量associatedconst即impl块内的常量项_不允许作为项名出现。理由很直接——关联常量属于 trait / impl 的公开接口必须有名字才能被引用匿名会让接口无法表达非关联常量impl块之外的顶层/模块级const项_被允许作为项名。当遇到_时编译器会将其替换为一个新生成的、全局唯一的标识符再走常规的常量检查流程。替换为新鲜生成的唯一标识符这一设计至关重要它保证了const _在内部处理上与普通具名常量完全等价相同的求值、相同的检查、相同的错误信息同时又因为名字是编译器生成的、用户无法预知也无法与之冲突从而实现了可无限重复声明。实战场景一自定义 derive 中的 trait 约束断言RFC 在 Rationale 中明确指出const _最想服务的一类用户是自定义 derive过程宏的编写者。过程宏展开后会生成一段普通 Rust 代码通常位于用户 crate 的某个模块中。如果 derive 需要保证输入类型MyType必须实现MyTrait宏作者可以生成const _: () { use std::marker::PhantomData; struct ImplementsMyTraitT: MyTrait(PhantomDataT); let _ ImplementsMyTrait::MyType(PhantomData); () };在没有const _之前宏必须生成一个具名常量例如const _DERIVE_MY_TRAIT_ASSERT: () ...。一旦用户在自己的代码里也定义了同名的常量宏展开结果就会与用户代码冲突导致编译失败——这种宏生成的内部名字泄露到用户命名空间的问题正是过程宏生态中最令人头疼的卫生性hygiene难题之一。const _把该位置变成真正的匿名槽位后宏无论被展开多少次、无论用户写了多少同名标识符都不会再发生名字碰撞。实战场景二编译期静态断言RFC 的 Rationale 还点出了另一个重要应用编译期断言宏。static_assertionscrate 中的const_assert!等宏此前只能在局部作用域scope内使用——因为它们需要借助一个let绑定或要求用户为承载表达式的外层函数指定一个作用域内唯一的名字才能工作。const _为这类宏提供了一个干净得多的落点断言表达式可以整体放进一个匿名的编译期常量里既不需要作用域也不需要用户绞尽脑汁起名字。这种用法在 Rust 生态中已经成为惯例。本仓库中就有实际例证在 RFC 3983bf16 浮点类型 的参考级解释中作者用const _来验证结构体尺寸// Ensure that the size of this struct is 2 const _: () assert!(size_of::f16b() 2);这里const _: () assert!(...)利用编译期常量求值执行assert!若size_of::f16b()不为 2编译直接失败若通过则断言常量被丢弃不留任何具名符号。这正是 RFC 2526 所设想能力的直接落地——从语法层面看它与 RFC 2526 的item_const新产生式完全一致CONST UNDERSCORE : ty expr ;其中ty为()expr为assert!宏调用。权衡与代价规则的复杂性RFC 自己也坦诚列出了 Drawbacks常量标识符的规则变得更复杂语言中新增了一个名字可以不是标识符的特殊位置编译器处理常量的逻辑也要随之增加分支引入了关联常量与非关联常量的区分impl内的const _非法、impl外的const _合法这意味着语言层面新增了一条需要向用户解释的规则边界。这一代价是设计上主动接受的关联常量作为接口的一部分必须具名而非关联常量作为编译期求值的副作用载体则可以匿名二者需求本质不同。备选方案与设计取舍RFC 的 Alternatives 章节讨论了三条其他可行路径并解释了为何不选为过程宏提供获取全局唯一标识符的 API即由编译器/库提供gensym之类的机制让宏自行生成不会冲突的名字。RFC 认为这把负担转嫁给了每个宏作者且无法解决用户手写const _FOO类代码时的碰撞问题——const _把问题在语言层面一次性解决支持匿名模块mod { ... }或mod _ { ... }模块可以容纳任意数量的具名常量但匿名模块本身仍是语言层面的新语法而且对仅在模块里塞一个断言常量这种需求而言过于笨重支持匿名的顶层函数fn _() { ... }函数体同样能承载编译期求值但函数的语义可被调用、可参与泛型等与纯求值丢弃的意图并不匹配且同样需要引入新的语法规则。综合来看const _是三者中改动最小、语义最贴合需求的方案它只放宽了item_const产生式中一个记号的选择范围。既有先例Go 的匿名常量与顶层变量RFC 的 Prior art 指出Go 语言早已允许类似的匿名常量语法const _ ...更常用的是它的顶层变量形式——Go 的包级变量在main运行之前的初始化阶段就会被求值var _ fmt.Formatter floatZero // *Float must implement fmt.Formatter这是 Go 标准库中真实存在的写法把floatZero赋值给实现了fmt.Formatter接口的类型通过类型检查来静态保证*Float实现了fmt.Formatter接口随后结果被_丢弃。这与 Rust 中const _: () { ... }的用法在精神上完全一致——用赋值/初始化的类型检查换取编译期约束验证。两者也存在本质差异Go 的var _是运行时初始化虽然发生在main之前而 Rust 的const _是纯编译期求值不会在最终产物中保留任何运行时初始化逻辑这也让 Rust 的版本更适合做零开销的编译期断言。后续演进与仓库印证RFC 在 Rationale 中留了一个明确的演进方向未来很可能会支持类似let绑定那样完全通用的模式匹配例如const (a, b): (u8, u8) (1, 1)从而让const _不再是语言中的一个特例。不过 RFC 明确表态这种设计的细节留给未来的 RFC。值得关注的是本仓库中后续的 RFC 2920inline const 在讨论命名问题时明确提到了 RFC 2526 引入的语法RalfJungprefers anonymousconst.scottmcmmentioned in Zulip that this could be confused with theconst _: () ...;syntax introduced in RFC 2526. The reference refers to these as unnamed constants.这段话包含两个重要信息const _: () ...;语法已经进入语言并被官方 reference 文档称为 unnamed constants匿名/未命名常量——说明 RFC 2526 的设计最终被采纳并实现后续语言设计inline const在术语上刻意与它区分避免混淆说明const _已成为 Rust 常量体系中的稳定组成部分。再结合 RFC 3983 中const _: () assert!(size_of::f16b() 2);的实际用法可以看到这条语法在仓库后续 RFC 的代码示例中已被当作常规工具使用。总结RFC 2526 用一处极小的语法放宽item_const的名字位置允许出现_解决了过程宏生态中长期存在的命名冲突难题const _: TYPE VALUE不引入绑定、仍在编译期求值、可以无限重复完美适配 trait 约束断言、编译期静态断言等只要副作用、不要名字的场景。其参考级解释给出了清晰的实现路径——非关联const遇到_时替换为编译器生成的唯一标识符而关联const因属于接口而不允许匿名。从 Go 的const _/var _先例到本仓库后续 RFC 中对 unnamed constants 的正式引用这一特性已经成为 Rust 编译期断言工具箱中不可或缺的一环。如果你想进一步阅读可深入本仓库的 RFC 2526 原文、对照 RFC 模板 理解 Rust RFC 的章节惯例并参考 RFC 2920 inline const 与 RFC 3983 bf16 中对该语法的后续使用。赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐Rust RFC 1685 深度解析废弃 trait 方法中的匿名参数anonymous parametersRust RFC 1685 深度解析废弃 trait 方法中的匿名参数anonymous parameters 导读 本文围绕本仓库Rust 官方 RF文档Rust 不安全指针规范化从 *T 到 *const T 的命名重命名与强制转换设计RFC 0068 深度解读Rust 不安全指针规范化从 T 到 const T 的命名重命名与强制转换设计RFC 0068 深度解读 导读 本文基于 Rust RFC 仓库中的 t文档Rust RFC 490 深度解析DST 类型参数语法从 Sized? T 到 T: ?Sized 的演变Rust RFC 490 深度解析DST 类型参数语法从 Sized? T 到 T: ?Sized 的演变 Rust 中「动态大小类型」dynamicall文档上一篇Pot-desktop打破语言障碍的桌面翻译工作流解决方案下一篇如何实现微信聊天记录的数据主权WeChatMsg本地化存储与智能分析完整方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载本篇围绕 Rust RFCs 仓库中的 RFC 2526Feature Nameconst_wildcard系统讲解「允许把常量赋给_通配符」这一语言特性的设计动机、语法变更、类型检查规则与实战价值。读者读完后将理解const _: TYPE VALUE与let _ VALUE的语义对应关系掌握其在自定义 derive 的 trait 约束断言、编译期静态断言等场景中的正确用法并能从语法层与类型检查层的角度看懂该 RFC 的完整设计。RFC 概览让常量可以匿名RFC 2526 于 2018-08-18 发起对应 Rust 跟踪 Issuerust-lang/rust#54912。它的提案非常简洁允许将常量声明中的标识符位置替换为下划线_即原本合法的const NAME: TYPE VALUE;现在也允许写作const _: TYPE VALUE;其语义与let _ VALUE完全类似不会引入任何新的绑定binding但右侧表达式仍会像普通常量一样在编译期被求值。这意味着const _可以在同一作用域内被重复书写多次而不会与任何既有标识符冲突。在仓库的 RFC 模板 中可以看到Rust 的 RFC 提案通常按 Summary、Motivation、Guide-level explanation、Reference-level explanation、Drawbacks、Rationale and alternatives、Prior art、Unresolved questions 等章节组织本文即按照 RFC 2526 自身的这一骨架展开并在仓库后续 RFC 中寻找该特性的实际印证。核心动机编译期类型检查与标识符冲突之痛Rust 中有一个被广泛使用的技巧通过让一段代码能否通过类型检查来在编译期验证某个类型是否满足某组 trait 约束。RFC 的 Motivation 给出了一个典型例子const _FOO: () { use std::marker::PhantomData; struct ImplementsMyTraitT: MyTrait(PhantomDataT); let _ ImplementsMyTrait::MyType(PhantomData); // type checking error if MyType: !MyTrait () };这段代码的运作原理是ImplementsMyTraitT是一个持有PhantomDataT的新结构体其定义本身对T: MyTrait有隐式约束结构体字段PhantomDataT要求T: Sized而T: MyTrait是作为泛型参数的 bound 被检查的——实际上这里的关键是ImplementsMyTrait::MyType这个实例化要求MyType: MyTrait成立整个const的初始化表达式在编译期被求值因此一旦MyType不实现MyTrait编译器就会直接报错const _FOO本身的值单元类型()并不重要这种模式常被用在自定义 derive过程宏生成的代码中用来对输入类型施加必须实现某 trait的静态断言。但该模式存在一个明显痛点必须为这个常量起一个独一无二的名字上例中的_FOO。无论选用什么样的标识符都存在与用户既有代码中的名字撞车的可能性——例如用户恰好也声明了const _FOO: () ...就会引发重定义错误。而如果const _: () { ... }合法这个烦恼就彻底消失了_不产生绑定可以无限次重复书写互不干扰。指南级解释像let _一样对待const _从使用者的视角看RFC 用一句话概括了新语义允许在定义常量时把名字写成_。与let _一样它不会引入任何新的绑定但仍会像其他常量一样在编译期对右值rvalue求值。也就是说程序员可以这样理解const _let _ VALUE在运行时求值VALUE结果被丢弃不创建变量const _: T VALUE在编译期求值VALUE结果被丢弃不创建具名常量但求值过程包括其中的类型检查、常量运算、assert!等照常发生。因此const _最自然的用途就是我只想借用编译期的求值副作用类型检查、静态断言而不关心产物叫什么名字。参考级解释语法变更与类型检查规则RFC 在参考级解释中给出了两处具体改动。语法Grammar变更item_const的产生式从item_const : CONST ident : ty expr ; ;改为item_const : CONST (ident | UNDERSCORE) : ty expr ; ;即常量项的名字位置从「必须是标识符ident」放宽为「标识符或下划线UNDERSCORE」。注意这里的_是词法层面的 UNDERSCORE 记号而不是标识符——这决定了它不会进入任何命名空间、不会与用户代码中的名字产生解析冲突。语法形式与let _ ...中_的处理逻辑一脉相承。类型检查Type checking规则RFC 对类型检查阶段明确区分了两种场景关联常量associatedconst即impl块内的常量项_不允许作为项名出现。理由很直接——关联常量属于 trait / impl 的公开接口必须有名字才能被引用匿名会让接口无法表达非关联常量impl块之外的顶层/模块级const项_被允许作为项名。当遇到_时编译器会将其替换为一个新生成的、全局唯一的标识符再走常规的常量检查流程。替换为新鲜生成的唯一标识符这一设计至关重要它保证了const _在内部处理上与普通具名常量完全等价相同的求值、相同的检查、相同的错误信息同时又因为名字是编译器生成的、用户无法预知也无法与之冲突从而实现了可无限重复声明。实战场景一自定义 derive 中的 trait 约束断言RFC 在 Rationale 中明确指出const _最想服务的一类用户是自定义 derive过程宏的编写者。过程宏展开后会生成一段普通 Rust 代码通常位于用户 crate 的某个模块中。如果 derive 需要保证输入类型MyType必须实现MyTrait宏作者可以生成const _: () { use std::marker::PhantomData; struct ImplementsMyTraitT: MyTrait(PhantomDataT); let _ ImplementsMyTrait::MyType(PhantomData); () };在没有const _之前宏必须生成一个具名常量例如const _DERIVE_MY_TRAIT_ASSERT: () ...。一旦用户在自己的代码里也定义了同名的常量宏展开结果就会与用户代码冲突导致编译失败——这种宏生成的内部名字泄露到用户命名空间的问题正是过程宏生态中最令人头疼的卫生性hygiene难题之一。const _把该位置变成真正的匿名槽位后宏无论被展开多少次、无论用户写了多少同名标识符都不会再发生名字碰撞。实战场景二编译期静态断言RFC 的 Rationale 还点出了另一个重要应用编译期断言宏。static_assertionscrate 中的const_assert!等宏此前只能在局部作用域scope内使用——因为它们需要借助一个let绑定或要求用户为承载表达式的外层函数指定一个作用域内唯一的名字才能工作。const _为这类宏提供了一个干净得多的落点断言表达式可以整体放进一个匿名的编译期常量里既不需要作用域也不需要用户绞尽脑汁起名字。这种用法在 Rust 生态中已经成为惯例。本仓库中就有实际例证在 RFC 3983bf16 浮点类型 的参考级解释中作者用const _来验证结构体尺寸// Ensure that the size of this struct is 2 const _: () assert!(size_of::f16b() 2);这里const _: () assert!(...)利用编译期常量求值执行assert!若size_of::f16b()不为 2编译直接失败若通过则断言常量被丢弃不留任何具名符号。这正是 RFC 2526 所设想能力的直接落地——从语法层面看它与 RFC 2526 的item_const新产生式完全一致CONST UNDERSCORE : ty expr ;其中ty为()expr为assert!宏调用。权衡与代价规则的复杂性RFC 自己也坦诚列出了 Drawbacks常量标识符的规则变得更复杂语言中新增了一个名字可以不是标识符的特殊位置编译器处理常量的逻辑也要随之增加分支引入了关联常量与非关联常量的区分impl内的const _非法、impl外的const _合法这意味着语言层面新增了一条需要向用户解释的规则边界。这一代价是设计上主动接受的关联常量作为接口的一部分必须具名而非关联常量作为编译期求值的副作用载体则可以匿名二者需求本质不同。备选方案与设计取舍RFC 的 Alternatives 章节讨论了三条其他可行路径并解释了为何不选为过程宏提供获取全局唯一标识符的 API即由编译器/库提供gensym之类的机制让宏自行生成不会冲突的名字。RFC 认为这把负担转嫁给了每个宏作者且无法解决用户手写const _FOO类代码时的碰撞问题——const _把问题在语言层面一次性解决支持匿名模块mod { ... }或mod _ { ... }模块可以容纳任意数量的具名常量但匿名模块本身仍是语言层面的新语法而且对仅在模块里塞一个断言常量这种需求而言过于笨重支持匿名的顶层函数fn _() { ... }函数体同样能承载编译期求值但函数的语义可被调用、可参与泛型等与纯求值丢弃的意图并不匹配且同样需要引入新的语法规则。综合来看const _是三者中改动最小、语义最贴合需求的方案它只放宽了item_const产生式中一个记号的选择范围。既有先例Go 的匿名常量与顶层变量RFC 的 Prior art 指出Go 语言早已允许类似的匿名常量语法const _ ...更常用的是它的顶层变量形式——Go 的包级变量在main运行之前的初始化阶段就会被求值var _ fmt.Formatter floatZero // *Float must implement fmt.Formatter这是 Go 标准库中真实存在的写法把floatZero赋值给实现了fmt.Formatter接口的类型通过类型检查来静态保证*Float实现了fmt.Formatter接口随后结果被_丢弃。这与 Rust 中const _: () { ... }的用法在精神上完全一致——用赋值/初始化的类型检查换取编译期约束验证。两者也存在本质差异Go 的var _是运行时初始化虽然发生在main之前而 Rust 的const _是纯编译期求值不会在最终产物中保留任何运行时初始化逻辑这也让 Rust 的版本更适合做零开销的编译期断言。后续演进与仓库印证RFC 在 Rationale 中留了一个明确的演进方向未来很可能会支持类似let绑定那样完全通用的模式匹配例如const (a, b): (u8, u8) (1, 1)从而让const _不再是语言中的一个特例。不过 RFC 明确表态这种设计的细节留给未来的 RFC。值得关注的是本仓库中后续的 RFC 2920inline const 在讨论命名问题时明确提到了 RFC 2526 引入的语法RalfJungprefers anonymousconst.scottmcmmentioned in Zulip that this could be confused with theconst _: () ...;syntax introduced in RFC 2526. The reference refers to these as unnamed constants.这段话包含两个重要信息const _: () ...;语法已经进入语言并被官方 reference 文档称为 unnamed constants匿名/未命名常量——说明 RFC 2526 的设计最终被采纳并实现后续语言设计inline const在术语上刻意与它区分避免混淆说明const _已成为 Rust 常量体系中的稳定组成部分。再结合 RFC 3983 中const _: () assert!(size_of::f16b() 2);的实际用法可以看到这条语法在仓库后续 RFC 的代码示例中已被当作常规工具使用。总结RFC 2526 用一处极小的语法放宽item_const的名字位置允许出现_解决了过程宏生态中长期存在的命名冲突难题const _: TYPE VALUE不引入绑定、仍在编译期求值、可以无限重复完美适配 trait 约束断言、编译期静态断言等只要副作用、不要名字的场景。其参考级解释给出了清晰的实现路径——非关联const遇到_时替换为编译器生成的唯一标识符而关联const因属于接口而不允许匿名。从 Go 的const _/var _先例到本仓库后续 RFC 中对 unnamed constants 的正式引用这一特性已经成为 Rust 编译期断言工具箱中不可或缺的一环。如果你想进一步阅读可深入本仓库的 RFC 2526 原文、对照 RFC 模板 理解 Rust RFC 的章节惯例并参考 RFC 2920 inline const 与 RFC 3983 bf16 中对该语法的后续使用。赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐Rust RFC 1685 深度解析废弃 trait 方法中的匿名参数anonymous parametersRust RFC 1685 深度解析废弃 trait 方法中的匿名参数anonymous parameters 导读 本文围绕本仓库Rust 官方 RF文档Rust 不安全指针规范化从 *T 到 *const T 的命名重命名与强制转换设计RFC 0068 深度解读Rust 不安全指针规范化从 T 到 const T 的命名重命名与强制转换设计RFC 0068 深度解读 导读 本文基于 Rust RFC 仓库中的 t文档Rust RFC 490 深度解析DST 类型参数语法从 Sized? T 到 T: ?Sized 的演变Rust RFC 490 深度解析DST 类型参数语法从 Sized? T 到 T: ?Sized 的演变 Rust 中「动态大小类型」dynamicall文档上一篇Pot-desktop打破语言障碍的桌面翻译工作流解决方案下一篇如何实现微信聊天记录的数据主权WeChatMsg本地化存储与智能分析完整方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
