文档【免费下载链接】swift-evolutionThis maintains proposals for changes and user-visible enhancements to the Swift Programming Language.项目地址https://gitcode.com/gh_mirrors/sw/swift-evolution点击查看免费下载SE-0154Provide Custom Collections for Dictionary Keys and Values为 Swift 标准库引入了两个全新的集合类型Dictionary.Keys与Dictionary.Values分别取代了原先基于LazyMapCollection的keys与values视图一举解决字典键查找退化为线性扫描、以及键下标无法触发值类型 copy-on-write 优化的两大性能短板。本文以 proposals/0154-dictionary-key-and-value-collections.md 提案为骨架结合仓库中后续相关提案SE-0514、SE-0494与 Swift 4.0 发布说明完整还原该特性的设计动机、API 形态、迁移影响与替代方案并给出可直接运行的实战代码。背景一个看似无害的字典操作为何会变慢提案全文以如下字典作为贯穿始终的演示对象var dict [one: [1], two: [2, 2], three: [3, 3, 3]]这是一个[String: [Int]]类型的字典值本身是可变长度的数组。围绕这个字典SE-0154 揭示了两个此前版本Swift 3 及更早中长期存在、且相互独立的问题。问题一dict.keys.contains(_:)是 O(n) 线性扫描在 SE-0154 之前Dictionary.keys的类型是LazyMapCollection——它只是对字典元素做了一次惰性映射取出key字段并没有把“按键查找”转发到底层哈希表存储上。因此当开发者想用“Swifty”的方式判断字典是否包含某个键时if dict.keys.contains(one) { // ... }这条代码的语义虽然正确性能却与直觉严重背离LazyMapCollection的contains只能对映射结果做线性搜索O(n)而非字典本应提供的哈希查找期望 O(1)。字典规模越大这个性能落差越明显。相比之下下面两种写法虽然能达到期望的哈希查找性能但可读性欠佳// 通过 nil 检查 if dict[one] ! nil { // ... } // 通过忽略值的可选绑定 if let _ dict[one] { // ... }类似的性能差异也存在于定位键索引的场景dict.index(forKey:)走的是哈希查找而dict.keys.index(of:)在旧的LazyMapCollection视图上同样退化为线性扫描。SE-0154 的核心诉求之一就是让“自然、可读的写法”与“高效实现”不再对立。问题二字典值无法在原地修改破坏了 copy-on-write 优化字典的键下标dict[key]返回的是OptionalValue这意味着任何通过下标访问值的方式都被一层 Optional 包裹。对于Array这类带 copy-on-write写时复制优化的值类型而言能否识别出“自己是存储的唯一持有者”直接决定了追加元素时是否需要整体拷贝。当时修改字典中某个键对应数组的常见写法有两种各有缺陷// 方式一直接重新赋值——复杂且难读还会双重查找 dict[one] (dict[one] ?? []) [1] // 方式二可选链——简洁但静默忽略键不存在的情况 dict[one]?.append(1)第一种写法先读后写至少包含两次哈希查找逻辑绕口第二种写法在one不存在时什么都不做容易掩盖逻辑错误。更重要的是两者都无法让数组在原地增长由于 Optional 包裹导致 copy-on-write 检测失效即使dict是存储的唯一持有者每次append依然会产生一次不必要的数组内容拷贝。为什么不直接给字典增加基于索引的可变下标提案明确指出这行不通。如果允许通过索引修改键key本身几乎必然改变该键的哈希值进而使索引失效这违反了MutableCollection协议对索引稳定性的要求。因此可变性必须设计在“值视图”上而不是直接施加于字典本身。解决方案为 keys 与 values 提供真正的专属集合类型SE-0154 的解法遵循了String的先例——String通过characters、unicodeScalars、utf8、utf16等多个视图呈现同一底层内容的不同侧面。相应地Dictionary也新增两个嵌套集合类型Dictionary.Keys提供高效的键查找contains、index(of:)均转发到底层哈希存储Dictionary.Values提供可变的集合接口MutableCollection允许对既有键的值做原地修改。这两个类型都嵌套在Dictionary内部且不可被直接构造——它们只能作为某个字典的视图被获取这保证了视图与字典底层存储永远一致。提案给出的标准库接口草案如下struct DictionaryKey: Hashable, Value: ... { /// 字典键的集合视图。 struct Keys: Collection { subscript(i: Index) - Key { get } // 其余 Collection 协议要求 } /// 字典值的可变集合视图。 struct Values: MutableCollection { subscript(i: Index) - Value { get set } // 其余 Collection 协议要求 } var keys: Keys { get } var values: Values { get set } // 其余 Dictionary 声明 }关键设计点有三keys是只读属性values是get set属性——可变性只授予值视图Keys遵循CollectionValues遵循MutableCollectionValues的下标同时提供 getter 与 setter两个视图与Dictionary共享同一套Index类型因此可以在两个视图之间无缝传递索引。共享索引两段式“定位 修改”模式由于keys、values与字典三者共享Index类型开发者可以先用键视图定位索引再通过值视图进行原地修改if let i dict.index(forKey: one) { dict.values[i].append(1) // 原地追加无拷贝 } else { dict[one] [1] }由于values是真正的MutableCollection且下标直接暴露底层存储append(1)不再经过 Optional 包装数组得以识别“唯一持有者”身份从而完全省略一次内容拷贝。提案甚至允许混合使用两个视图完成同一逻辑// 使用 dict.keys.index(of:) 定位再经 dict.values[i] 修改 if let i dict.keys.index(of: one) { dict.values[i].append(1) } else { dict[one] [1] }借助共享索引dict.keys.index(of:)与dict.values[i]可以安全组合索引来自同一个字典的键视图随后被交给同一个字典的值视图二者引用的是同一份底层存储。提案生效后直觉写法即高效写法引入新类型后文章开头的“好读但慢”的写法不再慢// 现在很快不再是线性扫描 if dict.keys.contains(one) { // ... }Dictionary.Keys会把contains与index(of:)等查找操作转发到底层哈希表开发者终于可以放心地用最自然的语句表达“判断键是否存在”。详细设计要点SE-0154 的详细设计可归纳为三条标准库引入两个新集合类型Dictionary.Keys与Dictionary.ValuesDictionary.keys与Dictionary.values属性的类型由LazyMapCollection改为上述新类型——这属于破坏 ABI 的变更因为无法继续沿用既有类型做别名这也是该提案需要进入 Swift 4 阶段 2 评审流程的原因之一新集合类型不可直接构造仅以字典视图的形式呈现。对 ABI 与发布时机的意义在 Swift 4.0 发布说明 中Swift 4 被划分为两个阶段阶段 1 聚焦源码稳定性与标准库 ABI 稳定性所必需的变更阶段 2 则允许加入“不改变 ABI 的增量变更”以及“对现有标准库设施的改进”其中明确列出了“集合如新的集合算法与 Dictionary 使用体验的改进”作为重点方向。SE-0154 正属于这一类它改变了keys/values属性的具体类型涉及标准库 ABI但 API 名称与日常使用方式基本不变属于阶段 2 的增量式演进。对既有代码的影响与迁移SE-0154 明确指出新类型的性能收益与values的可变性都是纯增量的绝大多数代码只是临时、过渡性地使用keys与values属性例如遍历升级后无需任何改动即可享受更快的键查找唯一的破坏性场景是代码显式声明了keys或values属性的类型例如把let ks: LazyMapCollectionDictionaryString, [Int], String dict.keys写进了类型签名。此时只需把声明的类型改为Dictionary.Keys/Dictionary.Values即可。换言之从 Swift 3 迁移到 Swift 4普通使用dict.keys遍历、Array(dict.keys)转换等代码基本零改动只有类型标注处需要手动调整。被否决的替代方案为什么这样设计更好提案在 “Alternatives considered” 一节讨论了三种备选路线均被否决理解这些权衡有助于把握最终设计的边界。方案一依赖编译器能力消除 copy-on-write 问题即不引入新类型而是通过编译器在既有键下标上管理可变性寄希望于未来的 copy-on-write 语义与 inout 访问改进。问题在于这会显著增加编译器与运行时复杂度且收益不确定不如提供一个显式的可变集合视图来得直接可靠。方案二带默认值的更新 API消除“键缺失”时的双重查找例如为字典提供“找到就改、找不到就用默认值”的 API// 用 SearchState 类型记住键的位置 dict.entries[one] .withDefault([]) .append(1) // 双参数下标 dict[one, withDefault: []].append(1) // 带 inout 闭包 dict.withValue(forKey: one) { (v: inout Value?) in if v ! nil { v!.append(1) } else { v [1] } }提案承认SE-0154 的共享索引方案只能消除“值已存在时修改”的那一类双重查找无法消除“先检查键是否存在、再决定是否插入”的场景方案二正是为补齐这一缺口而生。但 SE-0154 选择把问题控制在“提供高效且可变的视图”这个最小范围内避免同时引入一组新的 API 表面把“缺失键默认值”问题留给后续提案这类能力后来也确实以modifyaccessor 等形式在其他提案中继续演进。方案三重构字典的 Element 类型让字典自身成为可变集合让Dictionary的Element从(Key, Value)二元组改为Value从而让Dictionary自身成为一个以值为元素的MutableCollection另设entries/keysAndValues视图承载键值对。设想的用法形如let valuesOnly Array(dict) // [[2, 2], [1], [3, 3, 3]] let keysAndValues Array(dict.entries) // [(two, [2, 2]), (one, [1]), (three, [3, 3, 3])] let foo dict[one] // Optional([1]) let i dict.keys.index(of: one)! dict[i].append(1)这个方案看似优雅但颠覆了Dictionary作为“键值对集合”的核心抽象——Dictionary的Element是(key: Key, value: Value)这一事实早已渗透到for (k, v) in dict、map、reduce等所有集合 API 的使用习惯中重构将引发大规模源码破坏。相比之下SE-0154 以两个嵌套视图承载新能力保持了字典自身的Element语义不变迁移成本降到最低。从仓库后续提案看这两个类型的持续演进SE-0154 落地Swift 4.0Status 标记为 Implemented之后Dictionary.Keys/Dictionary.Values作为标准库一等公民在后续提案中继续获得能力补强SE-0514为Dictionary.Keys、CollectionOfOne、EmptyCollection增加Hashable一致性Swift 6.4 实现由于字典的Key恒为Hashable键视图天然具备“元素可哈希”的前提。SE-0514 为Dictionary.Keys添加无条件的Hashable一致性哈希实现采用可交换哈希算法对每个元素哈希做 XOR 累积确保包含相同元素但迭代顺序不同的两个键视图哈希值一致——这与Set、Dictionary自身的哈希语义保持一致也侧面印证了 SE-0154 设计的Keys集合本质上是“有序展示的集合视图”。提案同时指出Dictionary.Values因可能包含重复元素要做出“multiset”式的等价比较成本过高故未为其添加Hashable。SE-0494isTriviallyIdentical(to:)方法族该提案为Array、String、Dictionary、Set等 copy-on-write 类型提供 O(1) 的“平凡同一性”快速判断并在“未来候选类型”一节明确列出Dictionary.Keys与Dictionary.Values见 proposals/0494-add-is-identical-methods.md 第 666–670 行。这延续了 SE-0154 的核心关切——识别共享存储、消除无谓拷贝——只是把这一能力从“原地修改”扩展到了“相等性快速判断”层面。这两份后续提案从不同侧面印证了 SE-0154 所建立的类型基础是稳固且可扩展的Dictionary.Keys作为“无重复元素的视图”具备集合语义Dictionary.Values作为“可重复元素的可变视图”则更接近可变序列。实战要点速查需求SE-0154 之前SE-0154 之后推荐判断键是否存在高效dict[key] ! nil可读性差dict.keys.contains(key)O(1) 哈希查找定位键的索引dict.index(forKey: key)dict.index(forKey:)或dict.keys.index(of:)均高效原地修改既有键的值dict[key] (dict[key] ?? []) [x]有拷贝dict.values[i].append(x)无拷贝值不存在时回退插入—if let i dict.index(forKey:) ... else dict[key] [x]显式类型标注LazyMapCollection...Dictionary.Keys/Dictionary.Values需迁移适用前提与限制Dictionary.Keys与Dictionary.Values自 Swift 4.0 起可用二者不可直接构造只能通过字典实例的keys/values属性获取索引与Dictionary共享但请注意索引仅在字典未被结构性修改如插入/删除键时有效。SE-0154 的方案消除了“修改已存在值”时的双重查找但“键缺失时的默认值插入”仍需要index(forKey:)加分支的写法这类能力在 Swift 后续版本中由modifyaccessor 等机制继续完善。结语SE-0154 是一次典型的“以类型换性能、以视图换能力”的标准库演进通过Dictionary.Keys让“判断键是否存在”这一直觉写法获得哈希查找性能通过Dictionary.ValuesMutableCollection让字典值能够在原地增长完整释放 copy-on-write 的优化空间而三端共享的索引设计则让“定位 修改”两段式操作既高效又类型安全。理解这一提案的动机与设计权衡有助于开发者在日常 Swift 编程中写出既自然又高性能的字典操作代码也为后续理解Dictionary.Keys的Hashable一致性SE-0514等增量演进提供了上下文。赞分享文档【免费下载链接】swift-evolutionThis maintains proposals for changes and user-visible enhancements to the Swift Programming Language.项目地址https://gitcode.com/gh_mirrors/sw/swift-evolution点击查看免费下载相关推荐cJSON对象操作终极指南7个高效查找与修改键值对的实用技巧cJSON对象操作终极指南7个高效查找与修改键值对的实用技巧 cJSON作为轻量级的ANSI C JSON解析器是嵌入式系统和C语言项目中处理JSON数据的序列化NVIDIA Profile Inspector完全指南解锁显卡隐藏性能的7大实用技巧NVIDIA Profile Inspector完全指南解锁显卡隐藏性能的7大实用技巧 NVIDIA Profile Inspector是一款强大的显卡驱动配文档Swift 演进提案解析SE-0112 改进 NSError 桥接统一 Swift 与 Cocoa 错误模型Swift 演进提案解析SE 0112 改进 NSError 桥接统一 Swift 与 Cocoa 错误模型 SE 0112Improved NSErro文档上一篇告别模拟器APK Installer让你在Windows上无缝安装Android应用下一篇如何在Windows电脑上快速安装Android应用APK Installer完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考