標籤: UnsafeMutablePointer

Swift 3.1正式發佈

Swift 3.1在今(2017/3/28)正式發佈！3.1是次要的更新版本，主要針對目前的標準函式庫做改善以及改進。
在IBM以及各社群成員的努力下，還包含了Swift on LINUX的更新。以及部份的Swift Package Manager更新~
此外在編譯器也加上預編譯Objective-C的功能，讓編譯速度加快~

更多訊息可參考原始文章
https://swift.org/blog/swift-3-1-released/

 

 

New Sequence protocol members

The Sequence protocol now has two new members:

protocol Sequence {
  // ...
  /// Returns a subsequence by skipping elements while `predicate` returns
  /// `true` and returning the remainder.
  func drop(while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence
  /// Returns a subsequence containing the initial elements until `predicate`
  /// returns `false` and skipping the remainder.
  func prefix(while predicate: (Self.Iterator.Element) throws -> Bool) rethrows -> Self.SubSequence
}

See more at: SE-0045: Add prefix(while:) and drop(while:) to stdlib

Availability by Swift version

Swift 3.1 extends the @availability attribute to use the version of Swift to indicate the lifecycle of a declaration. As an example, an API that is removed in Swift 3.1 would be written as:

@available(swift, obsoleted: 3.1)
class Foo {
  //...
}

See more at: SE-0141: Availability by Swift version

Improved numeric conversion initializers

Swift 3.1 adds a new family of conversion initializers to all numeric types that either complete successfully without loss of information or return nil.

See more at: SE-0080: Failable Numeric Conversion Initializers

Deprecation and replacement of UnsafeMutablePointer.initialize(from:)

The version of UnsafeMutablePointer.initialize(from:) that takes a Collection is deprecated in favor of a new method on UnsafeMutableBufferPointer that takes a Sequence, with a goal of improving memory safety and enabling faster initialization of memory from sequences.

See more at: SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer

Improvements to the Linux implementation

  • Implementation of NSDecimal
  • Implementation of NSLengthFormatter
  • Implementation of Progress
  • Many improvements to URLSession functionality, including API coverage and optimized usage of libdispatch
  • Improved API coverage in NSArray, NSAttributedString and many others
  • Significant performance improvements in Data. See more details here
  • Improved JSON serialization performance
  • Memory leaks fixed in NSUUID, NSURLComponents and others
  • Improved test coverage, especially in URLSession

Package Manager Updates

Editable packages

Package dependencies are now stored in the tool-managed build directory by default, and a new swift package edit command allows users to “begin editing” on a package, moving it under the user’s control (into the Packages directory), exempting it from dependency updates, and allowing the user to commit and push changes to that package.

See more at: SE-0082: Package Manager Editable Packages

Version pinning

The version of each dependency you’ve used is now recorded in a Package.pins file, which can be checked in to share those versions with other users of your package; swift package pin and swift package unpin commands provide further control. The pinned versions of a package’s dependencies are fetched by default when resolving dependencies, but swift package update will re-resolve to the latest allowable dependency versions and update the pinfile.

See more at: SE-0145: Package Manager Version Pinning

Tools version

Packages can now specify the minimum version of the Swift tools that they require. This requirement can be edited with the swift package tools-version command and is recorded at the top of the Package.swift manifest. Package versions which require newer Swift tools than those in use will be ignored by dependency resolution, so packages can adopt new Swift features without breaking clients who are using older Swift tools. The minimum tools version required determines which Swift language version is used to interpret the Package.swift manifest, and which version of the PackageDescription API is available.

See more at: SE-0152: Package Manager Tools Version

Swift language compatibility version

Packages can now specify whether their sources are written in the Swift 3 or Swift 4 language version. If not specified, a default is inferred from the Package’s minimum Swift tools version.

See more at: SE-0151: Package Manager Swift Language Compatibility Version

Other Package Manager improvements

  • Package dependency resolution is now correct in cases where it could have resolved to incorrect dependency versions previously. Dependency cycles are now detected during a build, and incremental builds will rebuild fewer sources when possible.
  • swift test now supports running tests in parallel with the --parallel flag. swift build, swift test, and all swift package commands which resolve dependencies now support fetching those dependencies in parallel with the --enable-prefetching flag.

Documentation for the Swift Package Manager can be found in the repository.

Migrating to Swift 3.1

Swift 3.1 is source compatible with Swift 3.0. To help with moving to Swift 3.1 from earlier releases of Swift, Xcode 8.3 contains a code migrator that can automatically handle many of the need source changes. There is also a migration guide available to guide you through many of the changes — especially through the ones that are less mechanical and require more direct scrutiny.

Documentation

An updated version of The Swift Programming Language for Swift 3.1 is now available on Swift.org. It is also available for free on Apple’s iBooks store.

Platforms

Linux (Ubuntu 14.04, Ubuntu 16.04 and Ubuntu 16.10)

Official binaries for Ubuntu 14.04, Ubuntu 16.04 and Ubuntu 16.10 are available for download.

Apple (Xcode)

For development on Apple’s platforms, Swift 3.1 ships as part of Xcode 8.3.

Sources

Development on Swift 3.1 was tracked in the swift-3.1-branch on the following repositories on GitHub:

The tag swift-3.1-RELEASE designates the specific revisions in those repositories that make up the final version of Swift 3.1.

The swift-3.1-branch will remain open, but under the same release management process, to accumulate changes for a potential future bug-fix “dot” release.