文档【免费下载链接】swift-evolutionThis maintains proposals for changes and user-visible enhancements to the Swift Programming Language.项目地址https://gitcode.com/gh_mirrors/sw/swift-evolution点击查看免费下载本篇技术指南围绕 swift-evolution 仓库中由语言指导组LSG维护的「常见被否决提案」清单 commonly_proposed.md 展开系统梳理 Swift 对缩进语法、分号、逻辑运算符、guard、强制解包、GC 等高频提案的否决理由并结合仓库内的正式提案如 SE-0004、SE-0054、SE-0095印证这些决策背后的设计哲学。读完本文你将理解 Swift 在C 家族传统、显式优于隐式、工具链可解析性三条主线上的取舍逻辑并掌握在 Swift 论坛上发起新提案前应遵守的讨论纪律。这份清单是什么commonly_proposed.md 的定位commonly_proposed.md是 Swift Evolution 流程中的一份负向设计文档——它不描述要做什么而是记录为什么不做什么。它由语言指导组Language Steering Group维护这一点在 process.md 中有明确交代The LSG maintains a list of commonly rejected proposals.它存在的意义非常实际Swift 语言持续演进十几年社区里许多想法被反复提出而其中相当一部分与 Swift 的核心设计方向相悖、几乎不可能被接受。把这些讨论沉淀为清单可以让后来者避免重复踩坑也让否决本身成为可引用的公开决策记录。文档开头明确了两条使用规则若想重启某个话题必须为讨论带来新信息而不是简单地说我真的很想要这个或别的语言里有这个功能而且我喜欢它。超出范围out-of-scope的提案不会进入评审排期。当前仓库 README.md 列出了每个大版本发布的核心关注领域focus areas经正式评审后被否决的变更则收录在 Swift.org 的 Swift Evolution 仪表盘中。换句话说这份清单与 process.md 描述的两阶段流程先在论坛 pitch 讨论、再进入 open review是衔接的清单承担前置过滤职能帮提案者把精力集中在真正有希望的方向上。理解一切否决的前提Swift 的 C 家族血统清单中有大量讨论引用C familyC 家族语言。文档对它的定义是在语法层面与 C 相似的语言家族包括 C、C#、Objective-C、Java 和 JavaScript。这是一把理解全文的钥匙——Swift embraces its C heritage. Where it deviates from other languages in the family, it does so because the feature was thought actively harmful (such as the pre/post-increment) or to reduce needless clutter (such as;or parentheses inifstatements).这句话给出了 Swift 偏离 C 传统的仅有的两类正当理由该特性被认为主动有害actively harmful例如/--自增自减运算符为减少无谓杂乱needless clutter例如行尾分号、if语句的括号。反之如果某个提议只是换个叫法或别的语言这么干却没有达到上述标准就会被归入非目标non-goal。仓库中 SE-0004《Remove the and -- operators》 就是主动有害类偏离的完整案例状态Implemented (Swift 3.0)。该提案列举了移除/--的七条理由其中与上述哲学直接相关的包括x相比x 1表达优势极小Swift 中、等赋值类运算本就返回Void/--返回值的模型与之不一致for-in、区间、map等特性消除了 C 风格for循环中使用i的大部分场景依赖返回值如foo(a, a)的代码即使语义被定义清楚也极难阅读维护。最终它通过如果我们今天没有这个运算符还会在 Swift 3 里加上它吗这一试金石得出否定结论。对照阅读 commonly_proposed.md 与 SE-0004可以完整看到从提出到实现再到沉淀为常识的决策闭环。基本语法与运算符四个被否决的方向用 Python 风格缩进替代{}花括号这是最能引发情绪争议的话题之一但结论明确Swift 不会改用缩进界定作用域。花括号是 C 家族的基本语法结构弃用它将使 Swift 脱离其血统根基并动摇所有已有代码与工具链。移除;分号文档给出了一个精细的二分处理行内分号是刻意的表达特性一行写多条语句应当保留行尾分号属于代码风格问题应该交给linter处理而不是让编译器去管。这体现了 Swift 的一条原则编译器负责语言语义风格治理交给工具层。用 and、or、not 替换、||、!这是清单中最具技术深度的一条否决其理由与编译器与工具链的架构直接相关Swift 刻意将运算符语法与标识符语法分区partitioned。这是支持用户自定义重载运算符的关键前提。若运算符由普通标识符如and构成编译器解析单个文件时就必须先查看其import的模块、读取运算符声明才能决定如何分词——这会破坏无需解析全部 import 即可解析单个 Swift 文件的能力对 IDE、补全、重构等工具链是重大打击。即便不考虑中缀函数not要像!一样省略括号也必须获得运算符或关键字地位而not somePredicate()在视觉上的绑定也比!somePredicate()松散得多。有趣的是仓库中 SE-0001《Allow (most) keywords as argument labels》状态Implemented (Swift 2.2)恰好展示了 Swift 如何在关键字与普通标识符之间划出精细边界除inout、var、let三个会改变参数语义的关键字外其余关键字都可以作为参数标签如indexOf(value, in: collection)因为关键字后跟:在语法上无歧义。分区但精细、歧义即拒绝正是 Swift 语法设计的统一思路。替换?:三元运算符?:确实魔法感十足但它服务于一个重要的使用场景在表达式中紧凑地选取两个值之一。社区对替代方案做过密集讨论但没有一个足够好到值得背离 C 家族先例。否决理由是务实的先例本身就是价值除非替代方案显著更优。集合类型为什么Array下标访问不返回 Optional让ArrayT的下标访问返回T?或T!而不是T是一个反复出现的诉求但同样被明确否决理由有两条语义层面越界访问数组是一个逻辑错误logic error当前行为如实反映了这一点——你不应该吞掉一个逻辑错误并默默得到nil。性能层面若下标访问需要返回 Optional每次访问都要做边界检查并包装结果会将数组访问拖慢到不可接受的程度。数组是 Swift 性能模型的基石这个代价无法接受。值得注意文档的措辞Changing the unlabeled array subscript to return an optional has come up multiple times before and isvery unlikely to be accepted.——这是清单中罕见的几乎不可能级判断说明这条边界相当稳固。控制流、闭包、可选绑定与错误处理七条否决的深层逻辑替换continue关键字有提议用其他脚本语言的同义词next、skip、advance替换continue。否决理由直指设计目标Swift 刻意让自己感觉是 C 家族的一员在没有强烈动机的情况下把关键字换成非 C 先例的说法是明确的 non-goal。移除default:只用case _:default被广泛使用、在众多 C 家族语言中有充分先例而case _过于魔法。先例、可读性、惯用性三方面都不支持这次变更。把guard改名为unless这是清单中论证篇幅最长的条目之一核心论点是请求改名源于对guard语义的根本误解。误解方认为guard只是逻辑取反的if所以unless更直观事实是guard强制要求其花括号内的代码为当前执行路径提供提前退出——块内必须出现return、throw、break、continue或调用不返回的函数如fatalError()这与if有本质区别因此guard与if平行的假设不成立改名理由也随之瓦解。推断省略guard主体时的return有多个提案希望允许省略guard主体以追求简洁即只写条件不写退出语句。否决依据是 Swift 的一条核心原则——让控制流显式且可见举例来说try关键字存在的唯一目的就是向人类读者指出哪里可能抛出错误隐式返回会违反这一原则用简洁换取清晰这不是 Swift 的风格此外退出作用域的方式远不止return循环里可能想break或continue而且并非每个函数都有显而易见的默认返回值可退。更改闭包字面量语法闭包语法在 Swift 内部经历过仔细的论证设计的各个方面都有强动机。任何修改提案都应对 Swift 语法有非常细致的理解即便如此找到更好方案的可能性也很低。在if let中使用模式匹配取代可选解包这一条信息量极大Swift 团队实际上尝试过将if let改为模式匹配形式但收到了大量负面反馈。文档列出了五点原因堪称一份语言演进试错记录大多数开发者不会用模式匹配的术语思考问题他们想的是解构destructuringif let最常用的场景就是可选匹配改动让常见场景变得更别扭改动提高了 Swift 的学习曲线——模式匹配从可以晚点学变成必须一开始就面对当前if case的设计已经围绕case关键字统一了模式匹配概念不熟悉if case的开发者遇到它时能顺利在搜索引擎或 Stack Overflow 上检索到答案。第五点尤其能体现 Swift 团队的务实语言特性不仅要好用还要可被搜索、可被解释。移除或弃用强制解包运算符!对移除/弃用强制解包force-unwrap与try!的呼声同样被明确拒绝强制解包是语言中合法且有价值的组成部分并非仅仅出于源码稳定性考虑。核心团队明确表示即使以编译器 flag 开关的模式启用也不会考虑这类提案。文档同时留下一个开放话题编译器是否应该获得更通用的lint能力来引导代码风格——风格问题归风格工具语言语义归编译器这与分号条目的态度一脉相承。仓库中的 SE-0054《Abolish ImplicitlyUnwrappedOptional type》状态Implemented (Swift 4.2)可以看作这条决策的正面佐证Swift 虽然收紧了隐式解包可选IUO的使用范围——把T!从类型降格为声明上的属性_autounwrapped禁止嵌套 IUO如[Int!]、禁止typealias X Int!——但显式的强制解包运算符!与try!始终是合法的一等公民。正如该提案所述IUO 是过渡性技术而显式!是开发者明确表达意图的工具。两条决策合起来勾勒出 Swift 的完整态度显式解包可以隐式传播不行。用 C 风格语法替换do/try/repeatSwift 的错误处理是刻意设计的让代码维护者一眼看出哪些调用可能抛错。它与其他语言的异常处理在部分语法上相似但在关键点上刻意不同——这是偏向错误使用者一方的精心平衡。文档明确指引在提出修改前必须通读官方文档《Error Handling Rationale and Proposal》全文理解现状设计的原因并准备好解释你的改动为何值得打破这种平衡。杂项两条架构级否决用垃圾回收GC替代自动引用计数ARC这是清单中最具系统级色彩的一条。文档承认 GC 的优势——标记-清扫式 GC 在 Java、JavaScript 等流行语言中被广泛使用且能自动回收 ARC 需要程序员自行推理的引用环。但否决理由分量更重系统编程领域适配性实时系统视频/音频处理、深度嵌入式控制器、大多数内核都普遍认为 GC 不适用内存开销GC 只有在比进程实时使用量多给 3–4 倍内存时才高效这个代价对 Swift 不可接受。也就是说GC 会把 Swift 挡在大量系统编程领域门外——而能写系统软件正是 Swift 的立身之本。类型约束中的析取逻辑或不允许(Int | String)这类匿名联合类型、以及在类型约束中使用逻辑或。清单引用了 SE-0095 评审期间return for revision的论坛讨论直接给出结论这种类型的约束是类型系统无法也不应支持的。仓库中的 SE-0095《Replace protocolP1,P2 syntax with P1 P2 syntax》状态Implemented (Swift 3.0)提供了完整的背景Swift 用表达协议组合A B C是同时满足所有协议的合取类型Any从 typealias 升格为关键字。合取被精心实现而析取|被明确否决——这体现了 Swift 类型系统对可表示性的审慎并非所有听起来对称的语法都有对等的类型论支撑。给提案者的行动指南基于这份清单与 process.md 描述的完整流程想在 Swift 社区推进一个想法正确的姿势是先搜索在 Swift 论坛检索是否已有相关讨论并对照本清单确认想法是否已被否决。若已被否决除非你有新的技术论据否则重启讨论没有意义。先 pitch 再写提案在论坛的 Evolution Pitches 板块发起非正式讨论链接到所有相关旧线程充分吸收反馈process.md 对 pitch 阶段有详细要求。遵循模板撰写正式提案语言与标准库提案使用 proposal-templates/0000-swift-template.md并以SE-前缀提交到仓库的 proposals/ 目录SwiftPM 与 Swift Testing 提案分别使用对应的 0000-swiftpm-template.md 与 0000-swift-testing-template.md。对标当前版本焦点参考 README.md 中列出的每个大版本焦点领域判断想法是否契合当下发布节奏不契合的提案可能被要求推迟到后续版本。理解评审不是投票open review 的反馈以论据质量取胜而不是人数或嗓门演化工作组依据什么对 Swift 项目最有利做判断process.md。结语一份负向文档的价值commonly_proposed.md表面上记录的是拒绝实质上记录的是一套长期稳定的设计价值观尊重 C 家族先例、显式优于隐式、保持单文件可解析性、为系统编程保留性能与确定性、风格问题交给工具而非编译器。当你理解了这些否决背后的理由也就理解了 Swift 为什么会是今天的样子——以及什么样的提案才配得上一次正式的 open review。下次在论坛上看到为什么 Swift 不用缩进/不要分号/改成 GC的讨论时你可以直接引用这份清单把话题推进到新论据层面而不是停留在我想要这个。赞分享文档【免费下载链接】swift-evolutionThis maintains proposals for changes and user-visible enhancements to the Swift Programming Language.项目地址https://gitcode.com/gh_mirrors/sw/swift-evolution点击查看免费下载相关推荐Swift Evolution 提案解读SE-0028 现代化 Swift 调试标识符__FILE__ → file及其后续演进Swift Evolution 提案解读SE 0028 现代化 Swift 调试标识符__FILE__ → file及其后续演进 导读 SE 0028《M文档Arnis 完整指南三步把真实城市生成我的世界方块世界Arnis 完整指南三步把真实城市生成我的世界方块世界 想把自家城市原样搬进《我的世界》不必一块方块一块方块地摆。Arnis 读取 OpenStreetMa桌面应用游戏开发GISSwift 参数默认值调用顺序强制化解读 Swift Evolution SE-0060 提案Swift 参数默认值调用顺序强制化解读 Swift Evolution SE 0060 提案 本篇技术指南以 Swift 语言演进仓库swift evol文档上一篇CANN/ge图引擎API文档下一篇Battle City AI系统设计原理从简单寻路到智能决策的完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考