对Swift 3有何期待

最新推荐文章于 2024-10-02 10:53:34 发布

cunjie3951

最新推荐文章于 2024-10-02 10:53:34 发布

阅读量132

点赞数

文章标签： python 人工智能 java 编程语言大数据

您可能知道Swift 3将于今年晚些时候问世。这是包含梦幻般社区的辛勤工作的第一个版本。自2015年Apple开源Swift以来，已经提交了数十个提案，经过核心团队的仔细考虑，数十个提案被接受。在本文中，我们将介绍Swift 3中的一些重要更改。

Swift 3是关于什么的？

随着Swift 3的发布，核心团队的目标非常明确，为Swift编程语言奠定了坚实的基础。在WWDC 2016上，克里斯·拉特纳（ Chris Lattner）强调，Swift 3引入了一系列突破性的变化，目的是使基本原理正确。这是即将发布的版本的共同主题。这意味着要破坏现有功能，删除某些功能并改善语言的基础。

Swift演变项目对于参与Swift社区的每个人都是一个成功的故事。参与度非常高，结果就是Swift3。Apple对发布过程保持透明，可以从Swift网站上获得Swift 3的快照，该快照包含在Xcode 8中，Xcode 8在撰写本文时处于beta版。

不只是Swift

Swift 3版本不仅专注于Swift编程语言，还包括对工具链，标准库以及该语言与Cocoa的互操作性的重大更改。请记住，Swift不仅仅是一种语言。在谈论Swift时，通常只考虑语言，但它也包括标准库和包管理器。

源兼容性

如果您使用过Swift，那么您就会知道将代码库从一个版本迁移到另一个版本并不是一件容易的事。不幸的是，将项目迁移到Swift 3并没有什么不同。

也就是说，Swift 3的主要目标是确保从Swift 3到该语言的未来版本的过渡不会像那样。源代码兼容性是Swift 3的重点。

很棒

Swift被设计为一种现代编程语言，但是创建看起来不错并且很好……很棒的语言同样重要。像Chris Lattner所说的那样，借助Swift 3，团队继续“优化语言以达到令人敬畏的目的”。

尽管发生了许多重大变化，但最终的结果是一种感觉良好的语言。 Swift 3使用起来很有趣。我们稍后讨论的对Core Graphics和Grand Central Dispatch的更改就是很好的例子。

发生了什么变化？

Swift真棒，Swift 3真棒。在本文的其余部分中，我将重点介绍Swift 3中引入的一些关键更改。请记住，Swift 3会继续发展，直到今年晚些时候正式发布为止。

API

可读性

大量时间和精力花费在改进Swift语言的API上。变化是重大的，无可否认。但是结果非常非常好。借助Swift 3，核心团队的目标是开发一个注重可读性和可访问性的API。

尽管我们许多人已经习惯了Objective-C的冗长性，但新的Swift API仅通过强调和关注基本要素而采用了不同的方法。看一下下面的Swift 2.2.1示例。如果您花了一些时间使用Swift ...或Objective-C，则此示例应该看起来很熟悉。

parentViewController.presentViewController(newViewController, animated: true, completion: nil)

在Swift 3中，此代码段看起来略有不同，如下所示。

parentViewController.present(newViewController, animated: true, completion: nil)

Swift社区意识到，由于该信息已经包含在第一个参数中，因此无需引用将要呈现的内容。结果，方法名称变得更加可读和简洁。如果你问我的话，肯定有进步。

这是Swift 3中的一个通用主题。Swift 3中接受并包含的一些建议集中在简化和消除语言的混乱之处上。 Swift API最初受到Objective-C冗长性质的严重影响。可读性很好，但是Swift 3减少了冗长性，同时又不影响可读性。

Swift社区认为，API的设计应始终考虑到API的使用，并且在Swift 3中引入的更改中可以清楚地看出这一点。我确信您同意经过修改的API看起来很明显，并且读-很棒。

标签参数

许多开发人员欢迎的另一个重要更改是功能和方法的一致签名，默认情况下通过包含第一个参数标签来实现。这就是Swift 2.2.1中的典型函数。默认情况下，调用该函数时将省略第一个参数标签。

func setupView(view: UIView, withConfiguration configuration: Configuration) {
    // ...
}

setupView(view, withConfiguration: configuration)

在Swift 3中不再是这样。第一个参数不再经过特殊处理，这是一个非常受欢迎的更改。

func setupView(view: UIView, withConfiguration configuration: Configuration) {
    // ...
}

setupView(view: view, withConfiguration: configuration)

由于此更改，您可以通过在函数名称中省略对视图的引用来进一步改进上述示例。

func setup(view: UIView, withConfiguration configuration: Configuration) {
    // ...
}

setup(view: view, withConfiguration: configuration)

导入为会员

在Swift中使用C API看起来总是很笨拙。例如，Core Graphics函数作为全局函数导入，这不是一个很好的解决方案，因此，在Swift中使用Core Graphics感觉并不好。

大中央调度也是如此。在下一个示例中，我们使用Grand Central Dispatch将任务异步分配到后台队列。

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND, 0)) { 
    // ...
}

在Swift 3中，该API感觉更像是本机Swift API。函数作为方法导入，这在Swift 3中产生以下语法。

DispatchQueue.global(attributes: .qosBackground).async { 
    // ...
}

删除功能

Swift社区还同意删除许多功能，其中一些引发了激烈的讨论。我想指出其中的四个。

C风格`for`循环

这看起来对您熟悉吗？

for (var i = 0; i < 5; i++) {
    print(i)
}

Swift 3中不再提供C样式for循环。请稍候。什么？为什么？这是一个很好的问题。您可以在GitHub上阅读Erica Sadun提交的提案。这将我们带入下一个有争议的变化。

向`++`说再见`--`

Swift开源后不久，Swift的创建者Chris Lattner 提交了一项提案，要求从该语言中删除递增和递减运算符。在他的建议中，他提到在Swift的早期开发中，“无需过多考虑”就添加了这些运算符。为了清理Swift API并避免混淆， ++和--在Swift中不再可用。

var a = 0
a++

不过不要惊慌。解决方案很简单。不用担心。

var a = 0
a += 1

没有更多的`var`参数

如果您熟悉Swift中的函数，则知道函数的参数默认情况下是常量。您可以通过在参数名称前添加var关键字来更改此行为。对于可变参数，参数的可变副本将传递给函数。

但这与标记为inout参数有何不同？对。这正是我们许多人一直想知道的，这是从语言中删除可变参数的动机。

从函数的角度来看，没有什么区别，即函数接收参数值的可变本地副本。但是，顾名思义，标记为inout的参数会将其值写回到原始变量。

为避免混淆，在Swift 3中var参数不再可用。幸运的是，这里保留inout参数。

说到inout参数，在Swift 3中， inout关键字集成在函数参数的类型语法中。请看以下示例，以更好地理解此更改。

// Swift 2
func combineStrings(inout first: String, second: String) {
    // ...
}

// Swift 3
func combineStrings( first: inout String, second: String) {
    // ...
}

隐式元组Splat行为

尽管Swift仍然很年轻，但是许多功能还是相当先进的。您是否知道可以将元组传递给函数而不是参数列表？不过，没有必要加油。此功能将在Swift 3中删除。

// Pass Arguments As Separate Arguments

let view = UIView()
let configuration = Configuration()

setupView(view, withConfiguration: configuration)

// Pass Arguments As Part of Tuple

let tuple = (view, withConfiguration: configuration)

setupView(tuple)

克里斯·拉特纳（Chris Lattner）在删除功能的建议中将此行为称为“可爱”。尽管此行为有时会有用，但似乎会产生很多后果。提出此建议的原因是为了突出核心团队的主要目标，简化语言的语法和API。

我可以看到该功能最初看起来很整洁，但是随着语言的发展，复杂性的增加以及越来越多的人开始使用它，诸如此类的功能为语言增加了有限的价值，以换取似乎是一连串的复杂性，包括编译期间的性能问题以及类型检查器的复杂性，可以通过省略功能来避免。