文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载Rust 的模式pattern语法中存在一个长期的特殊情况..虽然可以在元组、切片、结构体等“列表式”模式中表示“剩余部分”却始终只是某些模式内部的语法片段而非一个独立的模式。RFC 2707dotdot_patterns正式把..提升为一种完整的模式pattern从而简化了模式文法、并让pat宏匹配器可以直接接受..。读完本文你将理解这一改动的前因后果、掌握..作为模式后的合法位置与语义限制并能在日常模式匹配与声明式宏编写中准确运用新语法。RFC 2707 在 Rust 模式演进中的位置本 RFC 的正式全称是dotdot_patterns由 rust-lang/rfcs 仓库收录于 text/2707-dotdot-patterns.md其对应的实现跟踪 Issue 为 rust-lang/rust#62254。它是此前两项工作的直接延续RFC 1492dotdot_in_patterns最早把..的使用范围从 slice 模式扩展到元组模式与元组结构体模式允许V(x, ..)、(.., z)等写法RFC 2359subslice pattern syntax为 slice 模式引入BINDING ..子切片绑定语法例如let [x, y .., z] [1, 2, 3, 4]但明确声明..与BINDING ..都不是完整模式因此不被pat宏匹配器接受。RFC 2359 在结尾的 “Future possibilities” 一节中已经预告未来可以把..变成在语法上被任何模式位置接受、但在语义上仅限 slice 与 tuple 模式的完整模式。RFC 2707 正是把这个预告落地的方案它直接引用了 RFC 2359 作为前置工作Prior art。Summary把语法片段提升为模式RFC 2707 的核心主张只有一句话Make..a pattern rather than a syntactic fragment of some other patterns.即将..从“其他某些模式的语法片段”改造为“一个独立的模式”。这一改变带来两个直接收益简化模式文法不再需要为元组、元组结构体、slice 模式各自定义“允许..出现”的特殊产生式简化宏中的使用pat宏匹配器从此可以直接匹配..以及包含..的复杂模式。在声明式宏macro_rules!中pat片段fragment此前无法捕获..导致任何依赖模式参数转发..的宏都无法编写。RFC 2707 之后pat匹配器可以直接接受..和ref x ..这样的模式。Guide-level..变成模式后的三个可见变化RFC 以面向使用者的视角列出了三个可观察的变化。变化一pat宏匹配器接受....成为模式后pat宏匹配器现在可以接受..以及任何包含..的复杂模式例如ref x ..。这意味着你可以写出类似下面的宏macro_rules! check_pattern { ($pat:pat) { /* 对 $pat 进行处理 */ }; } // 调用时可以直接传入 .. 或包含 .. 的模式 check_pattern!(..); check_pattern!(ref tail ..);在声明式宏体系里pat是少数几个“语法上收窄”的片段类型此前它无法承载..这构成了模式宏pattern macros编写中的经典痛点本 RFC 的改动从根源上解除了这一限制。变化二..之后允许尾随逗号在元组结构体、元组或 slice 模式中..之后现在允许出现一个尾随逗号trailing commaVariant(a, b, ..,) // OK注意在 RFC 2707 之前按照 RFC 1492 的约定..出现在最后位置时是不允许尾随逗号的“Trailing comma is not allowed after..in the last position by analogy with existing slice and struct patterns”。RFC 2707 通过把..作为普通模式来统一处理顺带接受..,这种写法与 Rust 其他地方“允许尾随逗号”的风格保持一致。变化三cfg(FALSE)下会接受一些“无意义”的代码由于cfg(FALSE)等条件下不会执行完整的语义检查一些语义上无意义的模式现在可以在语法层面被接受#[cfg(FALSE)] Tuple(.., a, ..) // OK不过这只发生在语义检查被跳过的编译路径上在正常编译路径中下面的代码仍然会被拒绝。Reference-level新的文法产生式与语义规则文法扩展模式文法新增一条产生式PAT ..原来那些“专门允许..出现在元组结构体、元组和 slice 模式中”的特殊产生式都被这条新产生式吸收并移除。换句话说..不再是散落在各个模式文法里的特例而是文法层面的一等公民。语义上可接受的位置从语义上讲..模式只允许出现在以下四种“列表式”模式中且BINDING ..是它的带绑定形式紧邻在元组结构体/枚举变体模式内部Tuple(PAT, .., PAT)紧邻在元组模式内部(PAT, .., PAT)紧邻在 slice 模式内部[PAT, .., PAT]紧邻在 slice 模式内部的绑定模式中[PAT, BINDING .., PAT]超出这些位置的任何使用都会产生错误let .. 10; // 语义错误.. 不属于任何“列表式”模式 let Option(.., ..) 11; // 语义错误同一个“列表式”模式中不允许出现多个 ..两条错误规则RFC 明确了两个语义错误判定位置错误..或BINDING ..被用在上述四个位置之外数量错误同一个元组结构体 / 元组 / slice 模式内部出现超过一个..或BINDING ..。例如(1, .., ..)或[x .., ..]都会因第二条规则被拒绝。两个值得注意的特例(..)仍然是元组模式出于向后兼容考虑(..)被继续解析为一个元组模式而不是“括号包裹的..模式”。这是本 RFC 中明确写出的兼容性决策。struct 模式中的..不是模式Struct { field1: PAT, field2, .. }这里的..依然只是 struct 模式语法的一个片段而不是一个独立的模式。也就是说本 RFC 的改动并不触及 struct 模式struct 模式的..表示“其余所有字段”本质上没有可绑定、可嵌套的子模式语义因此被明确排除在本次改造之外。与前置 RFC 2359 的关系子切片绑定的语法来源RFC 2707 中的第四个合法位置[PAT, BINDING .., PAT]直接继承了 RFC 2359 确立的语法。RFC 2359 引入了SUBSLICE .. | BINDING ..这一片段并配套给出了完整的绑定语义// 绑定子数组 let [x, y .., z] [1, 2, 3, 4]; // y: [i32; 2] [2, 3] // 绑定子切片按引用 let [x, y .., z]: [u8] [1, 2, 3, 4]; // y: [i32] [2, 3]RFC 2359 还定义了..在默认绑定模式default binding modes下的行为..被视为“非引用模式”当用它匹配某个引用或可变引用的 slice/数组的子区间时会把绑定模式切换为ref或ref mut而直接按值绑定非 Copy 的[u8]则会报“cannot move out of type[u8]”的错误。这些语义在 RFC 2707 中继续有效只是把BINDING ..的语法地位从“slice 模式片段”升级为了“完整模式”。两者的差异恰好可以用一句话概括RFC 2359 让..在 slice 模式中变得强大支持绑定RFC 2707 则让..在语法上变得普通成为完整模式从而让宏系统也能感知它。Drawbackscfg(FALSE)下接受更多无意义代码RFC 承认的缺点只有一个语义检查被跳过的场景如cfg(FALSE)下编译器会接受更多无意义的代码。由于..现在是语法合法的模式Tuple(.., a, ..)这类代码在cfg(FALSE)下能够通过编译尽管它在语义上毫无意义。这是一种“语法更宽松、语义检查兜底”的设计权衡——代价是在条件编译的死代码路径上错误不再那么早暴露。Rationale、Prior art 与 Future possibilities设计取舍与替代方案RFC 在 Rationale 一节没有展开长篇论证直接指出理由见 Motivation简化文法、简化宏并把“维持现状”列为始终存在的替代方案。从更早的 RFC 2359 的讨论中可以看到当时曾考虑过..PAT、PAT..等更复杂的语法但由于它们与将来可能的半开区间模式..END、BEGIN..存在歧义最终都被否决转而采用与既有绑定语法一致的BINDING ..形式。RFC 2707 的路线正是这一系列讨论收敛后的结果不引入新记号只改变..的语法地位。Prior art本 RFC 明确声明自己是 RFC 2359 的后续follow up。而 RFC 2359 又提到更早的 RFC 1492 已经讨论过“模式中的剩余列表”这一主题。三条 RFC 构成了一条完整的演进链1492 把..扩展到元组/元组结构体 → 2359 为 slice 模式加入BINDING ..→ 2707 把..提升为完整模式并解锁宏。Unresolved questions 与 Future possibilitiesRFC 2707 的未决问题Unresolved questions为空未来可能性Future possibilities则指出了一个明确的扩展方向接受BINDING ..出现在元组模式中例如(head, tail ..)。目前BINDING ..只允许在 slice 模式内部使用未来若将其扩展到元组模式就可以写出let (head, tail ..) (1, 2, 3, 4);这样的模式来一次性绑定“首元素 剩余元组”。这是一个尚未落地的设计前瞻读者在使用时不应假设该语法当前可用。实践小结新语法使用速查用法示例状态元组模式中使用..(a, .., z)允许元组结构体/枚举变体中使用..Variant(a, .., z)允许slice 模式中使用..[a, .., z]允许slice 模式中绑定子切片[a, tail .., z]允许源自 RFC 2359..后尾随逗号Variant(a, b, ..,)允许RFC 2707 新增pat宏匹配器中传..check_pattern!(..)允许RFC 2707 新增元组模式中BINDING ..(head, tail ..)不允许未来可能性单个模式中使用多个..(.., ..)语义错误非列表位置使用..let .. 10;语义错误struct 模式中的..S { f1, .. }仍为语法片段不是模式综合来看RFC 2707 是一次典型的“语法去特殊化”设计不增加任何新记号仅把既有片段..提升为完整模式就在不破坏现有代码的前提下同时简化了文法、激活了pat宏匹配器、并改善了尾随逗号的体验。理解它也就理解了 Rust 模式系统“语法接受范围”与“语义校验范围”两层设计之间的微妙边界。赞分享文档【免费下载链接】rfcsRFCs for changes to Rust项目地址https://gitcode.com/gh_mirrors/rf/rfcs点击查看免费下载相关推荐让宏成为一等公民Rust 宏 2.0 的命名与模块化设计RFC 1561 深度解读让宏成为一等公民Rust 宏 2.0 的命名与模块化设计RFC 1561 深度解读 导读 Rust 的 macro_rules! 宏虽然功能强大却长期游文档Rust RFC 1506 解读统一三种 ADT 结构体种类的语法模型与匹配一切模式Rust RFC 1506 解读统一三种 ADT 结构体种类的语法模型与匹配一切模式 导读 Rust 的代数数据类型ADTAlgebraic Data文档Rust RFC 0179 解读为 mut 模式匹配引入 mut pat 语法Rust RFC 0179 解读为 mut 模式匹配引入 mut pat 语法 导读 本文以 RFC 0179 mut 模式语法 https://文档上一篇还在为B站视频转文字烦恼3分钟教你用开源神器实现效率突破下一篇bili2text让B站视频内容变成可搜索、可编辑的文字笔记创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考