Skip to content

Commit e16e5a6

Browse files
authored
[44] publish issue 44 (SwiftWeekly#117)
1 parent 50ce161 commit e16e5a6

File tree

1 file changed

+20
-9
lines changed

1 file changed

+20
-9
lines changed

_drafts/2016-10-27-issue-44.md renamed to _posts/2016-10-27-issue-44.md

Lines changed: 20 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ author: jsq
66

77
What a week for Swift! Swift 3.0.1 is here, but what's more exciting is the new [Server APIs Work Group](https://swift.org/blog/server-api-workgroup/) and [Server APIs Project](https://swift.org/server-apis/) from Swift.org! See below for details. The Xcode 8.1 GM seed [was released](http://adcdownload.apple.com/Developer_Tools/Xcode_8.1_GM_Seed/Release_Notes_for_Xcode_8.1_GM_Seed.pdf), which bundles Swift 3.0.1. There are a number of improvements in Swift 3.0.1, including [SE-0138](https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md), [SE-0139](https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md) and [SE-0140](https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md). Check the release notes for more information. Additionally, [iOS 10.1](http://www.macrumors.com/2016/10/24/apple-releases-ios-10-1-with-new-portrait-mode/) and [macOS Sierra 10.12.1](http://www.macrumors.com/2016/10/24/apple-releases-macos-sierra-10-12-1/) had their final releases.
88

9-
In other news, Apple is holding a ["Mac-centric" event](http://www.macrumors.com/2016/10/19/apple-announces-october-27th-mac-centric-event/) this morning where they are expected to announce new Macs. A lot of people have been waiting for this, so let's hope it's good! I'm still crossing my fingers for an updated Thunderbolt display. 🤓
9+
In other news, Apple is holding a ["Mac-centric" event](http://www.macrumors.com/2016/10/19/apple-announces-october-27th-mac-centric-event/) this morning where they are expected to announce new Macs. I know a lot of developers in the community have been waiting for this. I'm still crossing my fingers for a new Thunderbolt display. 🤓 Let's hope the announcements are good!
1010

1111
<!--excerpt-->
1212

@@ -16,20 +16,19 @@ In other news, Apple is holding a ["Mac-centric" event](http://www.macrumors.com
1616

1717
> Since Swift became available on Linux there has been a huge amount of interest in using Swift on the server, resulting in the emergence of a number of Web Frameworks, including Kitura, Vapor, Perfect, and Zewo, along with many others. As an important part of the Swift ecosystem, and one that we are keen to foster, we are today announcing the formation of the Server APIs work group.
1818
19-
The [Server APIs Project](https://swift.org/server-apis/) looks like an amazing step forward for advancing Swift on the server and it's being driven by the community. The project's goal is to provide core APIs (base networking, security and encryption, HTTP and WebSockets) for server development &mdash; think [corelibs-foundation](https://github.com/apple/swift-corelibs-foundation), but for the server. The [Work Group](https://swift.org/server-apis/#work-group) is composed of a Steering Team and Stakeholders, including representatives for all of the popular Swift web frameworks &mdash; [IBM Kitura](https://github.com/IBM-Swift/Kitura), [Vapor](https://github.com/vapor/vapor), [Zewo](https://github.com/Zewo/Zewo), and [Perfect](https://github.com/PerfectlySoft/Perfect). It's really great to see the leaders from each of these projects come together to establish and collaborate on common, core functionality.
20-
There's more information on the new [project page](https://swift.org/server-apis/).
19+
The [Server APIs Project](https://swift.org/server-apis/) looks like an amazing step forward for advancing Swift on the server and it's being driven by the community. The project's goal is to provide core APIs (base networking, security and encryption, HTTP and WebSockets) for server development &mdash; think [corelibs-foundation](https://github.com/apple/swift-corelibs-foundation), but for the server. The [Work Group](https://swift.org/server-apis/#work-group) is composed of a Steering Team and Stakeholders, including representatives for all of the popular Swift web frameworks &mdash; [IBM Kitura](https://github.com/IBM-Swift/Kitura), [Vapor](https://github.com/vapor/vapor), [Zewo](https://github.com/Zewo/Zewo), and [Perfect](https://github.com/PerfectlySoft/Perfect). It's really great to see the leaders from each of these projects come together to establish and collaborate on common, core functionality. Until now, server-side Swift has been very ad hoc and fragmented. I think formalizing this aspect of Swift with official support from Swift.org will only increase the momentum behind making Swift a first-class citizen (and first-choice for developers) on the server. If this doesn't position server-side Swift for success, I don't know what does. There's more information on the new [project page](https://swift.org/server-apis/).
2120

2221
> The Server APIs project will provide core capabilities in areas such as networking and security so Swift programs no longer need to frequently rely on platform-specific C libraries to provide this functionality. As a result, developers will be able to create frameworks and server applications using pure-Swift code, without the need to also have systems programming skills and knowledge of multiple platforms.
2322
2423
[Erik Eckstein](https://github.com/eeckstein/) wrote a blog post on Swift.org titled [*Whole-Module Optimization in Swift 3*](https://swift.org/blog/whole-module-optimizations/). Not only does this article give an excellent overview of what whole-module optimization is and how it works, but it also provides a brief overview of how the Swift compiler works in this context.
2524

26-
There's an [UnsafeRawPointer Migration Guide](https://swift.org/migration-guide/se-0107-migrate.html) on Swift.org that guides you through migrating code that uses the `UnsafePointer` APIs from Swift 2 to Swift 3.
25+
There's a (new?) [UnsafeRawPointer Migration Guide](https://swift.org/migration-guide/se-0107-migrate.html) on Swift.org that guides you through migrating code that uses the `UnsafePointer` APIs from Swift 2 to Swift 3.
2726

2827
### Commits and pull requests
2928

3029
Doug Gregor [committed](https://github.com/apple/swift/commit/7519d83007443fd8092a20b700d5478a3cbeab5a) [a number](https://github.com/apple/swift/pull/5419) [of diffs](https://github.com/apple/swift/pull/5402) [to improve](https://github.com/apple/swift/pull/5421) the constraint solver by lazily creating constraints. This work prevents preallocating constraints that will be immediately simplified anyway &mdash; which should bring some decent performance improvements to the compiler.
3130

32-
In light of the rejection of [SE-0144](https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md), Robert Widmann submitted a [pull request](https://github.com/apple/swift/pull/5270) to disable the ability to use `$` as an identifier. It looks like Swift 3 point releases will continue to silently accept `$` as an identifier, but this will be an error in Swift 4.
31+
In light of the rejection of [SE-0144](https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md), Robert Widmann submitted a [pull request](https://github.com/apple/swift/pull/5270) to disable the ability to use `$` as an identifier. It looks like Swift 3.x releases will continue to silently accept `$` as an identifier, but this will be an error in Swift 4.
3332

3433
Erik Eckstein [fixed](https://github.com/apple/swift/pull/5400) a bug where a constructor call of an `open class` is devirtualized although the call should be done dynamically.
3534

@@ -49,21 +48,33 @@ Proposal [SE-0144](https://github.com/apple/swift-evolution/blob/master/proposal
4948
5049
### Mailing lists
5150

52-
There's a new mailing list, [swift-server-dev](https://lists.swift.org/mailman/listinfo/swift-server-dev), dedicated to the new Server APIs Project. If you have any interest in server-side Swift or want to get involved, sign up! Chris Bailey from IBM sent the [inaugural email](https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20161024/000000.html).
51+
There's a new mailing list! The [swift-server-dev](https://lists.swift.org/mailman/listinfo/swift-server-dev) list is a dedicated list for the new Server APIs Project. If you have any interest in server-side Swift or want to get involved, sign up! Chris Bailey from IBM sent the [inaugural email](https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20161024/000000.html).
5352

54-
> [...] Whilst there is already strong participation from some of the more well know web frameworks, including Kitura, Vapor, Perfect, and Zewo, participation and contribution is open to everyone - whether that's having a requirement or use case you'd like to share, bugs you want to report (once we have code!), code your willing to write, or just your thoughts on what's needed.
53+
> [...] Whilst there is already strong participation from some of the more well know web frameworks, including Kitura, Vapor, Perfect, and Zewo, participation and contribution is open to everyone &mdash; whether that's having a requirement or use case you'd like to share, bugs you want to report (once we have code!), code your willing to write, or just your thoughts on what's needed.
5554
5655
Ted Kremenek also [announced](https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000293.html) the Server APIs Project on swift-evolution-announce.
5756

5857
> [...] The idea behind the work group is to have a way for the Swift.org community to prototype and design a core set of APIs for empowering Swift development for server development. This work group complements the evolution process on swift-evolution, whereby the work group will incubate new APIs and libraries that eventually will be brought back for formal review/proposal on swift-evolution. The work group, however, provides a focused forum to develop and discuss these new APIs. [...]
5958
>
6059
> Thanks so much to Chris Bailey for driving much of the effort to organize the work group.
6160
61+
Erica Sadun [pitched an idea](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html) on reimagining `guard case` and `if case`. She proposed the following, simpler syntax using the pattern matching (`~=`) operator:
6262

63+
{% highlight swift %}
64+
// Current (confusing)
65+
if case range = myValue {
66+
// ...
67+
}
6368

64-
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html
69+
// Proposed (simpler)
70+
if range ~= myValue {
71+
// ...
72+
}
73+
{% endhighlight %}
6574

66-
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161017/028174.html
75+
Jacob Bandes-Storch [shared a draft proposal](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161017/028174.html) on *Refining Identifier and Operator Symbology* in collaboration with Erica Sadun, Xiaodi Wu, and Jonathan Shapiro. The goal is to clarify which characters are valid operators versus valid identifiers and adopt Unicode recommendations.
76+
77+
> This proposal seeks to refine and rationalize Swift's identifier and operator symbology.
6778
6879
### Finally
6980

0 commit comments

Comments
 (0)