苹果 AI 部分性能超过 GPT4 ｜ Swift 周报 issue 59

最新推荐文章于 2024-10-12 12:26:23 发布

网罗开发

最新推荐文章于 2024-10-12 12:26:23 发布

阅读量1.1k

点赞数 27

分类专栏： Swift周报文章标签：人工智能 swift issue

本文链接：https://blog.csdn.net/qq_36478920/article/details/140939477

版权

Swift周报专栏收录该内容

32 篇文章 4 订阅

订阅专栏

在这里插入图片描述

文章目录

前言

本期是 Swift 编辑组自主整理周报的第五十九期，每个模块已初步成型。各位读者如果有好的提议，欢迎在文末留言。

Swift 周报在 GitHub 开源，欢迎提交 issue，投稿或推荐内容。目前计划每两周周一发布，欢迎志同道合的朋友一起加入周报整理。

看人之长，世间一切尽是吾师，Swift社区一路走来没有敌兵，全是良师挚友。昔我一身旧雪，明我春风摇曳！👊👊👊

周报精选

新闻和社区：苹果 AI 部分性能超过 GPT4

提案：允许推断 TaskGroup 的 ChildTaskResult 类型提案正在审查中

Swift 论坛：提议正则表达式反向匹配

推荐博文：宣布 Swift 同态加密

话题讨论：

在现代高等教育中，大学生是否应尽早锁定专业一直备受争论，对此你怎么看？

上期话题结果

通过结果可以看出，大多数人认为更多的传统岗位将会被智能系统所代替。

新闻和社区

苹果公司 2024 财年三季度营收和利润同比增长

2024 年 8 月 2 日

据新华社旧金山 8 月 1 日电苹果公司 1 日发布的财报显示，2024 财年第三季度（截至 2024 年 6 月 29 日），公司实现营业收入 857.8 亿美元，同比增长约 4.9%；净利润 214.5 亿美元，同比增长约 7.9%。

财报显示，苹果公司当季手机销售额从上一财年同期的 396.7 亿美元降至 393 亿美元，略有下滑；可穿戴、家用及配件产品销售额从 82.8 亿美元降至 81 亿美元；服务收入由 212.1 亿美元升至 242.1 亿美元，增幅超过 14%。

苹果公司首席财务官卢卡·马埃斯特里在财报中表示，当季该公司活跃设备安装数量在所有地区都创下历史新高。

苹果公司首席执行官蒂姆·库克表示，公司将继续大力投资创新此前在全球开发者大会上推出的个人智能系统“苹果智能”。(来源：新京报)

苹果AI部分性能超过 GPT4

2024 年 7 月 31 日

苹果公司最新发布论文，分享了关于 Apple Intelligence 模型的相关细节，称其部分性能已经超过 OpenAI 的 GPT-4。据论文描述，苹果自研大模型在指令遵循、文本总结方面测试超 GPT-4。数据显示，在电子邮件、信息和通知汇总方面，苹果模型AFM的满意度分别为 71.3%、63% 和 74.9%。(来源：IT之家)

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

iOS 18.1 更新引争议苹果官方回应绝了

2024 年 7 月 30 日

近日，苹果公司最新推出的一系列产品引发了业界广泛关注。其中，iOS 18.1 和 iPadOS 18.1 开发者预览版 Beta 更新被广泛讨论。

据了解，这些更新包括了备受期待的通话录音功能。用户只需在 Notes 或 Phone 应用程序上点击录音按钮即可捕获音频和文字信息，并通过声音消息向对方发送通知。这项设计引起了网友们的热议，部分网友表示支持，认为这是苹果公司在隐私保护方面做出的努力；而另一些网友则认为这样反而降低了实用性，并调侃道“太尬了”“真的挺离谱的”“事先通知对方还录个啥呀？还不如没有这个功能”。对此，苹果官方回应称，这样的设计是为了保护双方的隐私。

值得一提的是，在 iPhone 通话录音会进行通知的情况下，大部分 iPhone 用户在必要时可能会选择其他方式进行通话记录。这种功能的使用频率可能会相对较低。(来源：中关村在线)

提案

通过的提案

SE-0427 不可复制的泛型 提案通过审查。该提案已在 四十九期周报 正在审查的提案模块做了详细介绍。

SE-0438 Metatype 关键路径 提案通过审查。该提案已在 五十五期周报 正在审查的提案模块做了详细介绍。

正在审查的提案

SE-0442 允许推断 TaskGroup 的 ChildTaskResult 类型 提案正在审查。

TaskGroup和ThrowingTaskGroup目前要求在创建时始终指定其两个泛型之一（ChildTaskResult）。由于SE-0326引入的闭包参数/结果类型推断的改进，在大多数情况下，可以通过允许编译器推断这两种泛型来简化这一点。

Swift论坛

发布Swift-foundation 现已推出

内容大概

Swift基金会的发布引发了关于内存管理和API兼容性的讨论。主要要点如下：

过去，Apple 开发者表示 Foundation API 的自动释放池行为不能改变，以保持二进制兼容性。
现在，部分Foundation API的自动释放行为可以改变，但某些情况下仍需保持兼容性。
为保证兼容性，Swift 基金会采用了一些策略，如兼容性检查和在 Objective-C 客户端中保留/自动释放结果。
Swift 的严格类型检查有助于解决一些常见的兼容性问题，如误用可变性和空值。
使用 Swift 实现可以减少内部对象的自动释放，从而在某些情况下降低峰值内存使用。

这些变化反映了 Swift 基金会在保持兼容性的同时，努力提高性能和安全性。

提议正则表达式反向匹配

内容大概

引言：
提议为 Swift 的正则表达式引擎添加反向匹配和后顾断言的支持。
动机：
现代正则表达式引擎普遍支持后顾断言，Swift 应跟进这一功能。
提议解决方案：
- 支持任意长度的后顾正则表达式，通过反向匹配实现。
- 提供API，从字符串末尾开始反向运行正则表达式。
详细设计：
- 语法：支持正向和负向后顾断言的语法。
- Regex 构建器：为Regex 构建器添加后顾断言支持。
- API：新增多个反向匹配相关的方法，如 firstReverseMatch、wholeReverseMatch 等。
兼容性：
- 源代码兼容：该提案是增量式的，与现有代码源代码兼容。
- ABI 兼容：与现有代码 ABI 兼容。
采用影响：
需要新版本的标准库和运行时。
未来方向：
考虑支持 PCRE 的 \K 功能，用于重置当前产生的匹配。
考虑的替代方案：
- 仅支持固定长度的后顾断言（被拒绝，因为会限制 Swift 的表达能力）。
- 在 API 名称中使用 “last” 而非 “reverse”（被拒绝，因为可能导致混淆）。

此提案旨在增强 Swift 正则表达式的功能，使其更加灵活和强大，同时保持与现有代码的兼容性。

讨论请帮助我理解将 Swift 6 警告添加到 Swift 5 的决定

内容大概

问题描述：
- Swift 6 编译器在 Swift 5 模式下引入了许多与新并发模型相关的警告。
- 某些情况下无法避免这些警告，例如导入 WebKit 模块时。
- 使用 -warnings-as-errors 选项时，无法编译原本有效的 Swift 5 代码。
疑问：
- 如果 Swift 5 模式下有效的代码现在产生警告，那么 Swift 5 模式的意义何在？
- 虽然一些警告可能有助于计划迁移，但是否应该有方法禁用它们？
- Swift 6 编译器的行为是否可视为一种倒退？
背景：
- 一些并发相关的警告在 Swift 5.5.x 中引入，后来在 Swift 5.6 中有所放松。
问题影响：
- 对于使用 -warnings-as-errors 的项目，无法使用新的 Swift 6 编译器编译 Swift 5 代码。
官方回应：
- 建议禁用 -warnings-as-errors，但这对某些开发者来说不可接受。
可能的解决方案：
- 关闭 warnings-as-errors 选项。
- 使用警告限制（本地或 CI），允许逐步修复 Swift 6 相关警告，同时防止添加新警告。
讨论要点：
- 开发者如何在自己的代码库中处理这些警告？
- 是否应该提供一种方法来禁用这些警告，特别是在 Swift 5 模式下？

这个问题突出了 Swift 版本迁移过程中的挑战，以及编译器警告策略对开发工作流程的影响。它引发了关于向后兼容性和渐进式迁移策略的讨论。

提议删除引用静态成员时对“Self.”的要求

内容大概

提议内容：
- 建议移除在实例成员中引用静态成员时需要使用 Self. 前缀的要求。
- 认为 Self. 前缀增加了代码噪音，不必要。
背景：
- 传统面向对象语言（如 Pascal、C++ 和 Java）允许直接引用静态成员，无需额外限定符。
问题示例：
- 开发者为避免使用 Self. 前缀，经常将私有常量移到类/结构体外部。
- 这种做法不理想，因为常量应该只在特定类型内部使用。
提议者观点：
- 认为调用者不应关心某个成员是静态的还是实例相关的。
- 希望能在类型内部定义静态常量并直接使用。
反对意见：
- 静态和实例属性之间存在语义和用户可见的区别。
- 静态不等同于常量，而是表示属于类型而非实例的属性。
- 给出了 Double.pi 和 Int.bitWidth 的例子来说明静态和实例属性的区别。
讨论要点：
- 为什么需要 Self. 而不需要 self.。
- 其他面向对象语言的做法及其局限性（不允许静态和实例属性同名）。
结论：
- 静态和实例属性之间确实存在语义区别。
- 提议者的例子（按钮高度）更适合作为实例属性。
- 如果确实需要，可以同时定义静态和实例属性。

这个讨论涉及了 Swift 语言设计的细节，以及如何平衡语言的表达力、清晰度和使用便利性。

讨论比较闭包

内容大概

问题：
是否有方法比较两个闭包的引用来确定它们是否相同？
主要回应：
- Swift中的函数值没有稳定的标识。
- 编译器可能会合并具有相同机器实现的不同函数。
- 同一函数可能因调用约定变化而产生不同的thunk。
- 这些转换是任意的，可能因编译器版本、设置、静态/动态库等因素而改变。
- 因此，不能依赖将函数转换为指针来比较，因为结果可能不一致。
替代建议：
- 可以使用KeyPath，它有==操作符，可以引用具有稳定标识的声明。
进一步讨论：
- 目前没有方法确定闭包的精确相等性，近期也不太可能有。
- 对于某些用例，精确相等性并非必要。
- 提出了一种可能的替代方法：比较结果可以是"确定相等"或"不确定"。
- 这种方法可以在某些情况下避免不必要的工作，但需要容忍有时会做多余工作。
未解决的问题：
- 如何恰当地命名这种不确定的比较方法。
- 如何更好地理解和推广这种比较方法的使用场景。
未来展望：
- 如果能找到好的方式描述这种比较，可能有助于将其纳入语言标准特性。

这个讨论揭示了 Swift 语言在处理闭包比较时的复杂性，以及编程语言设计中平衡灵活性和确定性的挑战。

提议放宽使用编译器生成的以 $ 为前缀的标识符作为闭包参数名称

内容大概

提案概述：
建议放宽在闭包中使用编译器生成的$前缀标识符的限制，特别是因为当前的限制阻止了在展开宏时使用 MacroExpansionContext.makeUniqueName(_:) 作为闭包参数的标识符。
背景：
- $前缀目前保留给编译器生成的标识符。
- Swift语法明确规定了$前缀标识符的使用，如：
```
implicit-parameter-name → $ decimal-digits
property-wrapper-projection → $ identifier-characters
```
- 实际上，编译器仅在特定情况下禁止使用$前缀标识符。
动机：
在宏展开时，MacroExpansionContext.makeUniqueName(_:) 返回的唯一名称带有$前缀，导致无法用作闭包参数名。示例：
```
let arg0 = context.makeUniqueName("")
return """
{ \(arg0) in
  ...
}
"""

// 展开后的源代码可能如下：
{ $s<SOME_MINGLED_NAME> in
  ...
}
```
这会导致编译器错误，将 $s<SOME_MINGLED_NAME> 错误地解释为属性包装器投影。
提议解决方案：
取消对使用 $ identifier-characters 作为显式闭包参数名的限制。这不会引入命名冲突，因为 $ decimal-digits 仍专门用于隐式闭包参数名。
讨论和疑问：
- 需要明确是否建议在一般情况下还是仅在宏展开中解除$限制。
- 有人提出是否可能将这一变更仅限于宏展开。
结论：
这似乎是一个有价值的改变，但需要进一步明确其适用范围和具体实施方式。

这个提案旨在解决 Swift 宏系统中的一个具体问题，同时也涉及了语言设计中标识符使用的更广泛问题。

已接受SE-0427：不可复制的 generics

内容大概

提案状态：
SE-0427：不可复制泛型的第二次审查已结束，提案已被接受。
主要修改：
- 要求明确声明对 Copyable 的条件一致性要求，而不是通过默认规则隐含。
- 移除了对非可复制关联类型的支持，将其留作未来方向。
讨论要点：
a. 关联类型问题：
- 移除关联类型支持导致了与泛型参数约束处理方式的不一致。
- 指导小组认为需要更多时间来制定关联类型的正确解决方案。
b. 未来可抑制约束：
- 讨论了如 Escapable 等未来可能的可抑制约束的处理方式。
- 这个问题将在未来引入 Escapable 或类似特性时再详细讨论。
c. ~Copyable 语法：
- 讨论了 ~Copyable 的含义和在不同位置的使用。
- 指导小组认为当前提议的 ~Copyable 语法是最佳选择。
d. 重复 ~Copyable 的问题：
- 指导小组认为 Copyable 要求应为默认设置，不同声明中的不同推断规则可能导致混淆。
e. 编译器限制：
- 讨论了是否应阻止在有显式 ~Copyable 抑制时使用显式 Copyable 要求或无条件一致性。
- 指导小组同意提案作者的观点，应发出错误以避免混淆。

代码示例（基于讨论内容推断）：

protocol P: ~Copyable { }

struct S<T: ~Copyable>: P { }

// 条件一致性示例
extension S: Copyable where T: Copyable { }

// 存在类型示例
let value: any P & ~Copyable

结论：
指导小组接受了提案中的语法和限制，认为这是 Swift 6 中这一重要特性的最佳推进方式。未来可能根据实际使用情况进行调整。

这个提案标志着 Swift 在处理不可复制类型和泛型系统方面的重要进展，为语言增加了更多的灵活性和表达能力。

话题讨论

在现代高等教育中，大学生是否应尽早锁定专业一直备受争论。赞同者认为，大学生应在探索不同学科后再选择专业，这样有助于他们发现真正的兴趣和才能，避免因为过早确定而陷入不合适的领域。反对者则认为，尽早确定专业有助于学生专注于职业发展，尽快进入职场并取得成功。中立者则认为，这取决于个人情况，包括学生的兴趣、目标和对未来的规划。对此你怎么看？