// 可选值

let cities_ = ["Paris": 2241,"Madrid": 3165,"Amsterdam": 827,"Berlin": 3562]

// madridPopulation 的类型是可选类型 Int?,而非 Int。一个 Int? 类型的值是 Int 或者特
//殊的 “缺失” 值 nil
let madridPopulation: Int? = cities_["Madrid"]

// 检验查询是否成功
// 写 madridPopulation! 是为了 获取可选值中实际的 Int 值。后缀运算符 ! 强制将一个可选类型转换为一个不可选类型
if (madridPopulation != nil) {
  print("The population of Madrid is \(madridPopulation! * 1000)")
} else {
  print("UnkNown city: Madrid")
}

if let madridPopulation = cities_["Madrid"] {
  print("The population of Madrid is \(madridPopulation * 1000)")
} else {
  print("UnkNown city: Madrid")
}

/**
如果 optional 变量是非 nil 的话,我们真的不愿意对 defaultValue 进行求值 ——
因为这可能是一个开销非常大的计算,只有绝对必要时我们才会想运行这段代码

*/

/**
Swift 还给 ! 运算符提供了一个更安全的替代,?? 运算符。使用这个运算符时,需要额外提供 一个默认值,当运算符被运用于 nil 时,这个默认值将被作为返回值
?? 运算符会检验它的可选参数是否为 nil。如果是,返回 defaultValue 参数;否则,返回可选 值中实际的值
*/
//infix operator ??

func ??<T>(optional: T?,defaultValue: T) -> T {
  if let x = optional {
    return x
  } else {
   
    return defaultValue
  }
}

/**
上面的定义有一个问题:如果 default 的值是通过某个函数或者表达式得到的,那么无论可选 值是否为 nil,defaultValue 都会被求值。
通常我们并不希望这种情况发生:一个 if-then-else 语句应该根据各分支关联的值是否为真,只执行其中一个分支。同样的道理,?? 运算符应该只 在可选值参数是 nil 时才对 defaultValue 参数进行求值。举个例子,假设我们像下面这样调用 ??:
作为 T 类型的替代,我们提供一个 () -> T 类型的默认值。现在 defaultValue 闭包中的代码仅 当我们对它进行调用时才会执行。在这样的定义下,代码会如预期一样,只在 else 分支中被执 行。美中不足的是,当调用 ?? 运算符时需要为默认值创建一个显式闭包。例如,我们需要编写 以下代码:
myOptional ?? { myDefaultValue }
*/

func ??<T>(optional: T?,defaultValue: () -> T) -> T {
  if let x = optional {
    return x
  }
  else {
    return defaultValue()
  }
}



//Swift 的 autoclosure 类型标签来避开创建显式闭包的需求。
//它会在所需要的闭包中隐式地将参数封装到 ?? 运算符。这样一来,我们能够提供与最初相同的 接口,但是用戶无需再显式地创建闭包封装 defaultValue 参数。Swift 标准库中使用的实际定 义如下:
//?? 运算符提供了一个相较于强制可选解包更安全的替代,并且不像可选绑定一样繁琐

infix operator ?? { associativity right precedence 110 }

func ??<T>(optional: T?,@autoclosure defaultValue: () -> T) -> T {
  if let x = optional {
    return x
  } else {
    return defaultValue()
   
  }
}


// 玩转可选值

// 可选值链
// 可选链,它用于在被嵌套的类或结构体中对方法或属性进行选择
struct Order {
  let orderNumber: Int
  let person: Person?
}
struct Person {
  let name: String
  let address: Address?
}
struct Address {
  let streetName: String
  let city: String
  let state: String?
}

// 给定一个 Order,如何才能查找到客戶的状态呢?我们可以使用显式解包运算符:
// order.person!.address!.state! 如果任意中间数据缺失,这么做可能会导致运行时异常。使用可选绑定相对更安全

if let myPerson = order.person {
if let myAddress = myPerson.address {
if let myState = myAddress.state { // ...

但这未免有些烦琐。若使用可选链,这个例子将会变成:
*/

var address = Address(streetName: "guangzhou",city: "huangpu",state: "wengcong")
var person = Person(name: "RHC",address:address)
var order = Order(orderNumber: 8,person:person)

// 使用问号运算符来尝试对可选类型进行解包,而不是强制将它们解包。当任意一个组成项 失败时,整条语句链将返回 nil
if let myState = order.person?.address?.state {
  print("This order will be shipped to \(myState)")
} else {
  print("UnkNown person,address,or state.")
}


// 分支上的可选值
//if let可选绑定机制,但是Swift还有其他两种分支语句,switch和 guard,它们也非常适合与可选值搭配使用
* 我们简单地为 case 分支中的每个模式添加一个 ? 后 缀。如果我们对一个特定值没有兴趣,也可以直接匹配 Optional 的 None 值或 Some 值
*/
switch madridPopulation {
case 0?: print("Nobody in Madrid")
case (1..<1000)?: print("Less than a million in Madrid")
case .some(let x): print("\(x) people in Madrid")
case .None: print("We don't kNow about Madrid")
}

guard 语句的设计旨在当一些条件不满足时,可以尽早退出当前作用域。没有值存在时就提早退出,是一个很常⻅的使用情境。将它和可选绑定组合在一起可以很好地处理 None 的情况。 很显然,guard 语句后面的任何代码都需要值存在才会被执行。举个例子,我们可以重写打印 给定城市居⺠数量的代码
*/
func populationDescriptionForCity(city: String) -> String? { guard let population = cities_[city] else { return nil }
  return "The population of Madrid is \(population * 1000)"
}
populationDescriptionForCity("Madrid")

// 可选映射
? 运算符允许我们选择性地访问可选值的方法或字段。然而,在很多其它例子中,若可选值存 在,你可能会想操作它,否则返回 nil
*/
func incrementOptional(optional: Int?) -> Int? {
  guard let x = optional else { return nil }
  return x + 1
}

// MARK: - 将 incrementOptional 函数和 ? 运算符一般化,然后为可选值定义一个 map 函数。这 样一来,我们不仅能像 incrementOptional 那样,对一个 Int? 类型的值做增量运算,还可以将 想要执行的任何运算作为参数传递给 map 函数
// map 函数接受一个类型为 Wrapped -> U 的 transform 函数作为参数。如果可选值不是 nil,map 将会将其作为参数来调用 transform,并返回结果;否则 map 函数将返回 nil。这个 map 函数是 Swift 标准库的一部分
extension Optional {
  func map<U>(transform: Wrapped -> U) -> U? {
    guard let x = self else { return nil }
    return transform(x)
  }
}


// 使用 map 来重写 incrementOptional
func incrementOptional2(optional: Int?) -> Int? {
  return optional.map { $0 + 1 }
}

// 再谈可选绑定
//map 函数展示了一种操作可选值的方法,但是还有很多其它方法存在:
let x: Int? = 3
let y: Int? = nil

// 问题是加法运算只支持 Int 值,而不支持我们这里的 Int? 值
//let z: Int? = x + y 解决:
func addOptionals(optionalX: Int?,optionalY: Int?) -> Int? { if let x = optionalX {
    if let y = optionalY {
      return x + y
    }
  }
  return nil
}

//了层层嵌套,我们还可以同时绑定多个可选:
func addOptionals_(optionalX: Int?,optionalY: Int?) -> Int? { if let x = optionalX,y = optionalY {
   return x + y
  }
  return nil
}


// 想更简短,可以使用一个 guard 语句,当值缺失时提前退出:
func addOptionals__(optionalX: Int?,optionalY: Int?) -> Int?{
  guard let x = optionalX,y = optionalY else {
    return nil
  }
  return x + y
}


let capitals = [
  "France": "Paris",
  "Spain": "Madrid",27)">  "The Netherlands": "Amsterdam","Belgium": "Brussels"
]


// 为了编写一个能返回给定国家首都人口数量的函数,我们将 capitals 字典与之前定义的的cities 字典结合。对于每一次字典查询,我们必须确保它返回一个结果

func populationOfCapital(country: String) -> Int? {
 
  guard let capital = capitals[country],population = cities_[capital]
    else { return nil }
 
  return population * 1000
}

可选链和if let(或guardlet)都是语言中让可选值能够更易于使用的特殊构造。不过,Swift 还提供了另一条途径来解决上述问题:那就是借力于标准库中的 flatMap 函数。多种类型中都 定义了 flatMap 函数,在可选值类型的情况下,它的定义是这样的
flatMap 函数检查一个可选值是否为 nil。若不是,我们将其传递给参数函数 f;若是 nil,那么
结果也将是 nil
*/
extension Optional {
  func flatMap<U>(f: Wrapped -> U?) -> U? {
    guard let x = self else { return nil }
    return f(x) }
}

// 使用此函数,重写例子
func addOptionals2(optionalX: Int?,optionalY: Int?) -> Int? {
  return optionalX.flatMap {
    x in optionalY.flatMap { y in return x + y}
  }
}

func populationOfCapital2(country: String) -> Int? {
  return capitals[country].flatMap {
    capital in cities_ [ capital ].flatMap {
      population in return population * 1000
    }
  }
}

// 当前我们通过嵌套的方式调用flatMap,取而代之,也可以通过链式调用来重写
//populationOfCapital2,这样使代码结构更浅显易懂:
func populationOfCapital3(country: String) -> Int? {
  return capitals[country].flatMap {
    capital in return cities_[capital]
    }.flatMap {
      population in return population * 1000
  }
}

AWESOME SWIFT-swift.libhunt.com-swift类库网站

https://swift.libhunt.com/categories/688-events

29 Events libraries and projects

• ORDERED BY POPULARITY
• ORDER BY DEV ACTIVITY

•  ReactiveCocoa

    10.0   7.3  Objective-C

  ReactiveCocoa (RAC) is a Cocoa framework inspired by Functional Reactive Programming. It provides APIs for composing and transforming streams of values over time.

•  RxSwift

    9.9   8.8 L3  Swift

  Microsoft Reactive Extensions (Rx) for Swift and iOS/OSX platform.

•  PromiseKit

    9.8   8.7 L5  Swift

  async promise programming lib.

•  ReSwift

    9.6   6.3 L5  Swift

  Unidirectional Data Flow in Swift

•  Bond

    9.3   8.8 L1  Swift

  a Swift binding framework.

•  BrightFutures

    8.3   4.7 L4  Swift

  promise and future lib for swift.

•  Katana

    8.2  8.7 L4  Swift

  Swift apps a la React and Redux.

•  ReactorKit

    7.8   6.4  Swift

  A framework for reactive and unidirectional application architecture.

•  ReactKit

    7.4   0.0 L3  Swift

  Swift Reactive Programming.

•  FutureKit

    6.4  0.7 L2  Swift

  A Swift based Future/Promises Library.

•  SwiftEventBus

    6.4   3.2 L5  Swift

  A publish/subscribe event bus optimized for iOS.

•  EmitterKit

    5.7  3.5 L5  Swift

  an implementation of event emitters and listeners in swift.

•  Signals

    4.9   3.3 L5  Swift

  replaces delegates and notifications.

•  Safe

    4.9   0.0 L2  Swift

  A modern concurrency and synchronization for Swift.

•  snail

    4.5   7.1 L5  Swift

  An observables framework for Swift

•  Reactor

    4.1   2.4 L5  Swift

  Powering your RAC architecture.

•  VueFlux

    3.8  6.8  Swift

  Unidirectional Data Flow State Management Architecture

•  SignalKit

    3.7   0.0 L5  Swift

  Swift event and binding framework.

•  Observable

    3.7   6.2  Swift

  The easiest way to observe values.

•  When

    3.4   5.4 L5  Swift

  A lightweight implementation of Promises in Swift.

•  Caravel

    3.3   0.0 L2  Swift

  A Swift event bus for UIWebView and JS.

•  Future

    2.5   0.0 L4  Swift

  A micro framework providing Future.

•  NoticeObserveKit

    2.3   0.0 L5  Swift

  NoticeObserveKit is type-safe NotificationCenter wrapper that associates notice type with info type.

•  Aftermath

    1.8   0.0 L5  Swift

  Stateless message-driven micro-framework in Swift.

•  Notificationz

    1.6   2.5 L5  Swift

  Helping you own NSNotificationCenter by providing a simple, customizable adapter.

•  Forbind

    1.2   0.0 L4  Swift

  Functional chaining and Promises in Swift.

•  ReduxSwift

    1.0   0.0 L5  Swift

  Predictable state container for Swift apps too

•  PureFutures

    0.7   0.0 L4  Swift

  Futures and Promises library.

•  SSEventFlow

    0.3  4.4 L5  Swift

  A type safe alternative to NSNotification, inspired by Flux.

Chris Lattner 对 Swift 3 的总结与对 Swift 4 的展望

Chris Lattner 写了一篇文章：回顾 Swift 3，展望 Switf 4，以下是这篇文章的关键内容：

• 开源大有益处，但无法让所有人满意。

• Swift 3 将在 2016 年秋到来。Swift 3.x 会在 2017 年春公布，Swift 4 会在 2017 年秋发布，这其中不包括修复 bug、提升兼容性之类的小更新（例如 3.0.1）。

• Swift 4 在交付时一定会保障代码的稳定性，增加容错性、ABI，优化泛型与字符串等等。

• 语法糖的优先级最低，没有提上日程。

• 安排进度有些困难。开发的目标并非是对交付的保证。从一开始安排计划与进度就是最主要的事。

下面是全文：

大家好呀，

Swift 3 的正式版已经基本完成，是时候让我们回顾一下这个版本了，从开发过程中汲取经验，并用于总结我们（Swift 社区）在这一年内所做的事。总体上来说，Swift 3 毫无疑问将是一个 amazing 的版本，我们完成了很多出色的工作。感谢所有为它付出的人。相比于立刻着手推进新计划，盘点过去、展望未来同样重要。

提示：这封 email 长得吓人，其中涵盖了各方面的话题。比起直接回复，更好的选择是开一个新话题来讨论。只需在主题上标记“［Swift 4］”即可。

Swift 3 回顾

每年 Swift 的新版本都与前一年完全不同，我希望 Swift 4 能继续保留这个传统。为了每一年都有提升与进步，以下是一些对 Swift 3 的回顾与建议：

• 开源有许多好处。见证一个充满活力的团队合作得如此之好，大家几乎彻夜为其付出，让人不可思议、充满惊喜。与这样一个才华横溢并充满热情的团队合作，实在是太棒了！

• 开源也带来挑战。比起“闭源设计”，“开源设计” 进度更慢且更加不可预料，我想这么说应该是公允的。然而，开源的结果明显更好，因此权衡之下开源是值得的。“感谢你们”，献给所有帮助 Swift 发展进化的人。

• 预估 软件开发的进度（特别是开源项目）依然困难到近乎不可能。我们在着手开发 Swift 3 的时候设立了许多高目标，在后期不得不进行修整。设立一些高目标是好事，但我们需要在沟通上更努力，让其他人知道“目标”不等于“承诺”，避免误导他们。

• 整个社区得益于在有限的主题上保持专注，因为如果有太多事项同时进行，没有人可以持续跟进所有部分。参与到前面所提的关键讨论中，对核心团队而言非常重要。在 Swift 3 的开发周期中，很多人在代码评审结束前都没有时间来跟进讨论，这是一个问题。

• 确立清晰的目标是一种解脱。特别是在去年十二月到今年一月，我们大致圈出了那些适合放入 Swift 3 的点子，同时开启了几个项目，这些项目最后远超出我们的能力范围。在后来的版本中，我们确立了几个具体目标（比如“不再加入新计划”），使所有人能更轻松地关注重要事项。

• 皆大欢喜是不可能的，尤其是在我们讨论优先开发哪些功能时，因为这会降低其他一些功能的优先级。这是一个无解的局面，因为我们并没有办法将所有有意思的工作都放在一个只有一年长的开发周期中。幸运的是，将来“总会有下一个版本”，每一个新版本都会加入一些重大的改进。

在上述回顾的基础上，我们来展望未来！

Swift 发布计划

在接下来一年里，核心团队预计会发布两个主要的版本：2017 年春发布 Swift 3.x，2017 年秋发布 Swift 4。除了主要版本之外，我们也会发布一些小的更新（如 Swift 3.0.1）来修复 Bug，或满足核心库的需求，或其他的 swift.org 的项目。

Swift 4 发布计划

从我们在 Swift 3 中获得的经验来看，我们需要挑出一些重点。对 Swift 4 来说，主要目标是从 3.0 开始要保证交付的代码的稳定性，并为标准库提供 ABI 的稳定性。因此，核心团队决定在接下来的一年中实施两个阶段的计划：

第一阶段：专注于提升代码及 ABI 稳定性，全心投入只完成这项必要的工作。这意味着如果一些功能不会从根本上改变现有语言特性的 ABI ，或是对标准库的 ABI 进行了破坏性的改动，那么现阶段都不会考虑开发它们。举个例子，泛型中的条件一致性（Conditional conformances）是一个附加特性，但由于它会对标准库造成众多更改，我们在第一阶段就要实现它。另一方面，正则表达式不会对现有 ABI 造成影响，也不会给标准库带来大量改动，所以第一阶段不会考虑它。

第一阶段的工作非常重要（下面会详细介绍），所以春季之前我们大概一直会很忙。

第二阶段：当第一阶段功能的设计与实现工作较好得完成之后，我们将基于剩余时间，选择一些大型的功能进行开发。我乐观估计将有剩余时间，来从长长的功能列表中选几个来开发，但具体选哪几个，得看最后剩多少时间。

除了新功能之外，我们也需要重新评估那些在 Swift 3 中尚未实现的、对代码造成破坏性变动的提案。这些提案不一定会被通过，我们需要在 Swift 4 的基础上来评估它们，挨个决定如何处理。

最后，虽然与 Swift 的进步没有特别大的关系，但我想提一提质量与性能问题。核心团队想要进一步提升质量，包括修复编译器的 Bug、改进错误与警告检测功能。性能是开发中另一个需要重视的部分，包括提升编译后的代码质量，改善标准库的实现，加快编译速度等。这些工作在任何开发阶段都需要重视。

Swift 4 第一阶段目标

为了专注于代码与 ABI 的稳定性，核心团队对第一阶段的工作有一个初步的讨论。下面是我们对第一阶段功能排序后的结果：

• 代码稳定性相关功能：这一部分工作量相对较小，但很重要。举个例子，我们需要类似于“-std=swift3”的编译器标志。我们也需要一个新方法来开启一些大型的功能，这些功能尚在开发，并不稳定，有了这个方法，调试会更简单。

• 适应力（Resilience）：这个功能提供了一种方式，在保证 ABI 稳定性同时，公有 API 可以随时间改进。一个例子，我们不想让 C++ 的“fragile base class” 问题发生在 Swift 中。更多设计与实现上的工作已经在 Swift 3 中完成了，但仍有重要工作未完成，包括模型中用户可见的部分（例如新的属性）。

• ABI 细节：代码生成模型中仍有大量细节需要审核与改进。这一部分与 Swift 开发更相关，与 Swift 的演进关系不大。

• 泛型改进需要在标准库的基础上进行：我希望条件一致性能在功能清单中处在最高位置，递归协议要求（recursive protocol requirements）与更强大的关联类型约束能处在随后的相近位置。然而，标准库的开发者们需要大量时间来解析出至关重要的部分，最终消除那些“_”协议，并正确展现标准库中的公有 API。

• 字符串相关改进：字符串是 Swift 中最重要的基本类型之一。标准库的开发者有很多点子，能改进它的编程范式而不影响到提供 unicode-correct-by-default 范式。我们的目标是在字符串处理上比 Perl 做得更好！

• 内存所有权模型（Memory ownership model）：许多系统开发者，以及想要可预测及确定性的性能（如在实时音频处理中）的人们，都非常希望 Swift 中能有一个（可选的）类似于 Cyclone / Rust 的内存所有权模型。从 Swift 4 的目标上来说，这个功能很重要，因为它从根本上改变了 ABI。这一模型会通知编译器“inout”事件的产生，解释底层“addressors”如何在 ABI 中运作，影响 Swift runtime，并对类型系统及命名管理产生显著影响。

我们对上面这些功能都有了一些想法，但它们在正式成为提案之前仍有很长路要走。我期待它们会在 Swift 4 的早期成为主要讨论内容。不仅如此，由于我们还没有全部找出那些影响 ABI 稳定性的部分，可能还有其他需要增加的条件。最后，我们也可能选择其他一些对 SwiftPM 这个包管理器，或其他对 swift.org 有高价值的小功能。

可能的 Swift 4 第二阶段工作

如我之前所提到的，在这个点上不可能知道还有多少时间留给第二阶段，因此也不知道第二阶段能完成哪些工作。核心团队也希望比 Swift 3 更早完成 Swift 4 开发版的合流，以便在版本发布之前有更多时间修复 BUG，仔细斟酌。

也就是说，我乐观估计我们能够挑一些大家都想要的新功能来开发。为了让你对这些功能有个概念，我列了张表。请注意这并不是开发的计划或承诺，而只是列了一些大家都希望有的功能：

• 反射：核心团队正致力于为 Swift 添加强大的动态机制。举个例子，Swift 3 中大致完成了数据反射的基础结构（已被用在 Xcode 的 memory debugger 中）。我们应在这些基础结构之上，搭建一些强大的面向用户的 API。同样，我们想要设计并实现动态方法反射的 runtime 与 API 支持。

• 最重要的并发：Actors、异步 / 等待（async / await）、atomicity、内存模型（memory model）以及相关话题。这些是大家都想要的，因为有了它们，就可以在客户端、服务端等之上开发更多新功能。我们计划在第二阶段正式讨论这件事，但非常明确地告诉大家，新的并发模型在 Swift 4 发布时还无法完成。我们需要超过一年的时间来进行设计与开发，我们也希望把这件事做好做对。需要这么多时间，也是因为在开发内存所有权模型之前能更深入的理解它。

• 泛型改进：泛型的开发计划中包含来许多激动人心的功能，能改进现有泛型系统。在提升标准库的 ABI 稳定性时并不需要这些功能，但它们会使 Swift 的泛型更加强大易懂。

• .swiftmodule 的稳定性：在某些方面我们需要使“.swiftmodule”的二进制文件格式稳定下来（或用不同的机制替代它），允许开发第三方的二进制框架。这个工作量很大，并需要标准库 ABI 保持稳定。

• 新的脚本功能：包括正则表达式、多行字符串字面量等。有了这些功能，Swift 在密集型文本处理任务及搭建 web 等方面会更有吸引力。这些功能也有助于完善字符串模型。

• 属性行为：这一功能承诺为现有属性模型提供强大的抽象能力。在被推迟的 SE-0030 提案中对它有完整描述。

• 其他功能：子模块、数值类型间的隐式转换、导入 C++ API、hygenic macro system、尾调用约定、枚举类型遍历、带类型的“thorws”、用户定义属性、抽象方法 / 类、更好的 SIMD 支持、非 @objc 的动态支持、支持数据并行、更高等级的类型...

• 语法糖：我不会把它们全部列出来，但有大量零散的小提案会经常出现，特别是那些其他语言中出现过、用于解决特定问题的。这些在 Swift 4 开发中都属于最低优先级。

好了，这是一封超长的邮件，列出了一些关于明年要做的事的想法与点子。有一点要提醒一下大家，目前 Swift 3 尚未完成。当对代码的破坏性改动（将要）完成时，需要留有一些时间来修复 Bug 并提升代码质量，这对于正式发布版很重要。

我认为如果我们马上花一些时间来讨论明年开发计划的一些基本事项，会很有帮助，然后再从概念上分解一些第一阶段的特性。只有在对它们有深入了解之后，我们才应该开始写一些提案。核心团队不希望被太多提案淹没，以至于无法跟踪它们的进展，或让我们无法专注于那些高优先级的项目中。

谢谢大家。再次提醒一下，如果大家想要更深入讨论某个话题，请重新开一个分支。

本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 http://swift.gg。

Emoji 上的 Swift：换一种视角来理解 Swift 高阶函数

不久之前，Iain Delaney 给我发了这一幅图：

这幅由 Steve Luscher 设计的图，其内容来源于 Joey Devilla 的博客 Global Nerdy 中的一篇文章。我觉得这种做法相当有才，让人眼前一亮。

然而，这幅图不是用 Swift 编写的，显然没办法在 Swift 中运行。我决定娱乐一番：我建立了一个 Playground，将大量的 Emoji 字符分配到对应的 Emoji 变量当中，由此构建了一个庞大的列表，然后使用 Swift 的语法让这些例子能够正确运行。

我决定听从 Jaden Geller 在 Twitter 上的所提出的建议，我没有使用便便?来表示 reduce 操作，因为这原先会让人理解为：在每个 reduce 操作执行的时候，都是将便便和一个新的食物合起来一同「吃下」。在 Swift 的版本当中，reduce 将从一个悲伤的表情?开始，最后变得高兴和满足?。

我尝试加了更多的食物种类，看看是否值得扩展一下图片上的内容，但是我发现一旦示例数量超过了原先的 4 种食物，就不够干净和优雅了：

我决定不再使用奶牛?、土豆?、小鸡?和玉米?，我想看一看是否存在一个比 isVegetarian 更好的 filter 选项。比如说孩子们将会选择自己爱吃的食物（往往并不营养）：

然后我又想到，那么为什么不再多加一些 Swift 语言的特性呢？于是我决定描述一下可变和不可变项目操作的概念：

以及重复操作：

还有排序操作（虽然我觉得这里可能换用别的食物会更好一些）：

当然了，zip 操作同样很赞：

然后还有 map 与 flatMap 的对比：

很遗憾的是，足球并不是一个合法的字符标识符，所以我无法在足球和橄榄球之间执行 bitcast 操作。这种不一致的 Emoji 字符集让我很不开心。Swift 需要对操作符和标识符进行基于标准的改造。

当我在鼓捣 fatalError 的时候，我发现我的时间都耗费在这里了：

不知道您是否有喜爱的 Swift 功能，想用 Emoji 将其表示出来吗？我已经向大家展示了我的想法。现在，是时候展示您的想法了。

更新：Phil Aaronson 建议还可以使用 emoji 函数。

@ericasadun functions too! pic.twitter.com/IDwDBps2WD

— Phil Aaronson (@phildrone) November 8, 2016

理想情况下，这些示例应当都可以在 Swift Playground 当中编译运行，我同样赞同使用其他 Emoji 来阐述这些功能，即使实现起来相当棘手。

本文由 SwiftGG 翻译组翻译，已经获得作者翻译授权，最新文章请访问 http://swift.gg。

iOS Swift 应用程序随机 EXC_BAD_ACCESS 崩溃：swift_bridgeObjectRetain swift_retain swift::RefCounts

如何解决iOS Swift 应用程序随机 EXC_BAD_ACCESS 崩溃：swift_bridgeObjectRetain swift_retain swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>

我不断收到来自随机用户的随机崩溃报告。不幸的是，我无法定期重现这一点。用户说崩溃是在 discussionViewController 中随机发生的。所有崩溃报告都有类似的内容：

0   libswiftCore.dylib              0x00000001a53face4 swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::incrementSlow(swift::RefCountBitsT<(swift::RefCountInlinedness)1>,unsigned int) + 60 (atomic:1003)
1   libswiftCore.dylib              0x00000001a53c59e0 swift_retain + 124 (RefCount.h:813)
2   libswiftCore.dylib              0x00000001a5401d60 swift_bridgeObjectRetain + 56 (SwiftObject.mm:585)
3   APPNAME                             0x0000000102b59734 closure #1 in discussionViewController.fetchPostData() + 7916

这是完整的崩溃日志和崩溃的线程：

Hardware Model:      iphone11,6
Process:             APPNAME [11770]
Path:                /private/var/containers/Bundle/Application/.../APPNAME.app/APPNAME
Identifier:          ----
Version:             62 (62)
AppStoretools:       12E262
AppVariant:          1:iphone11,6:13
Code Type:           ARM-64 (Native)
Role:                Foreground
Parent Process:      launchd [1]
Coalition:           ---- [1824]


Date/Time:           2021-06-17 12:07:01.4346 +1000
Launch Time:         2021-06-17 12:06:56.4993 +1000
OS Version:          iPhone OS 14.6 (18F72)
Release Type:        User
Baseband Version:    3.04.01
Report Version:      104

Exception Type:  EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x8000000000000010 -> 0x0000000000000010 (possible pointer authentication failure)
VM Region Info: 0x10 is not in any region.  Bytes before following region: 4339515376
      REGION TYPE                 START - END      [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      UNUSED SPACE AT START
--->  
      __TEXT                   102a7c000-102a94000 [   96K] r-x/r-x SM=COW  ...APPNAME.app/APPNAME

Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL,Code 0xb
Terminating Process: exc handler [11770]
Triggered by Thread:  3


Thread 3 name:
Thread 3 Crashed:
0   libswiftCore.dylib              0x00000001a53face4 swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::incrementSlow(swift::RefCountBitsT<(swift::RefCountInlinedness)1>,unsigned int) + 60 (atomic:1003)
1   libswiftCore.dylib              0x00000001a53c59e0 swift_retain + 124 (RefCount.h:813)
2   libswiftCore.dylib              0x00000001a5401d60 swift_bridgeObjectRetain + 56 (SwiftObject.mm:585)
3   APPNAME                             0x0000000102b59734 closure #1 in discussionViewController.fetchPostData() + 7916
4   APPNAME                             0x0000000102ad09d4 thunk for @escaping @callee_guaranteed (@guaranteed Data?,@guaranteed NSURLResponse?,@guaranteed Error?) -> () + 132 (<compiler-generated>:0)
5   CFNetwork                       0x00000001a1b0a3dc __40-[__NSURLSessionLocal taskForClassInfo:]_block_invoke + 540 (LocalSession.mm:687)
6   CFNetwork                       0x00000001a1b1c768 __49-[__NSCFLocalSessionTask _task_onqueue_didFinish]_block_invoke + 244 (LocalSessionTask.mm:584)
7   libdispatch.dylib               0x00000001a10d1a84 _dispatch_call_block_and_release + 32 (init.c:1466)
8   libdispatch.dylib               0x00000001a10d381c _dispatch_client_callout + 20 (object.m:559)
9   libdispatch.dylib               0x00000001a10db004 _dispatch_lane_serial_drain + 620 (inline_internal.h:2557)
10  libdispatch.dylib               0x00000001a10dbc34 _dispatch_lane_invoke + 456 (queue.c:3862)
11  libdispatch.dylib               0x00000001a10e64bc _dispatch_workloop_worker_thread + 764 (queue.c:6589)
12  libsystem_pthread.dylib         0x00000001ed04a7a4 0x1ed047000 + 14244
13  libsystem_pthread.dylib         0x00000001ed05174c 0x1ed047000 + 42828

我已验证 discussionViewController.fetchPostData() 不会强制解开任何可选选项，没有 try! 并且在任何地方都使用 [weak self] 和 self?。该函数非常大，所以我很难缩小崩溃发生的范围。

我们今天的关于swift 可选值和swift可选类型的分享就到这里，谢谢您的阅读，如果想了解更多关于AWESOME SWIFT-swift.libhunt.com-swift类库网站、Chris Lattner 对 Swift 3 的总结与对 Swift 4 的展望、Emoji 上的 Swift：换一种视角来理解 Swift 高阶函数、iOS Swift 应用程序随机 EXC_BAD_ACCESS 崩溃：swift_bridgeObjectRetain swift_retain swift::RefCounts的相关信息，可以在本站进行搜索。