灯塔实验室

Swift是苹果在WWDC 2014上突然宣布的一种新编程语言。Swift自身很多有趣的特性已经引起不少开发者的追捧。关于Swift火热的最直接证据就是：github上的Swift开源项目在一周中已经逼近700个。

上一次灯塔实验室分享了一些关于Swift的有趣观点。Swift很讨巧，给人以一种简洁、有力的第一观感。看着其他小伙伴已经一日千里地奔着Swift去了，你已经跃跃欲试了？别急，今天来给大家降降温。须知硬币都有正反面，Swift在给予开发者便利的同时，也精心准备了诸多深坑供大家玩耍。

~我们已经可以扔掉Objective-C了么？~

Optional：安全与便利的悖论

Swift以带问号的语法引入了optional类型，主责是将未初始化变量以一种主动的形式迫使开发者知晓。而开发者若想使用optional，即“允许未初始化”的变量时，必须使用感叹号来进行取值，也就是所谓的unwrap。

var illegalString :String = nil // 编译错误
var legalString :String? = nil

func genString(bar :Int) -> String?
{
    if bar > 30
    {
        return "abc"
    }
    else
    {
        // 如果可以返回nil，必须强制返回类型为optional
        return nil
    }
}

var a: String = genString(50)! // 必须进行取值操作，否则类型不匹配
var b: String? = genString(0)

苹果在设计Swift的时候，将安全摆在了一个相当重度的位置，从而牺牲了语言的随性。寄希望于Swift能更像脚本语言那样随意编写的同学，可能会在optional这里感受到来自语言设计者的恶意。

第二参数名：另一个名字还是历史的包袱？

这个问题还算比较良性。我们通常写带参数的函数是这样

//这样很好，与世无争
func foobar(a: Int, b: String) -> String {...}

但是，皇上您还记得大明湖畔的夏雨荷么？

- (instancetype)initWithBytes:(const void *)bytes length:(NSUInteger)length encoding:(NSStringEncoding)encoding

多么令人怀念的老时光。Swift为了要兼容Objective-C/Cocoa，也搞出了类似的东西，称之为“外部参数名”：

class Matrix
{
    func doMultiplication(str :String, 
                          fromData data1 :Int[], 
                          withData data2: Int[])
    {
        // do something
    }
}

let m = Matrix()
m.doMultiplication("My Matrix", fromData:[1,1,0,1], withData:[1,1,2,3])

从第二个参数开始，每个参数还有内外两个名字？这种丑到爆的语法真是历(nan)史(yi)沉(tu)疴(cao)啊╮(╯▽╰)╭

初始化：安全第一，好用第二

毫无意外地，Swift是一门（带少量函数式编程特性的）面向对象语言。同样毫无意外地，Swift类必须安装有初始化函数init。秉承前面optional带来的安全理念，开发者对于init的编写也有诸多规定，也就演化出了特定初始化函数和便利初始化函数，以及随之而来的convenience关键字。

class Item
{
    let name :String
    
    init(givenName name:String)
    {
        self.name = name
    }
}

var item = Item(givenName: "GeneralItem")

class Grenade : Item
{
    let explosive :Int
    init(givenName name: String, withExplosive explosive: Int)
    {
        self.explosive = explosive
        // 必须在子类初始化完毕所有成员后,再调用
        // 基类的构造；否则编译错
        super.init(givenName: name) 
    }
    
    convenience init(explosive: Int)
    {
        // 所谓的便利构造函数只能调用子类的特定构造函数，
        // 并不能涉及到基类构造；否则编译错
        self.init(givenName:"MyGrenade", withExplosive:explosive)
    }
}

let grenade1 = Grenade(givenName: "MyGrenade", withExplosive: 500)
let grenade2 = Grenade(explosive: 300)

写个初始化函数这么麻烦？为了安全，就得这么麻烦！其实不只是初始化，为了安全，连简单的switch结构也必须写default，这安全与好用的功与过，就全凭使用者来评判了。

ARC：自动引用计数带来的烦恼

苹果从Objective-C时代就引入了辅助对象生命期管理的自动引用计数(ARC)机制。Swift也一并继承了ARC。虽然ARC有轻量化、行为可预测、没有垃圾回收机制卡顿的优势，但也带来了很要命的问题：无法自行解决循环引用问题——从而引起内存泄露。

内存泄露难以跟踪、忽隐忽现又破坏力极大，它无疑是程序员最恐怖的梦魇。无奈之下，Swift引入了两个关键字weak和unowned，修饰不会自动增加引用计数的变量，来解决循环引用问题。

class Person
{
    let name: String
    var buff: Buff?
    
    init(name: String)
    {
        self.name = name
    }
    
}
// 施加在人物身上的buff技能
class Buff
{
    let id: Int
    weak var target: Person?
    
    init(id: Int)
    {
        self.id = id
    }
}
var me = Person(name: "Jon Blow")
var buff = Buff(id: 42)
me.buff = buff

然而游戏中buff是跟着人走的。没有人就谈不上buff，这就意味着Buff类中target设置为optional是不合适的。更好的做法是使用unowned。

class Person
{
    let name: String
    var buff: BetterBuff?
    
    init(name: String)
    {
        self.name = name
    }
    
}
class BetterBuff
{
    let id: Int
    unowned let target: Person
    
    init(id: Int, withTarget target: Person)
    {
        self.id = id
        self.target = target
    }
    
}
var me = Person(name: "Jon Blow")
me.buff = BetterBuff(id: 42, withTarget:me)

这里友情提醒一句，解决普通对象之间的循环引用只是战斗的开始。Swift是门现代语言，函数和闭包都是一等公民，所以后面还有闭包之间的循环引用等着勇敢的程序员们。

其他

另外还有一些语言特性看上去新奇，但基本上只能算是Objective-C的翻版，例如protocol和extension，基本上是复制了Objective-C的protocol和category，并没有为解放程序员的双手带来更多好消息。 值得一提的倒是外围特性：Playgrounds。Playgrounds并不是Swift语言自带的功能，而是Xcode 6中一种新工程形态。如果不是发布会上那惊鸿一瞥，Playgrounds恐怕会湮没在众多新特性的海洋之中。Playgrounds是促进苹果整个生态系统的一个巨大进步，它为Swift配置了动态语言的专利——交互式环境。而且还像matlab这类软件一样，Playgrounds提供数值视觉化效果，这类难能可贵的“所见即所得”，让游戏的细调的工作变得如捏橡皮泥搬简单。虽然Playgrounds之后会否发展成为一个单独的编辑器，我们不得而知，但Swift+Playgrounds+Sprite Kit毫无疑问已经向Corona这类二线游戏引擎产生了致命的冲击——一个飞速发展的生态圈内，是容不下弱者的。

说起来，Xcode 6 beta中的Playgrounds还非常地不稳定，没有足够的勇气不要轻易尝试哦~

未来

讲了这么多Swift的坏话，回过头来我们还是要认真评估一下它的未来：尽管Swift有着这样那样的妥协、不足，但它仍将是2014年增长速度最快的语言，没有之一，就像沉默十几年的Objective-C在iPhone开发热潮兴起之时，一瞬间成为了世界的宠儿。且不说，Swift所依赖的开源编译系统LLVM，也是目前编译器界最受瞩目的项目。他的创造者Chris Lattener，也就是那个WWDC上演示Playgrounds的默默无闻的天才少年，已经多次被ACM协会授予编译器、语言、系统方面的奖项。他在编译器、语言生态系统的远见卓识，让LLVM在原先强大的业界标准——GCC编译系统面前迅速崛起。不用猜，目前我们Xcode使用的编译系统正是LLVM。

行文至此，我们可以初步得出结论：Swift是一门脱胎自Objective-C的语言，带有浓厚的Objective-C/Cocoa的痕迹，也遵循了前辈的一些设计哲学，但同时拥有强大的现代语言特性。在权衡了易用性和安全性的前提下，做到了一定的动态语言的功能——不能说是尽善尽美。它的底层由强大且开放的LLVM支撑，外围又有Xcode所带来的Playgrounds让开发者立即上手。凭借苹果的开发生态圈，Swift必将以极快的速度取代Objective-C成为苹果平台开发的首选。至于Swift是否有望扩展到其他平台，WWDC并没有给予我们答案。参考苹果之前的作风，恐怕其底层库Cocoa移植的可能性不大。但由于LLVM的存在，Swift以开源编译器的形态，舍弃Cocoa而出现在各家平台上的可能性还是很大的。