Issue #63

Datetime:2017-03-31 05:35:24         Topic: Xcode  Objective-C          Share        Original >>
Here to See The Original Article!!!

The big news this week was that Swift 3.1 was officially released! Congratulations to the Core Team and open source contributors! This was a huge effort and aside from the notable features and proposals, there were dozens of bug fixes and other improvements. Be sure to report any bugs, regressions, or other issues that you run into.

Sponsored Link

Building Reactive Apps with Realm

In this five-episode tutorial series, Marin Todorov guides us on a sample app project in Swift to see how Realm facilitates building reactive Swift apps from the ground up.

Swift Unwrapped

Episode 4: Bridging with Objective-C

This week we discuss bridging! There’s been a constant push and pull on Objective-C bridging since Swift 1.x, trying to seek a balance but always swaying in the other direction.

News and community

Swift 3.1 was officially released !

Swift 3.1 is a minor release that contains improvements and refinements to the Standard Library. Thanks to efforts by IBM and other members of the community, it also includes many updates to the Linux implementation of Swift. There are also a number of updates to Swift Package Manager.

Swift 3.1 includes the following proposals:

Xcode 8.3 was released along with updates to all of Apple’s platforms. Xcode 8.3 ships with Swift 3.1.

It looks like JP Simard has already found an issue in Xcode 8.3. “Xcode 8.3 produces binaries 3x larger than Xcode 8.2 due to a 4x increase in bitcode.” Oops. :flushed: ( rdar://31302382 )

Bas Broekwrote a post on the cost of Swift evolution, highlighting this Twitter thread with Austin Zheng and Slava Pestov. This is something I’ve discussed before as well. It’s important to recognize that there is a huge opportunity cost to swift-evolution, that is, the cost of each change are those changes we give up in return. This is especially true regarding features/proposals that don’t align with Swift’s roadmap, or theme . As Slava points out , the Core Team needs (and deserves!) time to focus on bug fixes, performance improvements, and addressing technical debt. Personally, I wouldn’t mind seeing fewer proposals, or as Bas suggests, a temporary halt on swift-evolution. Having said that, I think the team has so far managed Swift 4 much better than Swift 3, which included a ton of proposals.

Commits and pull requests

Philippe Hausler ( @phausler ) opened a pull request to rework the backing storage for CharacterSet to be more performant and bridge correctly to Objective-c and CoreFoundation.

Doug Gregor ( @dgregor79 ) implemented the majority of SE-0160 : Limiting @objc inference .

Hugh Bellamy ( @hughbe ) has continued working hard to get Swift working on Windows and submitting a number pull requests to swift, swift-llvm, swift-lldb, and other repos for weeks (maybe months?) now. This week, he has a grim update to get the update-checkout script working on Windows.

Slava Pestov ( @slava_pestov ) merged SILGen fixes for static Self -returning methods. This is a crazy fix that I don’t completely understand. :sweat_smile: The first line of the commit says it all, “Take a seat and pour yourself a beer because this is going to get pretty intense.”

Proposals

No official proposal decisions, although the review periods for SE-0159 and SE-0160 have ended. We’re still waiting on official emails from the Core Team.

Mailing lists

There’s still been heavy debate on the lists over SE-0159 : Fix Private Access Levels . The core arguments that I coveredlast week haven’t changed so I’ll avoid belaboring them. The review period was supposed to end on March 27, so we should see a decision from the Core Team soon. My impression is that these discussion sort of burnt out the community as the lists have been relatively quiet since. :smile:

Ben Cohen pitched a draft proposal that intends to implement a subset of changes from the Swift 4 String Manifesto .

This proposal is to implement a subset of the changes from the Swift 4 String Manifesto.

Specifically:

  • Make String conform to BidirectionalCollection
  • Make String conform to RangeReplaceableCollection
  • Create a Substring type for String.SubSequence
  • Create a Unicode protocol to allow for generic operations over both types.
  • Consolidate on a concise set of C interop methods.
  • Revise the transcoding infrastructure.

Other existing aspects of String remain unchanged for the purposes of this proposal.

Finally

And finally — static typing .








New