kemchenj

原文: Optionals and String Interpolation
作者: Ole Begemann
译者: kemchenj

你知道这个问题吗? 你想要在 UI 上显示一个 Optional 值, 或者是在控制台打印出来, 但你不喜欢默认的 Optional 字符串的显示方式: “Optional(…)” 或者是 “nil”. 例如:

var someValue: Int? = 5
print("这个值是 \(someValue)")
// "这个值是 Optional(5)"

someValue = nil
print("这个值是 \(someValue)")
// "这个值是 nil"

在字符串里插入 Optional 值会有一些不可预料的结果

Swift 3.1 会在你往字符串里插入一个 Optional 值的时候发出一个警告, 因为这个行为可能会产生意料之外的结果. 这里有 Julio Carrettoni, Harlan Haskins 和 Robert Widmann 在 Swift-Evolution 的讨论:

原文: Swift: UIView Animation Syntax Sugar
作者: Andyy Hope
译者: kemchenj

闭包成对出现时会恶心到你

Swift 代码里的闭包是很好用的工具, 它们是一等公民, 如果他们在 API 的尾部时还可以变成尾随闭包, 并且现在 Swift 3 里还默认为 noescape 以避免循环引用.

但每当我们不得不使用那些包含了多个闭包参数的API的时候, 就会让这门优雅的语言变得很丑陋. 是的, 我说的就是你, UIView.

class func animate(withDuration duration: TimeInterval,            
    animations: @escaping () -> Void,          
    completion: ((Bool) -> Void)? = nil)

最近项目准备要上线了, 到了性能优化的阶段, 看了一些文章之后, 基本上都会提到 print 对于性能的影响很大, 常规的做法是新增一个方法, 想打印的时候全部调用这个方法, 编译时加一个布尔判断, 把方法里的 print 全部去掉, 变成一个空的方法, 例如下面这样 (摘录自 Swift 性能探索和优化分析 – 喵神):

// DEBUG 的 Complier Flag 的添加方法具体看喵神的的那篇文章
func dPrint(@autoclosure item: () -> Any) {
    #if DEBUG
    print(item())
    #endif
}

dPrint(resultFromHeavyWork())
// Release 版本中 resultFromHeavyWork() 不会被执行

但是感觉这种方式会影响代码习惯, 而且多人协作还有认知负担跟沟通成本, 谷歌一下之后, 某篇文章也写了一样的方法, 但是我在评论里找到了一个更加简单巧妙的方法 —- 重载

原文: Optional Non-Escaping Closures
作者: Ole Begemann
译者: kemchenj

Swift 里如何区分 escaping (逃逸)和 non-escaping (非逃逸)的闭包呢? escaping closure(逃逸闭包)作为函数参数在函数 return 之后(可能会)被调用. 也就是说这个 escaping 闭包被传递到了外部, 逃出当前的函数的作用域.

逃逸闭包经常会跟异步操作联系在一起, 就像下面的例子:

• 一个函数发起一个后台任务然后立刻返回, 通过一个 completion handler 回调去汇报结果
• 一个 View 的类保存了一个闭包去处理按钮点击事件, 每次用户点击这个按钮的时候就会去调用这个闭包, 这个闭包就会逃出这个属性的生命周期
• 你用 DispatchQueue.async 在一个线程里发起异步任务, 这个任务闭包就比发起异步任务的函数存活得更久.

与之相对的, DispatchQueue.sync 会等到任务闭包执行完成, 然后再 return – 这个闭包就永远不会逃逸了. 类似的还有 map 和其它标准库里常用的序列和集合的算法.

原文: Updating Strings for Swfit 3
作者: kharrison
译者: kemchenj

我去年写了一篇 Swift String Cheat Sheet 来帮助我记忆如何使用 Swift 标准库里的那些难用的 API, 在痛苦的版本迁移之后, Swift 3有了明显的改善, 这一部分得归功于新的 API 命名规范, 还有 Collections 集合, indicates 索引和 ranges 范围的一种新的运作方式.

这里有我关于 Swift 3的迁移工作的总结 Swift playground.

更好的 API 命名

标准库采用了新的 API 命名规范 API guidelines 之后, String 的属性和方法都有了很多改变. 因为大部分 API 命名的变化 Xcode 都会自动帮你修正, 所以我不会在这里把全都都列出来. 这里列出一些典型的改变让你能更好的了解这次变化:

原文: Xcode 8 Extensions

作者: tiborbodecs

译者: kemchenj

注: 比起原文, 改动比较大…

大概还有一个月 Xcode 8 就要发布 GM 版了, 所以这里列出了目前所有在 Xcode beta 期间开发的 extension

如果大家觉得这些 Extension 会很有用的话, 记得给它们 star 一下, 就算是个半成品, 也许这一个 star 就会成为他把这个 Extension 维护完成下去的动力

之前写过一篇关于 Swift 访问权限修改的文章, 这两天也看到了好几篇谈论访问权限的文章, 但单纯地讲概念可能大家的理解还是不会很深, private 的修改和 fileprivate 的加入其实还是跟日常代码规范有关, 今天就跟大家分享一下我的日常代码习惯以及这几个关键字的应用

下面的讲解不会解释这些关键字的含义, 还不了解的同学可以点进上面的连接看我之前写的文章

前两天 swift 3.0 更新了 beta 6, 权限访问的几个关键字有了一些改变, 这篇文章给大家简单介绍一下(真得很简单…)

还有一些小改变, 其中几个让人觉得很诡异:

• 很多 Core xx 的库把 swift原生的 Array 改成了 CFArray, 很多时候需要用 as 去转换(swift runtime 目前唯一一个比较显眼的功能…)
• 声明闭包的时候不能带显式 argument label, 例如typealias completion = (data: Data, error: Error?) -> Void就会报错, 必须加上_或者删掉参数标签
• 还有就是现在闭包声明的时候默认都是@nonescaping的, 如果闭包不是在当前作用域内执行而是还要继续作为参数传递到别的函数里的话, 那就必须加上@escaping
• 引入了 Objective-C 的 id, 在 Swift 叫做Any, 之前很多接口都从 AnyObject 改成了 Any, 而 Any 是没有 subscript 方法的, 看也就是说不能用键值对取值, 很多原本要通过键值对取值的写法都得先把类型强转成字典或者是 Anyobject?

Swift 3的 beta 版现在已经出来了, Chris Lattner 之前在邮件里也大概提到说 Swift 3在八月就基本上全面完工

大家在写小 demo 或者是项目迁移到 Swift 3.0 的时候遇到最大的一个问题应该是第三方库的添加

Swift 社区一直都是热情爆满, 诸如 Alamofire, Decodable等第三方库都有 Swift 3.0 的分支, 但如果在导入的时没有处理一下, 就总是会出各种奇奇怪怪的问题, 我在这里分享一下我自己的解决方案

其实主要要处理的问题就只有两个

1. 指定第三方库的某个特定分支
2. 指定工程文件内 Swift 编译的版本

原文: Looking back on Swift 3 and ahead to Swift 4
作者: Chris Lattner
译者: kemchenj

大家好，

Swift 3的正式版已经接近完成状态了, 是时候来回顾一下发布之前的事情, 从中汲取经验, 并且用来整理一下我们(Swift社区)在今年做的事情了. 总的来说, Swift 3无疑将会是一个Amazing的版本, 我们做到的很了不起, 谢谢每一个为这件事情贡献力量的人. 比起马上推进那一堆新计划, 更重要的是让我们每个人从整个大局来看, 了解自己做到的这些了不起的事情.

Metapoint: 这份邮件很长而且覆盖了很多主题, 比起直接回复, 最好还是重新开一个对话来对单独的一个话题进行讨论, 在主题上标上[Swift 4]就好了.