Swift Weekly Brief
A community-driven weekly newsletter about Swift.org
2023-03-26T10:25:10-07:00
https://swiftweeklybrief.com/
Swift Weekly Brief
/img/logo.png
Issue #201
https://swiftweeklybrief.com/issue-201
2022-06-22T00:00:00-07:00
2022-06-22T00:00:00-07:00
Jeroen Leenarts
https://twitter.com/appforce1
https://github.com/appforce1.png?size=100
appforce1
<p>This is it. The final goodbye of Swift Weekly Brief.</p>
<p>We are now dormant for almost half a year and after a quick discussion Kristaps and I feel it is time to make good on our promise to delete the entire list’s data.</p>
<p>We loved having you as readers, but we love respecting your data even more.</p>
<p>We do want to suggest another list to look at:</p>
<ul>
<li>Recently Cihat has been killing it on his new list with a very similar purpose to ours. If you liked Swift Weekly Brief, you will love his newsletter. So <a href="https://twitter.com/Jeehut">sign up on his Twitter profile</a>, give him a follow too. If you are not into Twitter or would like to use a dedicated email address: <a href="https://se-monthly.flinedev.com/">This is the same newsletter but on Revue</a></li>
</ul>
<p>Thank you for you time and attention,
<a href="https://kristaps.me/">Kristaps</a> and <a href="https://appforce1.net">Jeroen</a></p>
Issue #200
https://swiftweeklybrief.com/issue-200
2021-12-16T00:00:00-08:00
2021-12-16T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<blockquote>
<p>In every end, there is also a beginning.</p>
</blockquote>
<p>This issue #200 is my last as the main contributor to this project. I want to thank <a href="https://twitter.com/jesse_squires">Jesse Squires</a>, who started this project, and <a href="https://twitter.com/BasThomas">Bas Broek</a>, who continued later on and trusted me to run it. I also want to thank all the contributors who have helped with writing, reviewing, or providing the content. It is indeed a community-run project. Thank you!</p>
<p>Now let’s get to the news.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://getstream.io/chat/sdk/ios/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_200" target="_blank">Build real-time chat messaging in less time with Stream</a></h4>
<p>Rapidly ship in-app messaging with Stream’s highly reliable chat infrastructure and feature-rich SDKs. Drive in-app conversion, engagement, and retention.</p>
<p><small><a href="https://getstream.io/chat/sdk/ios/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_200" target="_blank">getstream.io/chat/sdk/ios/</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.swiftbysundell.com/podcast/110/">episode 110</a> of the Swift by Sundell podcast, <a href="https://twitter.com/0xTim">Tim Condon</a>, joins <a href="https://twitter.com/johnsundell">John Sundell</a> to discuss how both client and server-side Swift developers could utilize the new built-in concurrency system, as well as how distributed actors and other upcoming language features might continue to make Swift even more capable on the server.</p>
<h3 id="news-and-community">News and community</h3>
<p>Six years ago, on the 3rd of December 2015, the Swift language was <a href="https://www.swift.org/blog/welcome/">open-sourced</a>.</p>
<p>Xcode 13.2 has been released. The release tumbled a bit, but has some notable <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift">Swift features</a>.</p>
<p><a href="https://developer.apple.com/news/?id=v868vy6e">Swift Playgrounds 4 is now available.</a> Swift Playgrounds is the best and easiest way to learn how to code. And with Swift Playgrounds 4, you have the tools to build iPhone and iPad apps right on iPad and submit them directly to App Store Connect.</p>
<p>Amazon Web Services <a href="https://twitter.com/awsdevelopers/status/1466476358389874704">announced</a> that <a href="https://t.co/0x27sFTE3p">AWS SDK for the Swift programming language</a> is now available in developer preview.</p>
<p><a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> posted <a href="https://www.youtube.com/watch?v=Ii1mDtDr3xo">a video</a> about Swift’s standard library.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/Azoy">Alejandro Alonso</a> merged <a href="https://github.com/apple/swift/pull/40340">a pull request</a> that drops ICU.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md">SE-0331</a> <em>Remove Sendable conformance from unsafe pointer types</em> was <a href="https://forums.swift.org/t/accepted-se-0331-remove-sendable-conformance-from-unsafe-pointer-types/53979">accepted</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0332-swiftpm-command-plugins.md">SE-0332</a> <em>Package Manager Command Plugins</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0332-package-manager-command-plugins/54074">accepted with modifications</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0335-existential-any.md">SE-0335</a>: <em>Introduce existential <code class="language-plaintext highlighter-rouge">any</code></em> is <a href="https://forums.swift.org/t/se-0335-introduce-existential-any/53934">under review</a>.</p>
<blockquote>
<p>Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of <strong>active harm</strong> by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental <a href="https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials">limitation of value-level abstraction</a>. This proposal makes the impact of existential types explicit in the language by annotating such types with <code class="language-plaintext highlighter-rouge">any</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0336-distributed-actor-isolation.md">SE-0336</a>: <em>Distributed actor isolation</em> is <a href="https://forums.swift.org/t/se-0336-distributed-actor-isolation/53939">under review</a>.</p>
<blockquote>
<p>With the recent introduction of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">actors</a> to the language, Swift gained powerful and foundational building blocks for expressing <em>thread-safe</em> concurrent programs. This proposal is the first in a series of proposals aiming to extend Swift’s actor runtime with the concept of <em>distributed actors</em>, allowing developers leverage the actor model not only in local, but also distributed settings.</p>
<p>With distributed actors, we acknowledge that the world we live in is increasingly built around distributed systems, and that we should provide developers with better tools to work within those environments. We aim to simplify and push the state-of-the-art for distributed systems programming in Swift as we did with concurrent programming with local actors and Swift’s structured concurrency approach embedded in the language.</p>
<p>This proposal focuses on the extended actor isolation and type-checking aspects of distributed actors.</p>
</blockquote>
<p><a href="https://github.com/swift-server/sswg/blob/main/proposals/0018-mqtt-nio.md">SSWG-0018</a>: <em>MQTTNIO Proposal</em> is <a href="https://forums.swift.org/t/sswg-0018-mqttnio-proposal/54004">under review</a>.</p>
<blockquote>
<p>There are a number of Swift MQTT libraries out there but many are not built on top of SwiftNIO. And many only support one version of the protocol or don’t provide WebSocket or TLS connections. MQTTNIO provides all of these. The library has also recently gained new Swift concurrency APIs.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md">SE-0327</a>: <em>On Actors and Initialization</em> is <a href="https://forums.swift.org/t/se-0327-second-review-on-actors-and-initialization/54093">under a second review</a>.</p>
<blockquote>
<p>This proposal has undergone a number of revisions in response to feedback from the <a href="https://forums.swift.org/t/se-0327-on-actors-and-initialization/53053">first review 1</a>, which the author has summarized as:</p>
<ol>
<li>Actor initializers that are not isolated to the actor will now allow you to do anything you normally can from a <code class="language-plaintext highlighter-rouge">nonisolated</code> method. In exchange, Swift will automatically reject accesses to stored properties that might be unsafe. Here is the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#overly-restrictive-non-async-initializers">problem description</a> and <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#initializers-with-nonisolated-self">proposed solution 3</a>.</li>
<li>Deinitializers of an actor can no longer access non-sendable stored properties of the instance. Here is the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#data-races-in-deinitializers">problem description</a> and <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#deinitializers">proposed solution 1</a></li>
<li>The default value of a type’s stored property is evaluated in a non-isolated context. Here is the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#stored-property-isolation">problem description</a> and <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#global-actor-isolation-and-instance-members">proposed solution</a></li>
<li>The <code class="language-plaintext highlighter-rouge">convenience</code> keyword is no longer required to define a delegating initializer of an actor. Here is the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#initializer-delegation">problem description </a> and <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md#delegating-initializers">proposed rules</a> for their delegating initializers, which is continued in the Sendability section.</li>
</ol>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/etcwilde">Evan Wilde</a> pitched <a href="https://forums.swift.org/t/pitch-unavailability-from-asynchronous-contexts/53877">a proposal</a> the <code class="language-plaintext highlighter-rouge">@unavailableFromAsync</code> attribute.</p>
<blockquote>
<p>The Swift concurrency model allows tasks to suspend and resume on different threads. While this behaviour allows higher utility of computational resources, there are some nasty pitfalls that can spring on an unsuspecting programmer. One such pitfall is the undefined behaviour from unlocking a <code class="language-plaintext highlighter-rouge">pthread_mutex_t</code> from a different thread than the thread that holds the lock. Reading from and writing to thread-local storage across suspension points can also result in unintended behavior, since the operation may be resuming on a different thread.</p>
</blockquote>
<p><a href="https://twitter.com/tomerdoron">Tom Doron</a> pitched <a href="https://forums.swift.org/t/pitch-package-manager-statically-link-swift-runtime-libraries-by-default-on-supported-platforms/53900">an idea</a> to statically link Swift runtime libraries by default on supported platforms.</p>
<blockquote>
<p>Swift 5.3.1 introduced <a href="https://forums.swift.org/t/static-linking-on-linux-in-swift-5-3-1/">statically linking the Swift runtime libraries on Linux</a>. With this feature, users can set the <code class="language-plaintext highlighter-rouge">--static-swift-stdlib</code> flag when invoking SwiftPM commands (or the long form <code class="language-plaintext highlighter-rouge">-Xswiftc -static-stdlib</code>) in order to statically link the Swift runtime libraries into the program.</p>
<p>On some platforms, such as Linux, this is often the preferred way to link programs, since the program is easier to deploy to the target server or otherwise share.</p>
<p>This proposal explores making it SwiftPM’s default behavior when building executable programs on such platforms.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/jumhyn">Frederick Kellison-Linn</a> pitched <a href="https://forums.swift.org/t/swift-6-reconsider-escaping-for-optional-function-type-parameters/53932">a proposal</a> to reconsider <code class="language-plaintext highlighter-rouge">@escaping</code> for optional function-type parameters.</p>
<p><a href="">Kavon Farvardin</a> updated <a href="https://forums.swift.org/t/pitch-2-on-actors-and-initialization/53972">the proposal</a> on Actors and Initialization.</p>
<blockquote>
<p>Since the proposal differs significantly from the first review, this is a pitch. Here’s a very informal and incomplete summary of the major functionality proposed, along with some links into the document itself for more details:</p>
</blockquote>
<blockquote>
<ol>
<li>Actor initializers that are not isolated to the actor will now allow you to do anything you normally can from a <code class="language-plaintext highlighter-rouge">nonisolated</code> method. In exchange, Swift will automatically reject accesses to stored properties that might be unsafe. Here is the <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#overly-restrictive-non-async-initializers">problem description 2</a> and <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#initializers-with-nonisolated-self">proposed solution 1</a>.</li>
<li>Deinitializers of an actor can no longer access non-sendable stored properties of the instance. Here is the <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#data-races-in-deinitializers">problem description 1</a> and <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#deinitializers">proposed solution</a></li>
<li>A type’s stored property cannot have a default value if its isolation is not compatible with its initializers. Here is the <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#stored-property-isolation">problem description</a> and <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#global-actor-isolation-and-instance-members">proposed solution</a></li>
<li>The <code class="language-plaintext highlighter-rouge">convenience</code> keyword is no longer required to define a delegating initializer of an actor. Here is the <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#initializer-delegation">problem description 3</a> and <a href="https://github.com/kavon/swift-evolution/blob/actor-initializers-review2/proposals/0327-actor-initializers.md#delegating-initializers">proposed rules 2</a> for their delegating initializers, which is continued in the Sendability section.</li>
</ol>
</blockquote>
<p>Updates from Swift on the Server Workgroup:</p>
<ul>
<li><a href="https://forums.swift.org/t/1st-sep-2021/53982">1st Sep 2021</a></li>
<li><a href="https://forums.swift.org/t/15th-september-2021/54002">15th September 2021</a></li>
<li><a href="https://forums.swift.org/t/september-29-2021/53926">September 29, 2021</a></li>
<li><a href="https://forums.swift.org/t/october-13th-2021/53990">October 13th, 2021</a></li>
<li><a href="https://forums.swift.org/t/october-27th-2021/53984">October 27th, 2021</a></li>
<li><a href="https://forums.swift.org/t/november-10-2021/54031">November 10, 2021</a></li>
</ul>
<h3 id="finally">Finally</h3>
<p>This time I will leave <a href="https://kristaps.me/">my website</a> in the final section.</p>
Issue #199
https://swiftweeklybrief.com/issue-199
2021-12-02T00:00:00-08:00
2021-12-02T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Hello all! I truly hope you enjoyed Thanksgiving and were able to spend the holiday with your loved ones. Maybe some of you even played Chandler’s invented game of naming all <a href="https://www.youtube.com/watch?v=0YKyFV3551w">50 states in 6 minutes</a>.</p>
<p>The period after Thanksgiving was very productive for the Swift team, and there’s a lot of activity to discuss today. But before we jump into it, I’d like to use this opportunity to say that the next issue will be the last issue for me and maybe for this project. Please let me know if anyone is interested in taking over my duties. I would love to see this project stay alive and thrive after I leave.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://iosacademy.essentialdeveloper.com/p/ios-testing-crash-course-swba028/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_199" target="_blank">The Senior iOS Developer Testing Crash Course</a></h4>
<p>Learn the most up-to-date techniques and strategies for testing new and legacy Swift code in this free practical course for iOS devs who want to become complete Senior iOS Developers.</p>
<p><small><a href="https://iosacademy.essentialdeveloper.com/p/ios-testing-crash-course-swba028/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_199" target="_blank">iosacademy.essentialdeveloper.com</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/SmileyKeith">Keith Smiley</a> <a href="https://forums.swift.org/t/5-5-cherry-pick-triage-process/53574">shared</a> updates about Swift 5.5 and it’s cherry-picking triage process.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> wrote <a href="https://www.swiftbysundell.com/articles/count-vs-isEmpty/">an article</a> exploring how to use <code class="language-plaintext highlighter-rouge">count</code> vs. <code class="language-plaintext highlighter-rouge">isEmpty</code> to check whether a collection contains any elements.</p>
<p><a href="https://twitter.com/wlisac">Will Lisac</a> <a href="https://twitter.com/wlisac/status/1460499369052884992">tweeted</a> that <a href="https://github.com/wlisac/swift-on-balena">Swift 5.5 Docker images</a> for Raspberry Pi are now available.</p>
<p>A great <a href="https://fbernutz.github.io/images/summaries-ios-interview-topics/swift-evolution.jpg">illustration</a> by <a href="https://twitter.com/felibe444">Feli</a>. Worth to check out her <a href="https://fbernutz.github.io/sketchnotes/">sketches</a> from various conferences.</p>
<p><a href="https://twitter.com/MaxDesiatov">Max Desiatov</a> <a href="https://forums.swift.org/t/swiftwasm-5-5-0-is-now-available/53760">announced</a> that the <a href="https://blog.swiftwasm.org/posts/5-5-released/">SwiftWasm 5.5.0</a> is now available.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0328-structural-opaque-result-types.md">SE-0328</a> <em>Structural opaque result type</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0328-structural-opaque-result-type/53789">accepted with modifications</a>.</p>
<blockquote>
<p>During the review, there were two main areas of discussion:</p>
<ul>
<li>The spelling of optional types. The proposal leaves this as <code class="language-plaintext highlighter-rouge">(some P)?</code> even though <code class="language-plaintext highlighter-rouge">some P?</code> is more succinct and could potentially be allowed as sugar. The core team agrees with this more conservative approach, which could be revisited later after more experience with the feature.</li>
<li>The use of <code class="language-plaintext highlighter-rouge">some</code> in “consuming” rather than “producing” position when returning function types i.e. <code class="language-plaintext highlighter-rouge">f() -> (some P) -> Void</code>. Discussion of other uses of the <code class="language-plaintext highlighter-rouge">some</code> keyword is ongoing, and there was concern about potential conflict with those future uses. Since the use of opaque result types in consuming position is not especially useful (such functions are uncallable in all but a few circumstances) the core team has decided to subset out this use, requiring opaque result types only in the return value of returned function types for now.</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0332-swiftpm-command-plugins.md">SE-0332</a>: <em>Package Manager Command Plugins</em> is <a href="https://forums.swift.org/t/se-0332-package-manager-command-plugins/53769">under review</a>.</p>
<blockquote>
<p>SE-0303 introduced the ability to define <em>build tool plugins</em> in SwiftPM, allowing custom tools to be automatically invoked during a build. This proposal extends that plugin support to allow the definition of custom <em>command plugins</em> — plugins that users can invoke directly from the SwiftPM CLI, or from an IDE that supports Swift Packages, in order to perform custom actions on their packages.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0331-remove-sendable-from-unsafepointer.md">SE-0331</a>: <em>Remove Sendable conformance from unsafe pointer types</em> is <a href="https://forums.swift.org/t/se-0331-remove-sendable-conformance-from-unsafe-pointer-types/53768">under review</a>.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a> introduced the <code class="language-plaintext highlighter-rouge">Sendable</code> protocol, including <code class="language-plaintext highlighter-rouge">Sendable</code> requirements for various language constructs, conformances of various standard library types to <code class="language-plaintext highlighter-rouge">Sendable</code>, and inference rules for non-public types to implicitly conform to <code class="language-plaintext highlighter-rouge">Sendable</code>.</p>
<p>Experience with <code class="language-plaintext highlighter-rouge">Sendable</code> shows that this formulation is unnecessarily dangerous and has unexpected negative consequences for implicit conformance.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0333-with-memory-rebound.md">SE-0333</a>: <em>Expand usability of withMemoryRebound</em> is <a href="https://forums.swift.org/t/se-0333-expand-usability-of-withmemoryrebound/53799">under review</a>.</p>
<blockquote>
<p>The function <code class="language-plaintext highlighter-rouge">withMemoryRebound(to:capacity:_ body:)</code>
executes a closure while temporarily binding a range of memory to a different type than the callee is bound to.
We propose to lift some notable limitations of <code class="language-plaintext highlighter-rouge">withMemoryRebound</code> and enable rebinding to a larger set of types,
as well as rebinding from raw memory pointers and buffers.</p>
<p>Note this proposal is running concurrently with <a href="https://forums.swift.org/t/se-0334-pointer-usability-improvements/">SE-0334</a> which also relates to unsafe pointer usability.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0334-pointer-usability-improvements.md">SE-0334</a>: <em>Pointer Usability Improvements</em> is <a href="https://forums.swift.org/t/se-0334-pointer-usability-improvements/53800">under review</a>.</p>
<blockquote>
<p>This proposal introduces some quality-of-life improvements for <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and its <code class="language-plaintext highlighter-rouge">Mutable</code> and <code class="language-plaintext highlighter-rouge">Raw</code> variants.</p>
<ol>
<li>Add an API to obtain an <code class="language-plaintext highlighter-rouge">UnsafeRawPointer</code> instance that is advanced to a given alignment from its starting point.</li>
<li>Add an API to obtain a pointer to a stored property of an aggregate <code class="language-plaintext highlighter-rouge">T</code>, given an <code class="language-plaintext highlighter-rouge">UnsafePointer<T></code>.</li>
<li>Add the ability to compare pointers of any two types.</li>
</ol>
<p>Note this proposal is running concurrently with <a href="https://forums.swift.org/t/se-0333-expand-usability-of-withmemoryrebound/">SE-0333</a> which also relates to unsafe pointer usability.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/ethankusters">Ethan Kusters</a> started <a href="https://forums.swift.org/t/support-hosting-docc-archives-in-static-hosting-environments/53572">a discussion</a> about support hosting DocC archives in static hosting environments.</p>
<blockquote>
<p>This post discusses an enhancement to Swift-DocC and Swift-DocC-Render that will allow developers to build DocC archives that can be hosted without custom routing. This is specifically designed to enable DocC to be used in additional static hosting environments, most notably GitHub Pages.</p>
<p>This change is meant as a quick solution to address a pressing need, and provides general goodness. But please know that we’ve heard the community’s feedback that they would love for Swift-DocC to directly emit static HTML, and this feature is high on the priority list.</p>
</blockquote>
<p><a href="https://twitter.com/samdeane">Sam Deane</a> pitched <a href="https://forums.swift.org/t/default-initable-protocol/53723">an idea</a> to implement a default initable protocol.</p>
<blockquote>
<p>I’ve come across factory-type situations where I’ve ended up making a protocol to represent that “this type can be constructed with a default init that takes no arguments”.</p>
<p>I’ve found myself wondering (a) whether this protocol already exists somewhere in the standard library, and (b) whether Swift could auto-conform any type to it if an init() exists for it.</p>
</blockquote>
<p><a href="https://forums.swift.org/t/a-built-in-angle-type/53726">A good reminder</a> that a library <a href="https://github.com/apple/swift-numerics">Swift Numerics</a> does exist.</p>
<p>Guillaume Lessard pitched <a href="https://forums.swift.org/t/pitch-buffer-partial-initialization-better-buffer-slices/53795">a proposal</a> to make slices of buffers more useful, especially with respect to partial initialization of buffers.</p>
<blockquote>
<p>Sub-sequences of the <code class="language-plaintext highlighter-rouge">UnsafeBufferPointer</code> family have all the <code class="language-plaintext highlighter-rouge">[Mutable]Collection</code> API of <code class="language-plaintext highlighter-rouge">UnsafeBufferPointer</code>, but have none of their buffer-specific API. This makes partial initialization of a buffer difficult, among other tasks.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://www.youtube.com/watch?v=abcMmyhKCno">iPhone Development Tutorial - 1 - Installing Xcode and the iPhone SDK.</a>.</p>
<p><a href="https://thehistoryoftheweb.com/timeline/">The History of the Web</a>.</p>
Issue #198
https://swiftweeklybrief.com/issue-198
2021-11-18T00:00:00-08:00
2021-11-18T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The holiday season is just around the corner. Most of us enjoy Thanksgiving right before Christmas. For others, the festivities start after Christmas and continue even after New Year’s Eve. Despite the differences, we should all enjoy some time off with our families and friends and for this period, merge access will be locked down in Swift. Check out the <a href="https://forums.swift.org/t/holiday-schedule/53507">holiday schedule</a> and plan your work accordingly.</p>
<p>There is a new feature in <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Build-System">Xcode 13.2 beta</a> which makes build times much faster by using more CPU cores. This new build system is opt-in, so you’ll have to enable it.</p>
<p>Before we jump into other detailed news, I would like to express my gratitude to our sponsors who have helped us to run this project for the rest of the year. We would not be here without your support.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://getstream.io/chat/sdk/ios/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_198" target="_blank">Build real-time chat messaging in less time with Stream</a></h4>
<p>Rapidly ship in-app messaging with Stream’s highly reliable chat infrastructure and feature-rich SDKs. Drive in-app conversion, engagement, and retention.</p>
<p><small><a href="https://getstream.io/chat/sdk/ios/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_198" target="_blank">getstream.io/chat/sdk/ios/</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://swiftbysundell.com/podcast/108/">episode 108</a> of the Swift by Sundell podcast, <a href="https://twitter.com/icanzilb">Marin Todorov</a>, joins <a href="https://twitter.com/johnsundell">John Sundell</a>. They discuss Swift’s new concurrency system and its newly announced backward compatibility, his new book about that topic, and his work on Apple’s open source documentation tool, <a href="https://github.com/apple/swift-docc">Swift-DocC</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/racer_girl27">Nicole Jacque</a> updated us about the <a href="https://forums.swift.org/t/swift-5-6-release-process/53412">Swift 5.6 release process</a>.</p>
<p><a href="https://twitter.com/mishaldshah">Mishal Shah</a> <a href="https://forums.swift.org/t/updating-llvm-project-branch-for-swift-main/53438">informed</a> us about updating llvm-project branch for <code class="language-plaintext highlighter-rouge">swift:main</code>.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> announced <a href="https://github.com/JohnSundell/CollectionConcurrencyKit">CollectionConcurrencyKit</a> - a lightweight Swift package that adds asynchronous and concurrent versions of the standard <code class="language-plaintext highlighter-rouge">map</code>, <code class="language-plaintext highlighter-rouge">flatMap</code>, <code class="language-plaintext highlighter-rouge">compactMap</code>, and <code class="language-plaintext highlighter-rouge">forEach</code> APIs to all Swift collections that conform to the <code class="language-plaintext highlighter-rouge">Sequence</code> protocol.
He wrote <a href="https://www.swiftbysundell.com/articles/async-and-concurrent-forEach-and-map/">an article</a> explaining how to build async and concurrent versions of <code class="language-plaintext highlighter-rouge">forEach</code> and <code class="language-plaintext highlighter-rouge">map</code>.</p>
<p><a href="https://twitter.com/pwsacademy">Steven Van Impe</a> <a href="https://forums.swift.org/t/introducing-swift-in-higher-education/53445">introduced</a> <a href="https://www.pwsacademy.org/">Swift in higher education</a>.</p>
<p><a href="https://twitter.com/mishaldshah/">Mishal Shah</a> informed us about <a href="https://forums.swift.org/t/holiday-schedule/53507">the Holiday Schedule</a> for Swift projects.</p>
<p><a href="https://twitter.com/Leo_Pugliese">Leonardo Maia Pugliese</a> wrote <a href="https://holyswift.app/reverse-reverse-linked-list-linked-list-using-recursion">an article</a> explaining linked lists using recursion.</p>
<p><a href="https://twitter.com/twannl">Antoine van der Lee</a> explained property wrappers in Swift in a <a href="https://www.avanderlee.com/swift/property-wrappers/">blog post</a>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0326-extending-multi-statement-closure-inference.md">SE-0326</a> <em>Multi-statement closure parameter/result type inference</em> was <a href="https://forums.swift.org/t/accepted-se-0326-multi-statement-closure-parameter-result-type-inference/53502">accepted</a>.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md">SE-0327</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0327-on-actors-and-initialization/53447">returned for revision</a>.</p>
<blockquote>
<p>The review discussion centered on the complexity of the initialization model, and has uncovered a simpler model that should be easier to reason about. The Core Team has returned this proposal for revision to investigate this new model. Thank you to everyone who participated!</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0329-clock-instant-date-duration.md">SE-0329</a>: <em>Clock, Instant, Date, and Duration</em> is <a href="https://forums.swift.org/t/se-0329-clock-instant-date-and-duration/53309">under review</a>.</p>
<blockquote>
<p>The concepts of time can be broken down into three distinct parts:</p>
<ol>
<li>An item to provide a concept of now plus a way to wake up after a given point in time</li>
<li>A concept of a point in time</li>
<li>A concept of a measurement in time</li>
</ol>
<p>These three items are respectively a <strong>clock</strong>, an <strong>instant</strong> and a <strong>duration</strong>. The measurement of time can be used for many types of APIs, all the way from the high levels of a concept of a timeout on a network connection, to the amount of time to sleep a task. Currently, the APIs that take measurement of time types take <code class="language-plaintext highlighter-rouge">NSTimeInterval</code> (aka <code class="language-plaintext highlighter-rouge">TimeInterval</code>), <code class="language-plaintext highlighter-rouge">DispatchTimeInterval</code>, and even types like <code class="language-plaintext highlighter-rouge">timespec</code>.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/ilias_karim">Ilias Karim</a> started <a href="https://forums.swift.org/t/pitch-not-contains/53305">a discussion</a> about adding <code class="language-plaintext highlighter-rouge">notContains</code> to the standard library.</p>
<blockquote>
<p>Filter using keypath notation makes functional programming much more succinct and readable in Swift.</p>
<p>However, there is not an intuitive standard library way to filter by the opposite of the boolean. I previously proposed <a href="https://forums.swift.org/t/toggled-or-isfalse-property-method-on-bool-for-use-with-keypath-apis/51464"><code class="language-plaintext highlighter-rouge">.toggled</code> or <code class="language-plaintext highlighter-rouge">.isFalse</code></a> and was met with reasonable push back.</p>
</blockquote>
<p>Karl <a href="https://forums.swift.org/t/filling-buffers-using-randomnumbergenerator/53324">proposed</a> two minor additions to <code class="language-plaintext highlighter-rouge">RandomNumberGenerator</code>.</p>
<blockquote>
<ol>
<li>Filling buffers</li>
<li>Static member syntax</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/rxwei">Richard Wei</a> pitched <a href="https://forums.swift.org/t/pitch-strongly-typed-regex-captures/53391">an idea</a> about strongly typed regex captures.</p>
<blockquote>
<p>Capturing groups are a commonly used component of regular expressions as they allow the programmer to extract information from matched input. A capturing group collects multiple characters together as a single unit that can be <a href="https://www.regular-expressions.info/backref.html">backreferenced</a> within the regular expression and accessed in the result of a successful match.</p>
</blockquote>
<p><a href="http://twitter.com/heckj/">Joseph Heck</a> started a discussion about the terminology questions - behaviors, shells, and possible reductions.</p>
<blockquote>
<p>I’ll caveat this with “Yep, these could be all implementation details”. In starting to dig through the source for swift-distributed-actors, there are some things I knew the concepts for (basic actor concept, mailboxes, and messages). The distributed actors code steps it up a bit, and uses some terms and phrasing that I wasn’t very familiar with. I could guess and infer quite a bit, but I thought it might be best to ask about the specific terms and how they’re inter-related.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/ethankusters">Ethan Kusters</a> addressed improvements for the presentation of non-framework documentation.</p>
<blockquote>
<p>Not all documentation built by Swift-DocC is for frameworks. Today, Swift-DocC will build documentation for any symbol graph input it is provided, which is what allows for custom workflows like <a href="https://github.com/apple/swift-docc/blob/main/Sources/DocCDocumentation/DocCDocumentation.docc/DocC.symbols.json">Swift-DocC’s user documentation</a> on <a href="https://swift.org/documentation/docc">Swift.org</a>. However, Swift-DocC always describes this documentation as a “Framework” on the top-level page, regardless of the contents of that symbol graph.</p>
<p>For example, Swift-DocC’s user documentation on <a href="http://swift.org/">Swift.org</a> is currently described as a “Framework” on the top-level page when the documentation on that page is about using DocC as a “Tool”, not as a “Framework”.</p>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> <a href="https://forums.swift.org/t/pre-pitch-swiftpm-manifest-based-on-result-builders/53457">pitched a</a> SwiftPM manifest based on result builders.</p>
<blockquote>
<p>Swift Package Manager (here after SwiftPM) was released when Swift was made open source in 2016. SwiftPM uses a file named <code class="language-plaintext highlighter-rouge">Package.swift</code> with which users describe the package’s source structure, the build artifacts such as any executables or libraries the build produces, and any dependencies on other packages.</p>
<p>SwiftPM’s manifest is a Swift program (a script of sorts) which SwiftPM builds and executes as a separate process in a security sandbox to generate a static data model representing the desired package configuration. Currently, the static representation is based on JSON and the exact format of that JSON is an internal implementation detail. The JSON model is later deserialized and loaded into the parent process memory space, driving SwiftPM’s workflows such as the dependency resolution, build, test , etc.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/ktoso">Konrad <code class="language-plaintext highlighter-rouge">ktoso</code> Malawski</a> shared <a href="https://forums.swift.org/t/proposal-distributed-actor-isolation/53460">a proposal</a> to implement distributed actor isolation.</p>
<blockquote>
<p>This proposal is focusing only on the isolation rules necessary to support distributed actors, and is split out from the large overall Distributed Actors <a href="https://forums.swift.org/t/pitch-distributed-actors/51669/133">pitch 8</a>. Our intent is to propose the various pieces of that very large pitch, as individual yet interconnected proposals, similar to how Swift Concurrency was introduced last year. This way we hope to keep the amount of content reviewable, and also discussions focused on the specific topics at hand.</p>
</blockquote>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> pitched <a href="https://forums.swift.org/t/pitch-introduce-existential-any/53520">a proposal</a> introducing existential <code class="language-plaintext highlighter-rouge">any</code>.</p>
<blockquote>
<p>Existential types in Swift have an extremely lightweight spelling: a plain protocol name in type context means an existential type. Over the years, this has risen to the level of <strong>active harm</strong> by causing confusion, leading programmers down the wrong path that often requires them to re-write code once they hit a fundamental <a href="https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--limits-of-existentials">limitation of value-level abstraction</a>. This proposal makes the impact of existential types explicit in the language by annotating such types with <code class="language-plaintext highlighter-rouge">any</code>.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jesse_squires/status/1457792858715418629">What’s a good way to model a numeric value that <em>must</em> be within a certain range?</a>.</p>
<p><a href="https://www.youtube.com/watch?app=desktop&v=zQDqYKG4dME">Sprite Commercial in the Style of a 1993 MacIntosh computer</a>.</p>
Issue #197
https://swiftweeklybrief.com/issue-197
2021-11-04T00:00:00-07:00
2021-11-04T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>How have the last two weeks been for all of you? Personally, I’ve felt a slight decrease in my working capacity due to lack of daylight and the falling temperatures. By the way, does your country use daylight savings time?</p>
<p>The <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes#Swift">Xcode 13.2 Beta</a> has concurrency support, which should help to resolve a certain kind of pain-point for many Swift developers. Perhaps the most important benefit of Swift’s built-in concurrency system is that it allows performing multiple asynchronous tasks in parallel in a much easier way. I can only imagine how much time we’ll save by speeding up performing tasks.</p>
<p>It is with great pleasure that I write how terrific the last three years of running this newsletter have been. I’ve met so many incredible people, and thanks to all of you, I have learned so much! This is the reason why typing the following sentence fills me with emotion. Issue 200 will be the last newsletter I run. I have decided to step away from leading this project, and with joyful excitement, I am looking for someone who would like to continue running things.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://2021.nsspain.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_197" target="_blank">NSSpain 2021</a></h4>
<p>NSSpain 2021 Remote Edition is an online, continuous 36 hours conference, carefully crafted by the community for the community.</p>
<p><small><a href="https://2021.nsspain.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_197" target="_blank">2021.nsspain.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<p><a href="https://bugs.swift.org/browse/SR-15408">SR-15408</a> [Swift-DocC
] Building documentation with a fallback display name that includes a space produces a broken-looking article</p>
<h3 id="news-and-community">News and community</h3>
<p>New <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-13_2-release-notes">Xcode 13.2 Beta</a> adds Swift Concurrency support for macOS 10.15, iOS 13, tvOS 13, and watchOS 6 or newer. This support includes <code class="language-plaintext highlighter-rouge">async/await</code>, actors, global actors, structured concurrency, and the task APIs.</p>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> <a href="https://forums.swift.org/t/async-await-has-arrived-in-vapor/53077">posted</a> that Vapor now has now <code class="language-plaintext highlighter-rouge">async/await</code> support.</p>
<p><a href="https://forums.swift.org/u/ktoso">Konrad <code class="language-plaintext highlighter-rouge">ktoso</code> Malawski</a> wrote <a href="https://swift.org/blog/distributed-actors/">a post</a> introducing Swift Distributed Actors.</p>
<p><a href="https://twitter.com/digimarktech">Marc Aupont</a> is <a href="https://forums.swift.org/t/diversity-in-swift-work-group-update/53133">joining</a> the Diversity in Swift work group.</p>
<p>Swift download links have moved to a new location to provide faster download speeds! The toolchains will be hosted at <a href="http://download.swift.org/">download.swift.org</a>, and it will use a similar pattern as the current URL. To use the new URL, replace <code class="language-plaintext highlighter-rouge">swift.org/builds/</code> with <code class="language-plaintext highlighter-rouge">download.swift.org/</code>. Starting Oct 26th 2021, the <code class="language-plaintext highlighter-rouge">swift.org/builds</code> URLs have been redirected to the new sub domain.</p>
<p><a href="https://twitter.com/sarunw">Sarun Wongpatcharapakorn</a> wrote a blog post explaining <a href="https://sarunw.com/posts/what-is-keypath-in-swift/">KeyPath in Swift</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/eeckstein/">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/39902">a pull request</a> that implements a prototype for performance annotations like <code class="language-plaintext highlighter-rouge">@_noLocks</code> and <code class="language-plaintext highlighter-rouge">@_noAllocation</code> in Swift.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/39918">a pull request</a> that improves handling of identity conformances <code class="language-plaintext highlighter-rouge">[P].[P] => [P]</code>.</p>
<p><a href="https://github.com/rjmccall">John McCall</a> merged <a href="https://github.com/apple/swift/pull/39829">a pull request</a> that fixes the alignment of future fragments for highly-aligned result types.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0325-swiftpm-additional-plugin-apis.md">SE-0325</a> <em>Additional Package Plugin APIs</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0325-additional-package-plugin-apis/53086">accepted with modifications</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0326-extending-multi-statement-closure-inference.md">SE-0326</a>: <em>Multi-statement closure parameter/result type inference</em> is <a href="https://forums.swift.org/t/se-0326-multi-statement-closure-parameter-result-type-inference/52964">under review</a>.</p>
<blockquote>
<p>I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0327-actor-initializers.md">SE-SE-0327</a>: <em>On Actors and Initialization</em> is <a href="https://forums.swift.org/t/se-0327-on-actors-and-initialization/53053">under review</a>.</p>
<blockquote>
<p>Actors are a relatively new nominal type in Swift that provides data-race safety for its mutable state.
The protection is achieved by <em>isolating</em> the mutable state of each actor instance to at most one task at a time.
The proposal that introduced actors (<a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">SE-0306</a>) is quite large and detailed, but misses some of the subtle aspects of creating and destroying an actor’s isolated state.
This proposal aims to shore up the definition of an actor, to clarify <em>when</em> the isolation of the data begins and ends for an actor instance, along with <em>what</em> can be done inside the body of an actor’s <code class="language-plaintext highlighter-rouge">init</code> and <code class="language-plaintext highlighter-rouge">deinit</code> declarations.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0328-structural-opaque-result-types.md">SE-0328</a>: <em>Structural opaque result types</em> is <a href="hhttps://forums.swift.org/t/se-0328-structural-opaque-result-types/53248">under review</a>.</p>
<blockquote>
<p>An <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0244-opaque-result-types.md">opaque result type</a> may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in “structural” positions.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>A little history <a href="https://forums.swift.org/t/get-folders-number-of-elements/30674/12">lesson</a> from <a href="https://twitter.com/justkwin">@justkwin</a> about how Foundation ended up using URLs to represent file.paths.</p>
<p><a href="https://forums.swift.org/u/abertelrud">Anders Bertelrud</a> pitched <a href="https://forums.swift.org/t/pitch-package-manager-command-plugins/53172">a proposal</a> to add package manager command plugins.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> introduced the first kind of SwiftPM plugins, focusing on the ability to extend the build system with custom build tool invocations (in particular for the purpose of generating source code). Those plugins were always intended to be just the first kind of plugin supported by SwiftPM.</p>
<p>I’d like to pitch a draft proposal for adding another kind of more general-purpose “command plugin” to SwiftPM. These kinds of plugins would be directly invocable by users and would be intended for such things as source code formatting, documentation generation, test report generation, etc. A command plugin would not necessarily have anything to do with the build system.</p>
<p>One important aspect of these custom command plugins is that they can ask the plugin host (either SwiftPM or an IDE that supports packages) to generate specialized information on-demand or to initiate builds or test runs. This is the part of the draft proposal that could use the most scrutiny. There is an element of tension here between making the API rich enough to be as useful as possible, while also making it generic enough to be implementable not only in SwiftPM but also in IDEs that support Swift Packages.</p>
</blockquote>
<p>Guillaume Lessard pitched <a href="https://forums.swift.org/t/pitch-pointer-family-initialization-improvements/53168">a proposal</a> that would implement pointer family initialization improvements.</p>
<blockquote>
<p>The types in the <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> family typically require manual management of memory allocations, including the management of their initialization state. The states involved are, after allocation:</p>
<ol>
<li>Unbound and uninitialized (as returned from <code class="language-plaintext highlighter-rouge">UnsafeMutableRawPointer.allocate()</code>)</li>
<li>Bound to a type, and uninitialized (as returned from <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer<T>.allocate()</code>)</li>
<li>Bound to a type, and initialized</li>
</ol>
<p>Memory can be safely deallocated whenever it is uninitialized.</p>
<p>Unfortunately, not every relevant type in the family has the necessary functionality to fully manage the initialization state of its memory. We intend to address this issue in this proposal, and provide functionality to manage initialization state in a much expanded variety of situations.</p>
</blockquote>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> started <a href="https://forums.swift.org/t/asyncstream-constructor-which-also-returns-its-continuation/53251">a discussion</a> about <code class="language-plaintext highlighter-rouge">AsyncStream</code> constructor which also returns its Continuation.</p>
<blockquote>
<p>is there any way we can add an API to <code class="language-plaintext highlighter-rouge">AsyncStream</code> which returns the continuation directly, so we do not have to “juggle” it out of the closure?</p>
<p>in general, i also feel like <code class="language-plaintext highlighter-rouge">AsyncStream</code> is really difficult to work with due to the requirement that iteration happen in the same Task that the <code class="language-plaintext highlighter-rouge">AsyncStream</code> was created in, even when no concurrent iteration ever takes place. this makes it hard to “subscribe” to events generated from <code class="language-plaintext highlighter-rouge">actor</code> objects, even when the subscription method is marked <code class="language-plaintext highlighter-rouge">nonisolated</code>.</p>
</blockquote>
<p>Adam Fowler <a href="https://forums.swift.org/t/mqttnio/53238">pitched</a> the library <a href="https://github.com/adam-fowler/mqtt-nio">MQTTNIO</a> for inclusion in the SSWG package list.</p>
<blockquote>
<p>MQTT is a messaging protocol commonly used for communicating with IoT (Internet of Things) devices. It is a lightweight publish/subscribe message transport designed to have a small code footprint and network bandwidth.</p>
</blockquote>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> <a href="https://forums.swift.org/t/swiftnio-swift-version-support/53232">updated</a> us about the SwiftNIO Swift version support.</p>
<blockquote>
<p>The SwiftNIO team has made it a major pillar of our workflow to attempt to support Swift releases for a reasonably long time. Most users don’t take advantage of this, preferring to stay on the most recent release of Swift, but we think it’s important that you have confidence that newly written applications will get some meaningful amount of support going forward.</p>
</blockquote>
<p><a href="https://twitter.com/QuietMisdreavus">Victoria Mitchell</a> wrote <a href="https://forums.swift.org/t/extending-swift-docc-to-support-objective-c-documentation/53243">a post</a> about extending Swift-DocC to support Objective-C documentation.</p>
<blockquote>
<p>DocC is currently architected to render symbol documentation in a single language (Swift). However, there are cross-language projects that would benefit from collecting multiple “language variants” together into the same set of documentation, for example for Objective-C APIs that can be called from Swift or vice-versa.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1451258136648511488">π</a></p>
<p><a href="https://twitter.com/throwboy/status/1453739351179816960">The Iconic Pillow Collection 2</a>.</p>
<p><a href="https://twitter.com/niw/status/1455258442541711365?s=21">Infinite energy</a>.</p>
<p><a href="https://twitter.com/AirspeedSwift/status/1455735695855677447">Cornelius Dispatch</a>.</p>
Issue #196
https://swiftweeklybrief.com/issue-196
2021-10-21T00:00:00-07:00
2021-10-21T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Let me start with some very exciting news - our Swift Weekly Brief has been translated into the Chinese language. You can explore translations <a href="https://github.com/SwiftCommunityRes/SwiftWeekly">here</a>. I am thrilled to share this with all of you as I truly believe that reaching more people from around the world who can make an impressive contribution to our community is our way to broaden horizons leading to new inventions.</p>
<p>Meanwhile, Apple hosted its ‘Unleashed’ event and announced some new impressive hardware, satisfying everyone’s taste. Kids will soon be asking Santa for new AirPods and a colorful HomePod Mini to put under Christmas trees later this year, and professional artists are enthusiastic about new powerful MacBook Pros with Apple’s new chips, either the M1 Pro or M1 Max, with four-wheel-drive versions of the M1 chip they presented last fall. Let me know your thoughts about these new machines. Personally, I am looking forward to the 14-inch desktop as it perfectly fits my needs.</p>
<p>Just a kind reminder that we have various opportunities for sponsorship to help us run this project. You can always find more info about the options <a href="https://swiftweeklybrief.com/sponsorship/">here</a>. Also, I would like to give a shout-out to our current sponsors - we are grateful and appreciate your support.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p><a href="https://bugs.swift.org/browse/SR-15312">SR-15312</a> [Swift-DocC] Add ‘version’ command to docc command line tool</p>
<p><a href="https://bugs.swift.org/browse/SR-15313">SR-15313</a> [Swift-DocC] Primary tutorial navigation dropdown fails to bold the current tutorial when browser URL is not lowercased</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="http://twitter.com/franklinschrans">Franklin Schrans</a> <a href="https://swift.org/blog/swift-docc/">announced</a> <a href="https://forums.swift.org/t/announcing-swift-docc/52797">Swift-DocC</a> will be <a href="https://github.com/apple/swift-docc">open sourced</a>.</p>
<p><a href="https://twitter.com/icanzilb">Marin Todorov</a> finally <a href="https://twitter.com/icanzilb/status/1448555769050304512">revealed</a> his work on <a href="https://github.com/apple/swift-markdown">Swift Markdown</a>.</p>
<p><a href="https://twitter.com/zntfdr">Federico Zanetello</a> wrote <a href="https://www.fivestars.blog/articles/warn_unqualified_access/">a blog post</a> explaining <code class="language-plaintext highlighter-rouge">@warn_unqualified_access</code>.</p>
<p><a href="https://twitter.com/davedelong">Dave DeLong</a> explained <a href="https://davedelong.com/blog/2021/10/09/simplifying-backwards-compatibility-in-swift/">how</a> to simplify backwards compatibility in Swift.</p>
<p>Documentation for Swift-DocC is now on <a href="https://swift.org/documentation/docc/">Swift.org</a> (<a href="https://forums.swift.org/t/documentation-for-swift-docc-is-now-on-swift-org/52914">using Swift-DocC!</a>).</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0325-swiftpm-additional-plugin-apis.md">SE-0325</a>: <em>Additional Package Plugin APIs</em> is <a href="https://forums.swift.org/t/se-0325-additional-package-plugin-apis/52788">under review</a>.</p>
<blockquote>
<p>SE-0303 introduced the ability to define <em>build tool plugins</em> in SwiftPM, allowing custom tools to be invoked while building a package. In support of this, SE-0303 introduced a minimal initial API through which plugins can access information about the target for which they are invoked.</p>
<p>This proposal extends the plugin API to provide more context, including a richer representation of the package graph. This is in preparation for supporting new kinds of plugins in the future.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/nuriamari">Nuri Amari</a> pitched <a href="https://forums.swift.org/t/pitch-improved-clangimporter-diagnostics/52687">a proposal</a> to improve <code class="language-plaintext highlighter-rouge">ClangImporter</code> diagnostics.</p>
<blockquote>
<p>We would like to propose improvements to the ClangImporter to provide more detailed diagnostics when an entity cannot be imported from C or Objective-C. As it stands, when the ClangImporter fails to import an entity (function, type, macro, etc.) either entirely or partially, failure is largely silent. The current Swift compilation errors present largely as if the entity was never defined at all.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/jumhyn">Frederick Kellison-Linn</a> pitched <a href="https://forums.swift.org/t/pitch-generalize-keypath-to-function-conversions/52681">an idea</a> to generalize keypath-to-function conversions.</p>
<blockquote>
<p>This proposal introduces the ability to use the key path expression <code class="language-plaintext highlighter-rouge">\Root.value</code> wherever functions of <code class="language-plaintext highlighter-rouge">(Root) -> Value</code> are allowed.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/key-path-expressions-as-functions/19587">Key Path Expressions as Functions</a></p>
</blockquote>
<p><a href="https://forums.swift.org/u/patrick_pijnappel">Patrick Pijnappel</a> pitched <a href="https://forums.swift.org/t/pitch-exhaustive-pattern-matching-for-non-open-classes/52718">a proposal</a> to implement exhaustive pattern matching for non-open classes.</p>
<blockquote>
<p>Since we now make the distinction between open and non-open classes, it seems we should be able to make non-open class hierarchies exhaustively matchable. This would be a nice win for compile-time checks in the face of adding a new subclass, without any added syntax.</p>
</blockquote>
<p>Guillaume Lessard <a href="https://forums.swift.org/t/pitch-pointer-usability-improvements/52736">pitched</a> improvements to pointer usability.</p>
<blockquote>
<p>This proposal introduces some quality-of-life improvements for <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and its <code class="language-plaintext highlighter-rouge">Mutable</code> and <code class="language-plaintext highlighter-rouge">Raw</code> variants.</p>
<ol>
<li>Add an API to obtain an <code class="language-plaintext highlighter-rouge">UnsafeRawPointer</code> instance that is advanced to a given alignment from its starting point.</li>
<li>Add an API to obtain a pointer to a stored property of an aggregate <code class="language-plaintext highlighter-rouge">T</code>, given an <code class="language-plaintext highlighter-rouge">UnsafePointer<T></code>.</li>
<li>Rename the unchecked subscript of <code class="language-plaintext highlighter-rouge">Unsafe[Mutable]Pointer</code> to include the argument label <code class="language-plaintext highlighter-rouge">unchecked</code>.</li>
<li>Add the ability to compare pointers of any two types.</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> pitched <a href="https://forums.swift.org/t/pitch-light-weight-same-type-constraint-syntax/52889">a proposal</a> to improve same-type constraint syntax.</p>
<blockquote>
<p>As a step toward the goal of improving the UI of generics outlined in <a href="https://forums.swift.org/t/improving-the-ui-of-generics/22814#heading--directly-expressing-constraints">Improving the UI of generics</a>, we’d like to propose a couple of improvements that bridge the syntactic gap between protocols and generic types, and hide some of the complexity (both visual and cognitive) of writing same-type constraints on associated types and type parameters of generic types.</p>
</blockquote>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> started <a href="https://forums.swift.org/t/discussion-easing-the-learning-curve-for-introducing-generic-parameters/52891">a discussion</a> about easing the learning curve for introducing generic parameters.</p>
<blockquote>
<p>Swift’s generics system is highly expressive, but understanding the full generality of protocols with associated types, generic signatures with where clauses, and other generics features is a significant barrier to introducing generics into a Swift project. A major goal of a more approachable generics system is easing the learning curve of abstracting a concrete API into a generic one by improving the ergonomics of writing generic code in Swift. This discussion is to solicit feedback on possible directions toward achieving this goal, and gather other ideas surfaced by the community. <strong>Questions, comments, and ideas are all welcome!</strong></p>
<p>Many of the ideas in this post were laid out by <a href="https://forums.swift.org/u/joe_groff">@Joe_Groff</a> in <a href="https://forums.swift.org/t/improving-the-ui-of-generics/22814">Improving the UI of generics</a>.</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched <a href="https://forums.swift.org/t/pitch-character-classes-for-string-processing/52920">an idea</a> to implement character classes for String processing.</p>
<blockquote>
<p><a href="https://forums.swift.org/t/declarative-string-processing-overview/52459">Declarative String Processing Overview</a> presents regex-powered matching broadly, without details concerning syntax and semantics, leaving clarification to subsequent pitches. <a href="https://forums.swift.org/t/pitch-regular-expression-literals/52820">Regular Expression Literals</a> presents more details on regex <em>syntax</em> such as delimiters and PCRE-syntax innards, but explicitly excludes discussion of regex <em>semantics</em>. This pitch and discussion aims to address a targeted subset of regex semantics: definitions of character classes. We propose a comprehensive treatment of regex character class semantics in the context of existing and newly proposed API directly on <code class="language-plaintext highlighter-rouge">Character</code> and <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code>.</p>
<p>Character classes in regular expressions include metacharacters like <code class="language-plaintext highlighter-rouge">\d</code> to match a digit, <code class="language-plaintext highlighter-rouge">\s</code> to match whitespace, and <code class="language-plaintext highlighter-rouge">.</code> to match any character. Individual literal characters can also be thought of as character classes, as they at least match themselves, and, in case-insensitive matching, their case-toggled counterpart. For the purpose of this work, then, we consider a <em>character class</em> to be any part of a regular expression literal that can match an actual component of a string.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/andy_matuschak/status/1447408339160231947">HIG from 1987</a>.</p>
<p><a href="https://twitter.com/pteasima/status/1448634571315195905">Its pronounced M 1 “ten”</a>.</p>
<p><a href="https://twitter.com/jckarter/status/1448736493590114317"> Pascal</a>.</p>
Issue #195
https://swiftweeklybrief.com/issue-195
2021-10-07T00:00:00-07:00
2021-10-07T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>We’re starting today’s newsletter with some hiring news from Apple: they are <a href="https://twitter.com/jckarter/status/1441445811523502088">looking for paid interns</a> for their language, compiler and debugger teams. Even if you don’t have experience in the specific field, interested students are encouraged to apply anyway. If you’d like to understand better how internships work, have a look at <a href="https://forums.swift.org/t/swift-mentorship-compiler-language-design/52522">this</a> insightful article about <a href="https://twitter.com/Amritpan">Amritpan Kaur’s</a> path through Compiler Development and Language Design.</p>
<p>There have been some really nice improvements made to Swift.org recently, including <a href="https://forums.swift.org/t/swift-org-in-dark-mode/52495">support for dark mode</a>. For those of you using dark mode on iOS, the website will automatically switch modes to match. I hope you’re enjoying this feature as much as I am.</p>
<p>As always, I want to express our appreciation for the support from our sponsors. Without you this newsletter wouldn’t exist, so thank you very much. If anyone else is interested in sponsorship, please kindly get in touch. More information on how you could participate in our project can be found <a href="https://swiftweeklybrief.com/sponsorship/">here</a>.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://iosacademy.essentialdeveloper.com/p/ios-architect-crash-course-swbe1c9/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_195" target="_blank">Free Course for Mid to Senior iOS Developers</a></h4>
<p>From October 18th to 24th you can join a free practical crash course for iOS devs who want to become complete senior developers.</p>
<p><small><a href="https://iosacademy.essentialdeveloper.com/p/ios-architect-crash-course-swbe1c9/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_195" target="_blank">iosacademy.essentialdeveloper.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-15271">SR-15271</a> [Compiler] Improve Codable Diagnostics When <code class="language-plaintext highlighter-rouge">CodingKeys</code> Do Not Match Properties</p>
</blockquote>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> wrote <a href="https://swift.org/blog/swift-5-5-released/">a post</a> about the Swift 5.5 release.</p>
<p><a href="https://twitter.com/rockbruno_">Bruno Rocha</a> published <a href="https://swiftrocks.com/how-asyncsequence-works-internally-in-swift">a great article</a> explaining how <code class="language-plaintext highlighter-rouge">AsyncSequence</code> works internally in Swift.</p>
<p><a href="https://twitter.com/Lee_Kah_Seng">Lee Kah Seng</a> wrote <a href="https://swiftsenpai.com/swift/actor-reentrancy-problem/">a cool article</a> describing the actor reentrancy problem in Swift.</p>
<p><a href="https://twitter.com/Amritpan">Amritpan Kaur</a> <a href="https://forums.swift.org/t/swift-mentorship-compiler-language-design/52522">explained</a> how she participated in the inaugural Swift Mentorship and worked on Compiler Development and Language Design.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/milseman">Michael Ilseman</a> merged <a href="https://github.com/apple/swift/pull/38922">a pull request</a> that implements native normalization for String.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> created <a href="https://github.com/apple/swift/pull/39609">a pull request</a> that would back-deploy <code class="language-plaintext highlighter-rouge">@objc</code> actor types.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0322-temporary-buffers.md">SE-0322</a> <em>Temporary Uninitialized Buffers</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0322-temporary-uninitialized-buffers/52532">accepted with modifications</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0323-async-main-semantics.md">SE-0323</a> <em>Asynchronous Main Semantics</em> was <a href="https://forums.swift.org/t/accepted-se-0323-asynchronous-main-semantics/52531">accepted</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0324-c-lang-pointer-arg-conversion.md">SE-0324</a> <em>Relax diagnostics for pointer arguments to C functions</em> was <a href="https://forums.swift.org/t/accepted-se-0324-relax-diagnostics-for-pointer-arguments-to-c-functions/52599">accepted</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/swift-server/sswg/blob/main/proposals/0017-multipart-kit.md">SSWG-0017</a>: <em>MultipartKit</em> is <a href="https://forums.swift.org/t/sswg-0017-multipartkit/52586">under review</a>.</p>
<blockquote>
<p>MultipartKit offers both low level parsing and serializing of Multipart data as well as high level Codable support for encoding and decoding Multipart form data.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/lorentey">Karoy Lorentey</a> <a href="https://forums.swift.org/t/when-should-managedatomic-unsafeatomic-be-marked-sendable/52321">asked</a> when should <code class="language-plaintext highlighter-rouge">ManagedAtomic</code>/<code class="language-plaintext highlighter-rouge">UnsafeAtomic</code> be marked <code class="language-plaintext highlighter-rouge">Sendable</code>?</p>
<blockquote>
<p>I just filed <a href="https://github.com/apple/swift-atomics/issues/45">issue #45</a>, asking <code class="language-plaintext highlighter-rouge">UnsafeAtomic</code>, <code class="language-plaintext highlighter-rouge">ManagedAtomic</code> and friends to be marked <code class="language-plaintext highlighter-rouge">Sendable</code>, reflecting that they are safe to transfer across concurrency domains.</p>
</blockquote>
<p><a href="https://twitter.com/call1cc">Kavon Farvardin</a> <a href="https://forums.swift.org/t/proposal-actor-initializers-and-deinitializers/52322">proposed</a> to define how actor initializers work in Swift.</p>
<blockquote>
<p>The proposed solution to some of the problems described in this proposal are currently reflected in Swift 5.5 through a warning, but it’s important to review these changes for Swift 6. In addition, this proposal adds extra capabilities for the <code class="language-plaintext highlighter-rouge">deinit</code> of MainActor-isolated class, to make them easier and safer to write. I’ll paste the entire proposal below, but for the most up-to-date write-up, <a href="https://github.com/kavon/swift-evolution/blob/actor-init-proposal2/proposals/nnnn-actor-initializers.md">go here</a>.</p>
</blockquote>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> <a href="https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344">discovered</a> that Swift 5.5 has serious stack corruption bugs.</p>
<blockquote>
<p>I’ve discovered several stack corruption bugs related to <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code> which can be reproduced in simple test programs compiled with recent nightly toolchains. <strong>i have confirmed that <del>two</del> <del>three</del> four of these bugs are present in the 5.5-RELEASE toolchain.</strong></p>
</blockquote>
<p><a href="https://forums.swift.org/u/beccadax">Becca Royal-Gordon</a> pitched <a href="https://forums.swift.org/t/pitch-2-staging-in-sendable-checking/52413">a proposal</a> to add staging in sendable checking.</p>
<blockquote>
<p>A couple weeks ago, <a href="https://forums.swift.org/u/douglas_gregor">@Douglas_Gregor</a> <a href="https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341">pitched some changes which tried to tackle</a> some of the problems involved in adopting <code class="language-plaintext highlighter-rouge">Sendable</code> checking in a module when some of your clients or dependencies may not have updated yet. I had some concerns about how that pitch’s approach might break or hide bugs when modules were eventually updated, as well as with how Objective-C libraries would be able to control the sendability of their types.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/stevapple">YR Chen</a> started <a href="https://forums.swift.org/t/upon-swift-6-solve-inconsistency-within-the-language/52437">a discussion</a> around solving inconsistencies with the release of Swift 6.</p>
<blockquote>
<p>The arrival of Swift 6 means a chance for “regretting” some language designs with API breakage — after 3 years which is fairly a long time for Swift and the Swift community. With the Swift 3.2 and Swift 4.2 effort, transition to a breaking Swift release has proved to be a lot smoother.</p>
<p>I would suggest we pick up some of the deferred breaking pitches, which intended to eliminate inconsistency within the language. These ideas have already received positive feedbacks from the community, and yet didn’t make their ways into reality.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/philippe_hausler">Philippe Hausler</a> pitched <a href="https://forums.swift.org/t/pitch-clock-instant-date-and-duration/52451">a proposal</a> to define <code class="language-plaintext highlighter-rouge">Clock</code>, <code class="language-plaintext highlighter-rouge">Instant</code>, <code class="language-plaintext highlighter-rouge">Date</code>, and <code class="language-plaintext highlighter-rouge">Duration</code>.</p>
<blockquote>
<p>The concepts of time can be broken down into three distinct parts: an item to provide a concept of now plus a way to wake up after a given point in time, a concept of a point in time, and a concept of a measurement in time. These three items are respectively a clock, an instant and a duration. The measurement of time can be used for many types of APIs, all the way from the high levels of a concept of a timeout on a network connection, to the amount of time to sleep a task. Currently the APIs that take measurement of time types take <code class="language-plaintext highlighter-rouge">NSTimeInterval</code> aka <code class="language-plaintext highlighter-rouge">TimeInterval</code>, <code class="language-plaintext highlighter-rouge">DispatchTimeInterval</code>, and even types like <code class="language-plaintext highlighter-rouge">timespec</code>.</p>
</blockquote>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> pitched <a href="https://forums.swift.org/t/declarative-string-processing-overview/52459">an idea</a> to implement declarative string processing APIs.</p>
<blockquote>
<p>String processing is hard and the current affordances provided by the Swift Standard Library are underpowered. We propose adding two new <em>declarative</em> string processing APIs—a familiar <code class="language-plaintext highlighter-rouge">Regex</code> literal and a more powerful <code class="language-plaintext highlighter-rouge">Pattern</code> result builder—to help make Swift string processing fast and easy.</p>
<p>This is a large feature that will ultimately be divided into multiple Swift Evolution proposals. This initial pitch is intended to prompt discussion about the high level direction and to introduce the key prongs of the feature and their relationship to one another.</p>
</blockquote>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> started <a href="https://forums.swift.org/t/we-need-long-term-support-lts-releases/52462">a discussion</a> around long-term-support (“LTS”) releases.</p>
<blockquote>
<p>for those who don’t follow the <a href="https://forums.swift.org/c/development">Development</a> topic, <a href="https://forums.swift.org/u/mickeyl">@mickeyl</a>, <a href="https://forums.swift.org/u/timdecode">@timdecode</a>, and i have recently <a href="https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344">uncovered an alarming number of highly dangerous stack corruption bugs</a> in the Swift 5.5 release toolchain.</p>
<p>setting aside the technical aspects of the stack corruption issues in Swift 5.5, which are detailed in the <a href="https://forums.swift.org/t/swift-5-5-has-serious-stack-corruption-bugs/52344">corresponding thread</a>, i would like to kickoff discussions on whether it would be valuable for us to adopt some form of the concept of a <a href="https://en.wikipedia.org/wiki/Long-term_support">“Long-Term Support” (LTS) release 8</a> in our release cycle, much like Ubuntu has been doing for some time.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/abertelrud">Anders Bertelrud</a> pitched <a href="https://forums.swift.org/t/pitch-additional-api-available-to-swiftpm-plugins/52494">a proposal</a> to extend the plugin SwiftPM plugin API to provide more context.</p>
<blockquote>
<p>SE-0303 introduced SwiftPM plugins, focusing in particular on build tool plugins (especially those that generate source code). To keep that proposal bounded, the type and amount of information available to a plugin was geared toward the task of generating build commands.</p>
<p>Before starting to consider new kinds of plugins, it seems prudent to expand the information available to plugins of all kinds. Future proposals might add specific APIs for particular kinds of plugins, but before that, it seems that a good starting point would be to give all plugins access to a distilled form of the package graph that SwiftPM already has internally. This should allow a wide latitude in terms of what any particular plugin wants to do.</p>
<p>I’d like to pitch a draft proposal for extending the API available to SwiftPM plugins, and would love to hear what everyone thinks. There’s an implementation in a PR in the SwiftPM repository.</p>
</blockquote>
<p>Guillaume Lessard pitched <a href="https://forums.swift.org/t/pitch-expand-usability-of-withmemoryrebound/52500">a proposal</a> to expand usability of <code class="language-plaintext highlighter-rouge">withMemoryRebound</code>.</p>
<blockquote>
<p>The function <code class="language-plaintext highlighter-rouge">withMemoryRebound(to:capacity:_ body:)</code> executes a closure while temporarily binding a range of memory to a different type than the callee is bound to.</p>
<p>We propose to lift some notable limitations of <code class="language-plaintext highlighter-rouge">withMemoryRebound</code> and enable rebinding to a larger set of types, as well as rebinding from raw memory pointers and buffers.</p>
</blockquote>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> <a href="https://forums.swift.org/t/async-await-and-the-future-of-vapor/52590">updated</a> us about <code class="language-plaintext highlighter-rouge">async/await</code> and the future of Vapor.</p>
<p><a href="https://forums.swift.org/u/drewmccormack">Drew McCormack</a> pitched <a href="https://forums.swift.org/t/proposal-a-standard-library-type-for-working-with-shared-data-in-a-concurrent-system/52603">a proposal</a> that would create standard library data structures designed for working with shared data in a concurrent system.</p>
<blockquote>
<p>I want to propose such a type here: a branching resource.</p>
<p>A BranchingResource would be a type with a generic parameter for the payload it carries (ie the resource). The resource would begin with a single branch, called “main” or “trunk” or “truth”. The app could add as many auxiliary, named branches as it likes.</p>
</blockquote>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> pitched <a href="https://forums.swift.org/t/pitch-enable-multi-statement-closure-parameter-result-type-inference/52619">an idea</a> to enable multi-statement closure parameter/result type inference.</p>
<blockquote>
<p>I propose to improve inference behavior of multi-statement closures by enabling parameter and result type inference from the closure body. This will make type inference less surprising for developers, and remove the existing behavior cliff where adding one more expression or statement to a closure could result in a compilation failure.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1444003858468855816">typedef unsigned char BOO_L; // 👻</a></p>
Issue #194
https://swiftweeklybrief.com/issue-194
2021-09-23T00:00:00-07:00
2021-09-23T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>How many of you have pre-ordered the new iPhone 13? Tomorrow is the big day, when we can see the new device hit the store shelves. Apple claims that the new iPhone has a brand new dual-camera system, a super-fast A15 chip and a massive leap in battery life.</p>
<p>But we are here not only for the new and pretty iPhone colors – Xcode 13.0 was released just a couple of days ago along with <a href="https://forums.swift.org/t/swift-5-5-released/52247">Swift 5.5</a>. Here’s a listing of Swift 5.5 <a href="https://twitter.com/simjp/status/1440318174856036354">updates</a>. This is a big release, and it includes quite a few new features. The iOS 13.0 release notes can be found <a href="https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-15-release-notes">here</a>. And the work to <a href="https://github.com/apple/swift/pull/39342">back-deploy concurrency features</a> to older Swift versions has begun.</p>
<p>To keep running this project and send you this newsletter, we are inviting sponsors to reach out. Your support is very much appreciated and helps us cover the platform costs.</p>
<p>Thanks to everyone involved and let’s get straight to the news.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> <a href="https://forums.swift.org/t/swift-crypto-2-0-0/52308">informed</a> us that Swift Crypto 2.0.0 was released.</p>
<h3 id="starter-tasks">Starter tasks</h3>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-15218">SR-15218</a> [Compiler] Enhance interchangeable CGFloat/Double to allow interchange between optional</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/salinas-miguel">salinas-miguel</a>’s PR that removes the Swift project’s dependency on Foundation on macOS was <a href="https://github.com/apple/swift/pull/39216">merged</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> created <a href="https://github.com/apple/swift/pull/39342">a pull request</a> to back-deploy concurrency.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0323-async-main-semantics.md">SE-0323</a>: <em>Asynchronous Main Semantics</em> is <a href="https://forums.swift.org/t/se-0323-asynchronous-main-semantics/52022">under review</a>.</p>
<blockquote>
<p>Program setup generally occurs in the main function where developers expect to perform operations before other parts of the program are run. Objective-C, C++, and C have initializers that are run before the main entrypoint runs and can interact with Swift’s concurrency systems in ways that are hard to reason about. In the Swift concurrency model, the developer-written asynchronous main function is wrapped in a task and enqueued on the main queue when the main entrypoint is run. If an initializer inserts a task on the main queue, that task may be executed before the main function, so setup is performed after initializer tasks are run.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0324-c-lang-pointer-arg-conversion.md">SE-0324</a>: <em>Relax diagnostics for pointer arguments to C functions</em> is <a href="https://forums.swift.org/t/se-0324-relax-diagnostics-for-pointer-arguments-to-c-functions/52019">under review</a>.</p>
<blockquote>
<p>C has special rules for pointer aliasing, for example allowing <code class="language-plaintext highlighter-rouge">char *</code> to alias other pointer types, and allowing pointers to signed and unsigned types to alias. The usability of some C APIs relies on the ability to easily cast pointers within the boundaries of those rules. Swift generally disallows typed pointer conversion. See <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0107-unsaferawpointer.md">SE-0107 UnsafeRawPointer API</a>. Teaching the Swift compiler to allow pointer conversion within the rules of C when invoking functions imported from C headers will dramatically improve interoperability with no negative impact on type safety.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/bitjammer">Ashley Garland</a> <a href="https://forums.swift.org/t/swift-snippets/51947">introduced</a> some experimental work for a new Swift Package Manager feature for <em>snippets</em>.</p>
<blockquote>
<p>We all know that learning by example is great, especially for code. I wanted to create the smallest, simplest method of providing example code for Swift packages, and I’ve just landed some <a href="https://github.com/apple/swift-package-manager/commit/a0ffd92a2c80f2c4677d696e248f4cfbec9d6540">work in progress in the Swift Package Manager</a>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/filip-sakel">Filip Sakel</a> pitched <a href="https://forums.swift.org/t/pitch-refining-property-wrapper-related-initialization/52049">a proposal</a> to refine property wrapper related initialization.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md">SE 0258</a> introduced property wrappers and <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md#detailed-design">SE 0293</a> expanded them with function-like declarations. Today, property wrapper initialization exhibits inconsistencies due to its growing versatility. Specifically, memberwise initializers use complex, poorly documented rules and projection initialization remains limited. This proposal will simplify synthesized memberwise initialization for types with wrapped properties and extend projection value initialization to include global, type, and local wrapped properties.</p>
</blockquote>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> started <a href="https://forums.swift.org/t/pre-pitch-remove-the-implicit-initialization-of-optional-variables/52300">a discussion</a> about removing the implicit initialization of Optional variables.</p>
<blockquote>
<p>In Swift 6, optional variables become uninitialized by default, like all other variables. Locals and globals get a fix-it to add <code class="language-plaintext highlighter-rouge">= nil</code>. Properties only get that fix-it in a note attached to the error about leaving the variable uninitialized, since it’s not obviously the right thing to do, only the Swift 5 thing to do. A migrator could auto-apply that fix too though.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jordanpittman/status/1437946722358005769">This would explain why my phone is hot all the time</a>.</p>
<p><a href="https://twitter.com/molly_struve/status/1440777471259860992">Dress code</a>.</p>
Issue #193
https://swiftweeklybrief.com/issue-193
2021-09-09T00:00:00-07:00
2021-09-09T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p><a href="https://www.apple.com/apple-events/">California streaming</a>. We all know what that means: a big day is coming next week - Apple has announced an event on September 14! They hid an easter egg inside the event invitation - <a href="https://9to5mac.com/2021/09/07/apple-hypes-next-weeks-iphone-13-event-with-ar-portal-experience/">a hidden AR experience</a>, and it looks pretty cool. This also allowed fans across the globe to speculate about what upcoming products Apple is going to announce. It was suggested that the rose gold color of the skies inside the portal gives us the first glance of the new iPhone’s colors. Well, we’ll find out in less than a week.</p>
<p>The last two weeks have been full of activities in the Swift community. Many proposals are being generated in Swift evolution; some have been accepted or returned, and some are still in review. These proposals help to facilitate Swift remaining a modern language, so let’s keep them rolling!</p>
<p>I want to thank everyone in the Swift community involved in this project. If you want to support our newsletter financially, please reach out as we have a few <a href="https://swiftweeklybrief.com/sponsorship/">sponsorship slots available</a>.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> wrote <a href="https://www.swiftbysundell.com/articles/conditional-compilation-within-swift-expressions/">an article</a> explaining conditional compilation within Swift expressions.</p>
<p><a href="https://twitter.com/gabtheodor">Gabriel Theodoropoulos</a> wrote <a href="https://serialcoder.dev/text-tutorials/swift-tutorials/using-variadic-parameters-in-swift/">a blog post</a> explaining how to use variadic parameters in Swift.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/39051">a pull request</a> that adds an option to build the concurrency library for back deployment.</p>
<p><a href="https://github.com/fwcd">FW</a> merged <a href="https://github.com/apple/sourcekit-lsp/pull/414">a pull request</a> that implements semantic highlighting for Swift.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0321-package-registry-publish.md">SE-0321</a> <em>Package Registry Service - Publish Endpoint</em> was <a href="https://forums.swift.org/t/accepted-se-0321-package-registry-service-publish-endpoint/51660">accepted</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md">SE-0304</a> <em>Structured Concurrency</em> <a href="https://forums.swift.org/t/se-0304-4th-review-structured-concurrency/50281">fourth review</a> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0304-structured-concurrency/51850">accepted</a>.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0320-codingkeyrepresentable.md">SE-0320</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0320-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/51706">returned for revision</a>.</p>
<blockquote>
<p>The feedback from the review was positive, and members of the community suggested several improvements that the author and core team felt would be good to adopt:</p>
<ol>
<li>Adding conformance for <code class="language-plaintext highlighter-rouge">String</code> and <code class="language-plaintext highlighter-rouge">Int</code> to <code class="language-plaintext highlighter-rouge">CodingKeyRepresentable</code> which will allow the natural use of <code class="language-plaintext highlighter-rouge">String</code> and <code class="language-plaintext highlighter-rouge">Int</code> keys when <code class="language-plaintext highlighter-rouge">CodingKeyRepresentable</code> is used as a generic constraint.</li>
<li>Make the initializer of the <code class="language-plaintext highlighter-rouge">CodingKeyRepresentable</code> protocol be generic.</li>
<li>Provide default implementations for the conformance for <code class="language-plaintext highlighter-rouge">RawRepresentable</code> (with <code class="language-plaintext highlighter-rouge">String</code> and <code class="language-plaintext highlighter-rouge">Int</code> raw values).</li>
<li>Make the initializers of the internal <code class="language-plaintext highlighter-rouge">_DictionaryCodingKey</code> non-failable.</li>
</ol>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0320-codingkeyrepresentable.md">SE-0320</a>: <em>Coding of non String / Int keyed Dictionary into a KeyedContainer</em> is <a href="https://forums.swift.org/t/se-0320-2nd-review-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/51710">under a second review</a>.</p>
<blockquote>
<p>The second review is focused on the proposed improvements made by the community during the first review, and addressed by <a href="https://github.com/apple/swift-evolution/pull/1435">swift-evolution#1435</a>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md">SE-0292</a>: <em>Package Registry Service</em> <a href="https://github.com/apple/swift-evolution/pull/1410">amendment</a> <a href="https://forums.swift.org/t/amendment-se-0292-package-registry-service/51663">is under review</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a>: <em>Package Manager Extensible Build Tools</em> <a href="https://github.com/apple/swift-evolution/pull/1434">amendment</a> <a href="https://forums.swift.org/t/amendment-se-0303-package-manager-extensible-build-tools/51763">is under review</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0322-temporary-buffers.md">SE-0322</a>: <em>Temporary Uninitialized Buffers</em> <a href="https://forums.swift.org/t/se-0322-temporary-uninitialized-buffers/51848">is under review</a>.</p>
<blockquote>
<p>This proposal introduces new Standard Library functions for manipulating temporary buffers that are preferentially allocated on the stack instead of the heap.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/pitch-temporary-uninitialized-buffers/48954">[Pitch] Temporary uninitialized buffers</a></p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/maustinstar">Michael Verges</a> pitched <a href="https://forums.swift.org/t/pitching-optional-throws-in-swift/51650">a proposal</a> to add optional <code class="language-plaintext highlighter-rouge">throws</code> in Swift.</p>
<blockquote>
<p>There are many cases when jurisdiction of error handling is unclear. Developers may question whether to handle or propogate errors.</p>
<p>Choosing to throw errors provides the benefit that callers can flexibly handle problems.</p>
<p>Choosing to not throw errors provides the benefit of simplifying syntax to users (no <code class="language-plaintext highlighter-rouge">do-try-catch</code>).</p>
</blockquote>
<p>Karl <a href="https://forums.swift.org/t/api-changes-for-0-2-0/51647">informed</a> the community about <a href="https://karwa.github.io/swift-url/">WebURL</a> version 0.2.0.</p>
<blockquote>
<p>I’m getting ready to release version 0.2.0 of WebURL. It’s going to be an exciting and important release, including a <code class="language-plaintext highlighter-rouge">WebURLSystemExtras</code> module for integration with <code class="language-plaintext highlighter-rouge">System.framework</code> and the <code class="language-plaintext highlighter-rouge">swift-system</code> package, and aligning the project with the very latest revision of the URL Standard.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/patrickgoley">Patrick Goley</a> pitched <a href="https://forums.swift.org/t/pitch-destructuring-assignment-of-structs-and-classes/51593">a proposal</a> to add destructuring assignment of structs and classes.</p>
<blockquote>
<p>Destructuring assignment is a language feature that allows you to extract multiple parts of a value and assign them to multiple variables within a single assignment statement.</p>
</blockquote>
<p><a href="https://twitter.com/stephentyrone">Steve Canon</a> <a href="https://forums.swift.org/t/1-0-0-release-notes/51641">announced</a> that the <a href="https://github.com/apple/swift-numerics/releases/tag/1.0.0">first stable release</a> of Swift Numerics is now available.</p>
<p>Austin started a <a href="https://forums.swift.org/t/netlink-socket-support-in-swiftnio/51651">conversation</a> about netlink socket support in SwiftNIO.</p>
<p><a href="https://forums.swift.org/u/ktoso">Konrad <code class="language-plaintext highlighter-rouge">ktoso</code> Malawski</a> pitched <a href="https://forums.swift.org/t/pitch-distributed-actors/51669">a proposal</a> to implement distributed actors.</p>
<blockquote>
<p>With the recent introduction of Swift concurrency, and most notably actors to the language, Swift gained powerful and foundational building blocks for expressing <em>thread-safe</em> concurrent programs. This proposal aims to extend Swift’s actors with the ability to work equally well for distributed systems thanks to the introduction of <em>distributed actors</em> and <em>location transparency</em> associated with them.</p>
</blockquote>
<p><a href="https://twitter.com/maxdesiatov">Max Desiatov</a> <a href="https://forums.swift.org/t/swiftwasm-5-4-0-has-been-released/51753">informed</a> us that <a href="https://github.com/swiftwasm/swift/releases/tag/swift-wasm-5.4.0-RELEASE">SwiftWasm 5.4.0</a> is out.</p>
<blockquote>
<p>This release matches upstream Swift 5.4, and allows you to compile Swift apps (as long as they don’t use code specific to other platforms) to WebAssembly, and even run them in the browser.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/elsh">elsh</a> pitched <a href="https://forums.swift.org/t/pitch-module-aliasing/51737">a proposal</a> to add module aliasing support.</p>
<blockquote>
<p>As Swift libraries and packages are more widely distributed, module names sometimes end up clashing. As there’s no module namespace yet in Swift, libraries are often forced to be renamed or pinned to an older non-conflicting version in such case. This makes use cases such as the following challenging:</p>
<ul>
<li>
<p>Adding a new dependency or upgrading as it can introduce a collision: A new (or upgraded) module can have the same name as another module already in the dependency graph. Module name Logging is a common example.</p>
</li>
<li>
<p>Upgrading to a newer version of a package from an older version pinned by an upstream library: Consider a scenario where MyApp depends on module Lib, and Lib depends on module Logging. MyApp also depends on Logging. If Lib is pinned to Logging 1.0.0, MyApp is stuck with the same version 1.0.0.</p>
</li>
</ul>
</blockquote>
<p>Swift on the Server Workgroup, on September 3rd, 2021, announced a <a href="https://forums.swift.org/t/september-3rd-2021-special-update/51766">special update</a>.</p>
<p><a href="https://forums.swift.org/u/iillx">Isabel Lima</a> <a href="https://forums.swift.org/t/pitch-introduce-expanded-parameters/51885">updated</a> us about the status of the <a href="https://forums.swift.org/t/add-shared-storage-to-property-wrappers/49898">Shared Storage for Property Wrappers</a> pitch.</p>
<blockquote>
<p>Swift is a language that allows us to write expressive API interfaces. With features like constrained Generics, method overloading, trailing closures, and default arguments, you can reduce code duplication while still achieving quite flexible APIs. This proposal aims to increment this part of the language with <code class="language-plaintext highlighter-rouge">@expanded</code>, a new attribute for function parameters.</p>
</blockquote>
<p><a href="https://github.com/johnno1962">John Holdsworth</a> <a href="https://forums.swift.org/t/introducing-an-unwrap-or-throw-operator/51905">proposed</a> adding an Unwrap or Throw operator.</p>
<blockquote>
<p>This thread is the love child of two previous contentious threads <a href="https://forums.swift.org/t/pitch-introducing-the-unwrap-or-die-operator-to-the-standard-library/6207">[Pitch] Introducing the “Unwrap or Die” operator to the standard library 2</a> and more recently <a href="https://forums.swift.org/t/moving-toward-deprecating-force-unwrap-from-swift/43455">Moving toward deprecating force unwrap from Swift?</a>. The latter thread did not reach a conclusion other than being locked and this thread picks up on the former thread proposing instead an “Unwrap or Throw” operator might be a better solution to the problem of forced unwraps in Swift which bugs me and I’m sure it bugs our users when their apps crash out.</p>
<p>In short, I’d like to propose a <code class="language-plaintext highlighter-rouge">!!</code> operator, a cross between a forced unwrap and nil coalescing that throws if an optional is nil..</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1433870421179334659">welsh for “dependency injection”</a>.</p>
Issue #192
https://swiftweeklybrief.com/issue-192
2021-08-26T00:00:00-07:00
2021-08-26T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>This week I spoke at the <a href="https://360idev.com/">360iDev</a> conference. I enjoy going to conferences and meeting fellow community members, but it is tough to do it in a remote environment. The organizers did a tremendous job to facilitate both worlds this year. Thank you!</p>
<p>The last two weeks were relatively silent in the open-source Swift world. But we have news that one of the maintainers of this newsletter, <a href="https://twitter.com/basthomas">Bas Broek</a>, might <a href="https://twitter.com/basthomas/status/1429113333748224000">join</a> this project in the future. :) If you want to participate by helping out or writing an issue, just reach out to us. This is by no means a personal project.</p>
<p>We have sponsorship availability for upcoming dates. Your support would be greatly appreciated by more than 10K Twitter followers and 4.5K newsletter subscribers! Head down <a href="https://swiftweeklybrief.com/sponsorship/">here</a> to learn more about how you could support this project. Thank you!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.swiftbysundell.com/podcast/103/">episode 103</a> of the Swift by Sundell podcast, <a href="https://twitter.com/twannl">Antoine van der Lee</a>, creator of SwiftLee, joins <a href="https://twitter.com/johnsundell">John Sundell</a>. They discuss the new language features that are being introduced as part of Swift 5.5 — from the brand-new concurrency system, to convenience features and various improvements.</p>
<h3 id="news-and-community">News and community</h3>
<p>It turns out that Xcode has documentation for its <a href="https://developer.apple.com/support/xcode/#minimum-requirements">minimum requirements and supported SDKs</a>.</p>
<p><a href="https://www.twitter.com/twannl">Antoine van der Lee</a> wrote <a href="https://www.avanderlee.com/swift/unwrap-or-throw/">a blog post</a> exploring unwrap or throw solutions in Swift.</p>
<p><a href="https://twitter.com/Leo_Pugliese">Leonardo Maia Pugliese</a> wrote <a href="https://holyswift.app/how-to-do-apis-constraints-with-available-in-swift">a blog post</a> about how to do APIs constraints with <code class="language-plaintext highlighter-rouge">@available</code> in Swift.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> wrote <a href="https://www.swiftbysundell.com/articles/using-an-unknown-default-case-within-a-switch-statement/">an article</a> explaining how to use <code class="language-plaintext highlighter-rouge">@unknown default</code> within switch statements.</p>
<p><a href="https://www.twitter.com/basthomas">Bas Broek</a> wrote <a href="https://www.basbroek.nl/deprecating-workarounds">a blog post</a> exploring how to deprecate workarounds in Swift.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0321-package-registry-publish.md">SE-0321</a>: <em>Package Registry Service - Publish Endpoint</em> is <a href="https://forums.swift.org/t/se-0321-package-registry-service-publish-endpoint/51286">under review</a>.</p>
<blockquote>
<p>A package registry is responsible for determining which package releases are made available to a consumer.</p>
<p>Currently, the availability of a package release is determined by an out-of-band process. For example, a registry may consult an index of public Swift packages and make releases available for each tag with a valid version number.</p>
<p>Having a standard endpoint for publishing a new release to a package registry would empower maintainers to distribute their software and promote interoperability across service providers.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/alvae">Dimitri Racordon</a> pitched <a href="https://forums.swift.org/t/pitch-protocols-with-private-fields/51209">an idea</a> to implement protocols with private fields.</p>
<blockquote>
<p>In a protocol, all fields (properties and methods) will get the access visibility of the conforming type. For instance, conforming to a protocol with a public type will prompt all of its requirements to be public.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/etcwilde">Evan Wilde</a> pitched <a href="https://forums.swift.org/t/pitch-revisit-the-semantics-of-async-main/51254">a proposal</a> to revisit the semantics of async main.</p>
<blockquote>
<ul>
<li>The main function should run synchronously up to the first suspension point.</li>
<li>The main function should be run on the main actor</li>
<li>MainActor should provide a user-specifiable alternative to the default runloop behaviour.</li>
<li>Make the main task pull the priority from <code class="language-plaintext highlighter-rouge">getCurrentThreadPriority</code> instead of a hard-coded <code class="language-plaintext highlighter-rouge">Default</code> priority.</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/abertelrud">Anders Bertelrud</a> proposed amending to SE-0303: <em>Plugin API to Use <code class="language-plaintext highlighter-rouge">@main</code> for Plugin Entry Point</em>.</p>
<blockquote>
<p>I’d like to propose amending SE-0303 so that SwiftPM plugins use <code class="language-plaintext highlighter-rouge">@main</code> instead of top-level code for entry points. While it’s a little more verbose, this would allow customized entry points for each kind of plugin, and would also make it clearer what the inputs and expected outputs of each plugin are.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/saklad5">Jeremy Saklad</a> pitched <a href="https://forums.swift.org/t/allow-use-of-concrete-associated-type-of-protocols/51277">a proposal</a> that would allow use of concrete associated type of protocols.</p>
<p><a href="https://twitter.com/lorentey">Karoy Lorentey</a> announced Swift Collections <a href="https://forums.swift.org/t/announcement-planning-for-swift-collections-v1-0/51321">version 1.0</a>.</p>
<p><a href="https://forums.swift.org/u/ktoso">Konrad <code class="language-plaintext highlighter-rouge">ktoso</code> Malawski</a> posted Swift Server Workgroup <a href="https://forums.swift.org/t/august-4th-2021/51315">August 4th 2021 meeting notes</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> pitched <a href="https://forums.swift.org/t/pitch-staging-in-sendable-checking/51341">a proposal</a> to implement Staging in <code class="language-plaintext highlighter-rouge">Sendable</code> checking.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a> introduced the <code class="language-plaintext highlighter-rouge">Sendable</code> protocol, which is used to indicate which types have values that can safely be copied across actors or, more generally, into any context where a copy of the value might be used concurrently with the original. Applied uniformly to all Swift code, <code class="language-plaintext highlighter-rouge">Sendable</code> checking eliminates a large class of data races caused by shared mutable state. Swift 5.5 does not perform complete checking for <code class="language-plaintext highlighter-rouge">Sendable</code> because doing so resulted in so many compiler errors and diagnostics that it undermined the usability of the feature.</p>
<p>I think we can stage in <code class="language-plaintext highlighter-rouge">Sendable</code> checking to improve data-race safety over time without. We propose two principles to guide the design of staged <code class="language-plaintext highlighter-rouge">Sendable</code> checking:</p>
<ul>
<li>Incremental adoption of concurrency should introduce incrementally more <code class="language-plaintext highlighter-rouge">Sendable</code> checking.</li>
<li><code class="language-plaintext highlighter-rouge">Sendable</code> problems outside the user’s module should not block progress nor produce an undue annotation burden.</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/millenomi">Aura Lily Vulcano</a> pitched <a href="https://forums.swift.org/t/pitch-the-cstdlib-module/51373">a new module</a> offered by Swift by default.</p>
<blockquote>
<p>The module would re-export the correct module that contains the POSIX or POSIX-like C standard library for the current platform, if any; it would <em>not</em> be imported by default, but would allow “reasonably cross-platform” code to avoid using lengthy <code class="language-plaintext highlighter-rouge">#if canImport(…)</code> chains to gain access to all possible stdlibs, given that they have different names on different OSs.</p>
<p>For example, the module may be named <code class="language-plaintext highlighter-rouge">CStdlib</code>.</p>
</blockquote>
<p>Robert Widmann (aka <a href="https://twitter.com/CodaFi_">@CodaFi_</a>) pitched <a href="https://forums.swift.org/t/pitching-the-start-of-variadic-generics/51467">an idea</a> about the start of variadic generics.</p>
<blockquote>
<p>As part of our efforts to improve the ergonomics of the generics system, as well as providing better support for abstractions that use tuples, I wanted to approach y’all with a sketch for the surface syntax and preliminary semantics. Because this is a large topic area with a lot of impacts on the direction of both the language and later proposals, your feedback is critical at this stage for shaping the direction this feature set is taken in.</p>
<p>I want to thank (in no particular order) Alejandro Alonso, Doug Gregor, and Slava Pestov for shaping my thinking on this subject, and for advancing a lot of the foundations here.</p>
<p>You can find the link to the text of the pitch here <a href="https://gist.github.com/CodaFi/a461aca155b16cd4d05a2635e7d7a361">TypeSequences.md · GitHub</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/aligatr/status/1428285367933972480">async await async await async await async await async await async await async awaiiiiiit 🎵</a></p>
<p><a href="https://twitter.com/gregheo/status/1429121397142351872">[Insert Swift evolution pun here]</a></p>
<p><a href="https://twitter.com/fassko/status/1430576104729939972">When your cat wakes up during the recording of the presentation … 🐈⬛😹🐾</a></p>
Issue #191
https://swiftweeklybrief.com/issue-191
2021-08-12T00:00:00-07:00
2021-08-12T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Have you noticed how the last two weeks have been pretty low-key for the Swift community? I feel this is a lull before the storm of September comes and we all know what that means. Folks are holding their breath, eager to find out news from Apple.</p>
<p>Personally, this time is quite challenging for me as I am getting ready to take the stage at <a href="https://360idev.com/">360iDev conference</a>. Unfortunately, the US hasn’t opened their borders yet, even for fully vaccinated people, so I’m participating online this time. But despite not being able to meet old friends and make new friends in person, I’m truly looking forward to connecting with people and sharing my experience using Swift for rapid development. Let me know if you’re participating in 360iDev and let’s meet up!</p>
<p>For those of you who want to give back to community and support the Swift Weekly Brief, we are open for <a href="https://swiftweeklybrief.com/sponsorship/">sponsors</a>.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-15026">SR-15026</a> [Compiler] Fix-it for deprecated initializers removes the <code class="language-plaintext highlighter-rouge">.init</code> part from <code class="language-plaintext highlighter-rouge">self.init</code></p>
</blockquote>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/collindonnell">Collin Donnell</a> <a href="https://twitter.com/collindonnell/status/1420950032669286402">tweeted</a> that Swift is the only language they could find with over 100 keywords.</p>
<p><a href="https://twitter.com/khawerkhaliq">Khawer Khaliq</a> wrote <a href="https://khawerkhaliq.com/blog/swift-optional-chaining/">a blog post</a> explaining the power of optional chaining in Swift.</p>
<p><a href="https://www.twitter.com/twannl">Antoine van der Lee</a> has <a href="https://www.avanderlee.com/#h-swift-keywords">created a great resource</a> about Swift keywords.</p>
<p><a href="https://aymanmoo.medium.com/">Ayman Fayez</a> wrote <a href="https://aymanmoo.medium.com/copy-on-assignment-vs-copy-on-write-in-swift-c3016b343d06">a post</a> about copy-on-assignment vs. copy-on-write in Swift.</p>
<p>Excellent <a href="https://t.co/ahsYLaO8lZ?amp=1">writeup</a> covering all of Swift’s internal underscored attributes by <a href="https://twitter.com/typesanitizer">Varun Gandhi</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0320-codingkeyrepresentable.md">SSE-0320</a>: <em>Coding of non <code class="language-plaintext highlighter-rouge">String</code> / <code class="language-plaintext highlighter-rouge">Int</code> keyed <code class="language-plaintext highlighter-rouge">Dictionary</code> into a <code class="language-plaintext highlighter-rouge">KeyedContainer</code></em> is <a href="https://forums.swift.org/t/se-0320-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/50903">under review</a>.</p>
<blockquote>
<p>The current conformance of Swift’s <code class="language-plaintext highlighter-rouge">Dictionary</code> to the <code class="language-plaintext highlighter-rouge">Codable</code> protocols has a somewhat-surprising limitation in that dictionaries whose key type is not <code class="language-plaintext highlighter-rouge">String</code> or <code class="language-plaintext highlighter-rouge">Int</code> (values directly representable in <code class="language-plaintext highlighter-rouge">CodingKey</code> types) encode not as <code class="language-plaintext highlighter-rouge">KeyedContainer</code>s but as <code class="language-plaintext highlighter-rouge">UnkeyedContainer</code>s. This behavior has caused much confusion for users and I would like to offer a way to improve the situation.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/pitch-allow-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/44593">[Pitch] Allow coding of non-<code class="language-plaintext highlighter-rouge">String</code>/<code class="language-plaintext highlighter-rouge">Int</code> keyed <code class="language-plaintext highlighter-rouge">Dictionary</code> into a <code class="language-plaintext highlighter-rouge">KeyedContainer</code></a></p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/calstephens98">Cal Stephens</a> pitched <a href="https://forums.swift.org/t/guard-capture-specifier-for-closure-capture-lists/50805">a proposal</a> introducing a <code class="language-plaintext highlighter-rouge">guard</code> capture specifier for closure capture lists.</p>
<blockquote>
<p>In some classes of Swift programming, such as UI programming, closures are a predominant way to perform action handling and send event notifications between multiple objects. When passing closures between parent objects and their children, special care must be taken to avoid retain cycles.</p>
<p><code class="language-plaintext highlighter-rouge">weak</code> captures are often the preferred method to avoid retain cycles. In action handling and event notification closures, there is typically no work to perform if <code class="language-plaintext highlighter-rouge">self</code> (or other captured objects) no longer exist. Because of this, a large number of these closures simply <code class="language-plaintext highlighter-rouge">guard</code> that the weakly captured object still exists, and otherwise do nothing.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/jmjauer">Johannes Auer</a> started [a thread] about <code class="language-plaintext highlighter-rouge">AnyAsyncSequence</code> in Swift.</p>
<p>Swift on the Server Workgroup meeting notes:</p>
<ul>
<li><a href="https://forums.swift.org/t/july-7th-2021/50960">July 7th 2021</a></li>
<li><a href="https://forums.swift.org/t/july-21st-2021/50961">July 21st 2021</a></li>
</ul>
<p><a href="https://forums.swift.org/u/bdriscoll">Benjamin Driscoll</a> pitched <a href="https://forums.swift.org/t/structural-opaque-result-types/50998">an idea</a> to add structural opaque result types.</p>
<blockquote>
<p>An opaque result type may be used as the result type of a function, the type of a variable, or the result type of a subscript. In all cases, the opaque result type must be the entire type. This proposal recommends lifting that restriction and allowing opaque result types in “structural” positions.</p>
<p>We should allow opaque result types in structural positions in the result type of a function, the type of a variable, or the result type of a subscript.</p>
</blockquote>
<p><a href="https://twitter.com/mattt">mattt</a> <a href="https://forums.swift.org/t/package-registry-service-publish-endpoint/51067">pitched a proposal</a> that would add a publish endpoint to the package registry service.</p>
<blockquote>
<p>A package registry is responsible for determining which package releases are made available to a consumer.</p>
<p>Currently, the availability of a package release is determined by an out-of-band process. For example, a registry may consult an index of public Swift packages and make releases available for each tag with a valid version number.</p>
<p>Having a standard endpoint for publishing a new release to a package registry would empower maintainers to distribute their software and promote interoperability across service providers.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/nicholas_maccharoli">Nicholas Maccharoli</a> <a href="https://forums.swift.org/t/if-guard-shorthand-for-optional-unwrapping/51088">proposed</a> a shordhand solution for optional unwrapping.</p>
<p><a href="https://forums.swift.org/u/vihan">Vihan Bhargava</a> wrote an <a href="https://forums.swift.org/t/api-review-sorted-collections/51109">aweseome overview</a> of the new <code class="language-plaintext highlighter-rouge">SortedDictionary</code> and <code class="language-plaintext highlighter-rouge">SortedSet</code> APIs in swift-collections.</p>
<blockquote>
<p>The Swift Collections package currently includes two data structures which maintain its members in a well-defined order: <code class="language-plaintext highlighter-rouge">OrderedSet</code> and <code class="language-plaintext highlighter-rouge">OrderedDictionary</code>. These types are useful in a variety of use-cases, as they enumerate their elements in insertion order. However, there also exist many situations where its desired to maintain elements in an order specified by a predefined comparator. For example, a common pattern in user interfaces is displaying a list with entries sorted in some order, such as in chronological order.</p>
<p>Quick ad hoc implementations of sorted data structures can have many pitfalls. A naive implementation can devolve to quadratic performance. A smarter implementation using binary search is difficult to get correct and has subtle potential pitfalls. For this reason, there is natural place to provide high-performance, production-grade sorted data structures.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/andrew_trick/">Andrew Trick</a> pitched <a href="https://forums.swift.org/t/pitch-implicit-pointer-conversion-for-c-interoperability/51129">an idea</a> to add an implicit pointer conversion for C interoperability.</p>
<blockquote>
<p>C has special rules for pointer aliasing, for example allowing <code class="language-plaintext highlighter-rouge">char *</code> to alias other pointer types, and allowing pointers to signed and unsigned types to alias. The usability of some C APIs relies on the ability to easily cast pointers within the boundaries of those rules. Swift generally disallows typed pointer conversion. See <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0107-unsaferawpointer.md">SE-0107 UnsafeRawPointer API</a>. Teaching the Swift compiler to allow pointer conversion within the rules of C when invoking functions imported from C headers will dramatically improve interoperability with no negative impact on type safety.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/brennanmke">Brennan Stehling</a> <a href="https://forums.swift.org/t/throw-coalescing-operator/51137">proposed to add</a> the throw coalescing operator to the Swift language.</p>
<blockquote>
<p>I’d really like syntax for <code class="language-plaintext highlighter-rouge">do</code>/<code class="language-plaintext highlighter-rouge">try</code>/<code class="language-plaintext highlighter-rouge">catch</code> which is as compact as <code class="language-plaintext highlighter-rouge">nil</code> coalescing in Swift. And so I put together a working implementation which I’d like to refine further. So far I have <code class="language-plaintext highlighter-rouge">!!</code> defined as my operator much like <code class="language-plaintext highlighter-rouge">??</code> for <code class="language-plaintext highlighter-rouge">nil</code> coalescing so it is familiar. The left operand would the work while the right would handle the error.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://twitter.com/omershapira/status/1424592236537339907">Is your child texting about C++?</a></li>
<li><a href="https://twitter.com/jckarter/status/1425110878504984577">maccinated</a></li>
</ul>
Issue #190
https://swiftweeklybrief.com/issue-190
2021-07-29T00:00:00-07:00
2021-07-29T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Thank you <a href="https://twitter.com/appforce1">Jeroen</a> for covering last week’s issue. If you want to contribute or write an issue, head down to our <a href="https://github.com/SwiftWeekly/.github/blob/master/CONTRIBUTING.md">contributions guide</a> or let me know personally.</p>
<p>The slow summer trend is also continuing these past two weeks. Despite that, there are a bunch of accepted proposals and some fresh ideas on the Swift forums.</p>
<p>As always, I appreciate your support. Now let’s get to the news.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://iosacademy.essentialdeveloper.com/p/ios-architect-crash-course-swb2dfd/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_190" target="_blank">Free Training Course for Mid/Senior iOS Devs</a></h4>
<p>From August 2nd to 8th you can join a FREE crash course for iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer!</p>
<p><small><a href="https://iosacademy.essentialdeveloper.com/p/ios-architect-crash-course-swb2dfd/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_190" target="_blank">iosacademy.essentialdeveloper.com/p/ios-architect-crash-course-swb2dfd/</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14941">SR-14941</a> Introduce compiler warning for leading-zero octal notation</li>
<li><a href="https://bugs.swift.org/browse/SR-14943">SR-14943</a> [Compiler] Fix-it for changing unsafeBitcast to unsafeDowncast should be more narrow or removed</li>
<li><a href="https://bugs.swift.org/browse/SR-14971">SR-14971</a> [Compiler] Spurious error after wrapped ‘var’ declaration without type annotation.</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p>Great <a href="https://holyswift.app/using-tuples-to-complex-sorting-operations-in-swift">article</a> about using tuples in complex sorting operations in Swift.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0319-never-identifiable.md">SE-0319</a> <em>Never as Identifiable</em> was <a href="https://forums.swift.org/t/accepted-se-0319-never-as-identifiable/50473">accepted</a>.</p>
<blockquote>
<p>Feedback from the review was positive, and mostly focused on further exploration of making <code class="language-plaintext highlighter-rouge">Never</code> a true bottom type, or similar alternatives to expanding the list of protocols <code class="language-plaintext highlighter-rouge">Never</code> conforms to in a systemic manner. The core team acknowledges this is an interesting design space and encourages follow up proposals exploring it.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0317-async-let.md">SE-0317</a> <em>Async Let</em> was <a href="https://forums.swift.org/t/accepted-se-0317-async-let/50695">accepted</a>.</p>
<blockquote>
<p>A significant area of feedback during the review was that of the creation of implicit suspension points when an <code class="language-plaintext highlighter-rouge">async let</code> variable is not awaited on a path that exits a scope that is not itself an awaited function. This creates an exception to the rule that suspension points are always marked with an <code class="language-plaintext highlighter-rouge">await</code>.</p>
<p>After thorough discussion of the alternatives to implicit suspension points, the core team feels that language-level solutions add more complexity than is warranted to eliminate implicit suspension points.</p>
<p>The core team acknowledges that this exception may have more impact in practice than can be reasoned about without real-world use. There is an opportunity to react to real-world feedback in Swift 6 by tightening up the model around implicit awaits if it turns out that they are harmful in practice (although it is not currently the intention to do so).</p>
<p>The proposal authors have added descriptions of other solutions and their downsides to the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0317-async-let.md#requiring-an-awaiton-any-execution-path-that-waits-for-an-async-let">alternatives considered</a> section of the proposal. This section also has additions covering other alternatives discussed during the review, such as the use of property wrappers for a partial library-level solution.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0315-placeholder-types.md">SE-0315</a> <em>Type placeholders</em> was <a href="https://forums.swift.org/t/accepted-se-0315-placeholder-types/50671">accepted</a>.</p>
<blockquote>
<p>Support for the added functionality was unanimous; there was some discussion about whether the proposal might be better titled “type placeholders” or “inferred types”, but that would not affect the behavior of the feature within the language. Thanks to everyone who participated in the review!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0314-async-stream.md">SE-0314</a> <em><code class="language-plaintext highlighter-rouge">AsyncStream</code> and <code class="language-plaintext highlighter-rouge">AsyncThrowingStream</code></em> <a href="https://forums.swift.org/t/se-0314-second-review-asyncstream-and-asyncthrowingstream/49803">second review</a> was <a href="https://forums.swift.org/t/accepted-se-0314-asyncstream-and-asyncthrowingstream/50699">accepted</a>.</p>
<blockquote>
<p>The proposal is <strong>accepted</strong>. After much discussion, Core Team has decided to retain the <code class="language-plaintext highlighter-rouge">AsyncStream</code> and <code class="language-plaintext highlighter-rouge">AsyncThrowingStream</code> names as proposed.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0318-package-creation.md">SE-0318</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0318-package-creation/50474">returned for revision</a>.</p>
<blockquote>
<p>The feedback from the review highlighted further refinement that can be done to the ergonomics of the proposed solution including the templating system. For example, the proposal can make it clearer why a new command is desired compared to enhancing the existing package init command, and explore a templating system that supports for multi-template-single-repo and programatic interfaces.</p>
<p>The proposal authors are encouraged to consider these alternative design ideas, and pitch a modified version of the proposal to the community.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/gutley">Gutley</a> pitched <a href="https://forums.swift.org/t/catching-unwanted-uses-of-on-optionset/50566">an idea</a> to implement a solution to catch unwanted uses of <code class="language-plaintext highlighter-rouge">~=</code> on OptionSet.</p>
<p><a href="https://forums.swift.org/u/jmjauer/summary">Johannes Auer</a> pitched a <a href="https://forums.swift.org/t/pre-pitch-asyncvalue/50590">proposal</a> to add <code class="language-plaintext highlighter-rouge">AsyncValue</code>.</p>
<blockquote>
<p>While migrating a project to the new async features of Swift I constantly needed a mechanism for a synchronization point based of the availability of some value. As far as I can tell, currently there is nothing in the stdlib to cover this.</p>
<p>Basically, this is something like an ‘AsyncSequence’ with only 1 value.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/m-housh">Michael Housh</a> shared <a href="https://forums.swift.org/t/exploring-the-swift-web-framework/50652">a story</a> about exploring Swift web frameworks.</p>
<p><a href="https://forums.swift.org/u/1oo7">Jonathan G.</a> pitched <a href="https://forums.swift.org/t/sub-syntax-for-string-literals/50678">an idea</a> to add sub-syntax for string literals.</p>
<blockquote>
<p>The idea is a new feature for multi-line string literals that allows the user to specify what format the nested content should conform to. Swift would provide a String.Syntax enumeration that would allow the programmer to choose amongst a wide range of existing formats to designate the string content as conforming to.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/bitjammer">Ashley Garland</a> started <a href="https://forums.swift.org/t/command-line-ux-enhancements-for-swift/50670">a thread</a> about improving Swift’s user experience from the command line across all platforms.</p>
<blockquote>
<p>I’d like to make the command line interface more appropriate for direct, interactive use by humans, while keeping automation use cases available. I propose to rework the CL tools in the following ways:</p>
<ul>
<li>Give users direction in accomplishing their Swift tasks at the command line, providing choices for high level tasks and > * clarification about what to do next where possible.</li>
<li>Progressively disclose flags and options, keeping text focused on the current task.</li>
<li>Make the command line aware of context so it can infer the right action for impactful cases.</li>
<li>Continue to provide explicit invocations for all of the tasks we perform today.</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/uliwitness">Not a Kitteh</a> pitched <a href="https://forums.swift.org/t/pre-pitch-testable-visibility-specifier-instead-of-internal-for-testable/50718">an idea</a> to add a <code class="language-plaintext highlighter-rouge">testable</code> visibility specifier instead of <code class="language-plaintext highlighter-rouge">internal</code> for <code class="language-plaintext highlighter-rouge">@testable</code>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">@testable</code> is a very useful feature, however I’ve recently had several bugs caused by accidentally accessing <code class="language-plaintext highlighter-rouge">internal</code> symbols, or rather, by forgetting to declare symbols in a framework <code class="language-plaintext highlighter-rouge">public</code>.</p>
<p>So, I’m wondering if it was a mistake to make <code class="language-plaintext highlighter-rouge">@testable</code> allow access to all symbols with <code class="language-plaintext highlighter-rouge">internal</code> visibility, and whether it should be changed to just provide access to symbols that are explicitly marked with a special <code class="language-plaintext highlighter-rouge">testable</code> visibility.</p>
<p>For all other intents and purposes, <code class="language-plaintext highlighter-rouge">testable</code> would be identical to <code class="language-plaintext highlighter-rouge">internal</code>. The only difference would be that <code class="language-plaintext highlighter-rouge">@testable import</code> only makes <code class="language-plaintext highlighter-rouge">testable</code> symbols accessible, all symbols marked as <code class="language-plaintext highlighter-rouge">internal</code> stay in-accessible.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://twitter.com/zats/status/1419343807229960199">Carbonara.framework</a></li>
<li><a href="https://twitter.com/jckarter/status/1418996455616835585">Dissociated types</a></li>
<li><a href="https://twitter.com/DeepSchneider/status/1417195426877431811">Reverse-pascal-reverse-snake case</a></li>
</ul>
Issue #189
https://swiftweeklybrief.com/issue-189
2021-07-15T00:00:00-07:00
2021-07-15T00:00:00-07:00
Jeroen Leenarts
https://twitter.com/appforce1
https://github.com/appforce1.png?size=100
appforce1
<p>Kristaps has asked me to take over the writing for this week. It seems that Swift proposals and pitches have slowed down a little bit for now. Is this due to summer in the northern hemisphere or people having fun with the current beta releases by Apple? Who knows. I do know everything happens in cycles and my guess is that things will pick up again. Enjoy this week’s links and information.</p>
<p>Swift Weekly is looking for sponsors. If your company or someone you know would like to sponsor this community-driven project, <a href="https://swiftweeklybrief.com/sponsorship/">reach out</a>! Thank you!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14883">SR-14824</a> [Compiler] Consider <code class="language-plaintext highlighter-rouge">must</code> in diagnostic error message for empty <code class="language-plaintext highlighter-rouge">switch</code> cases</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/rockbruno_">Bruno Rocha</a> wrote an in depth article on <a href="https://swiftrocks.com/how-actors-work-internally-in-swift/">How Actors Work Internally in Swift</a>.</p>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> did a nice experiment with Visual Studio Code as a (server-side) Swift IDE. <a href="https://twitter.com/0xTim/status/1412775961343442954">He reports on his experience in a Swift Forum topic.</a></p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md">SE-0292</a> <em>Package Registry Service</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0292-package-registry-service/49849">accepted</a>.</p>
<p>The <a href="https://forums.swift.org/t/se-0292-3rd-review-package-registry-service/">3rd review</a> of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md">SE-0292</a> has concluded. The review has been generally quiet with feedback focused on making the OpenAPI spec more robust to explicitly highlight the support for redirecting proxies which have been one of the focus points of the <a href="https://forums.swift.org/t/se-0292-2nd-review-package-registry-service/">2nd review</a>. As such, the proposal has been accepted with a few minor revisions.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0319-never-identifiable.md">SE-0319</a>: <em>Never as Identifiable</em> <a href="https://github.com/apple/swift-evolution/pull/1399">amendment</a> <a href="https://forums.swift.org/t/se-0319-never-as-identifiable/50246">was under review and is accepted</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0314-async-stream.md">SE-0314</a>: <em>AsyncStream and AsyncThrowingStream</em> is <a href="https://forums.swift.org/t/se-0314-second-review-asyncstream-and-asyncthrowingstream/49803">under review</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0319-never-identifiable.md">SE-0304</a>: <em>Structured Concurrency</em> is <a href="https://forums.swift.org/t/se-0304-4th-review-structured-concurrency/50281">under a fourth review</a>.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/tomerd">Tomer Doron</a> shared the Swift Server Work Group <a href="https://forums.swift.org/t/june-23rd-2021/50273">June 23rd, 2021</a> meeting notes.</p>
<p><a href="https://twitter.com/drexin">Dario Rexin</a> has <a href="https://forums.swift.org/t/development-open-for-swift-5-4-3-for-linux-and-windows/50302">announced</a> that development for Swift 5.4.3 for Linux and Windows is now open.</p>
<blockquote>
<p>Merge window open: Jul 8 2021 (now)
Merge window close: Jul 28 2021
Planned release: End of July or early August 2021</p>
</blockquote>
<p><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> pitched <a href="https://forums.swift.org/t/add-value-property-to-result/50253">a proposal</a> on value properties on Results.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0310-effectful-readonly-properties.md">SE-0310</a> added throwing properties, and so <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md">SE-0304</a>
has a throwing value instead of <code class="language-plaintext highlighter-rouge">get()</code>. This adds a matching equivalent to <code class="language-plaintext highlighter-rouge">Result</code> which makes things more consistent.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://twitter.com/jesse_squires/status/1411519690023739397">Dancing Queen</a>.</li>
<li><a href="https://twitter.com/jckarter/status/1411717750553120772">Crass vs. class</a>.</li>
</ul>
Issue #188
https://swiftweeklybrief.com/issue-188
2021-07-01T00:00:00-07:00
2021-07-01T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>It seems that WWDC21 has settled down, and people are starting to enjoy the summer. But Swift’s core team hasn’t stopped working, and there are quite a few proposals in review as well as accepted.</p>
<p>This issue of Swift Weekly brings some sad news because the Swift Unwrapped podcast has ended. I want to personally say thanks to <a href="https://twitter.com/jesse_squires">Jesse Squires</a> and <a href="https://twitter.com/simjp">JP Simard</a> for running Swift Unwrapped for so long - 4.5 years and 92 episodes. It was a wild ride, and I learned a ton. Thank you!</p>
<p>Swift Weekly is looking for sponsors. If your company or someone you know would like to sponsor this community-driven project, <a href="https://swiftweeklybrief.com/sponsorship/">reach out</a>! Thank you!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14824">SR-14824</a> [Compiler] Improve diagnostic for multi-statement closures instead of saying “too complex closure return type”</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>After 4.5 years, 92 episodes, and 830k downloads, Swift Unwrapped is wrapping up. In the last episode <a href="https://swiftunwrapped.github.io/episodes/xyd_XEwO/">92: Deinit</a> <a href="https://twitter.com/jesse_squires">Jesse Squires</a> and <a href="https://twitter.com/simjp">JP Simard</a> talk about the history of the show and more.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tiborbodecs">Tibor Bödecs</a> wrote <a href="https://theswiftdev.com/swift-actors-tutorial-a-beginners-guide-to-thread-safe-concurrency/">a great tutorial</a> about Swift actors.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md">SE-0311</a> <em>Task-local values</em> was <a href="https://forums.swift.org/t/accepted-se-0311-task-local-values/50120">accepted</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0311-3rd-review-task-local-values/49122">third review</a> of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md">SE-0311: Task-local values</a> concluded a few weeks ago. The review focused on a narrow question: whether to extend the proposal to allow task-local values to be established from synchronous functions. Feedback on this point was quite positive. SE-0311 is therefore <strong>accepted</strong> without further amendment.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a> <a href="https://github.com/apple/swift-evolution/pull/1392">Amendment</a> <em>Allow overloads that differ only in async</em> was <a href="https://forums.swift.org/t/accepted-amendment-to-se-0296-allow-overloads-that-differ-only-in-async/50117">accepted</a>.</p>
<blockquote>
<p>It was generally accepted that overloading on <code class="language-plaintext highlighter-rouge">async</code> would be beneficial. Most of the discussion centred not on <code class="language-plaintext highlighter-rouge">async</code>, but on <code class="language-plaintext highlighter-rouge">throws</code>. Accepting this amendment makes <code class="language-plaintext highlighter-rouge">async</code> more different from <code class="language-plaintext highlighter-rouge">throws</code>, and there was some sentiment that this amendment should only be accepted if we also allow overloading on <code class="language-plaintext highlighter-rouge">throws</code> accordingly. The Core Team disagreed with this approach for two specific reasons:</p>
<ul>
<li>First, <code class="language-plaintext highlighter-rouge">throws</code> is not necessarily as amenable to overloading as <code class="language-plaintext highlighter-rouge">async</code>, due to the presence of control flow that handles thrown errors without requiring the enclosing context to be <code class="language-plaintext highlighter-rouge">throws</code> (<code class="language-plaintext highlighter-rouge">try?</code>, <code class="language-plaintext highlighter-rouge">try!</code>, and <code class="language-plaintext highlighter-rouge">do</code>..<code class="language-plaintext highlighter-rouge">catch</code> constructs have no analogy in <code class="language-plaintext highlighter-rouge">async</code>). It is not a given that <code class="language-plaintext highlighter-rouge">throws</code> and <code class="language-plaintext highlighter-rouge">async</code> must be consistent with respect to their overloading behaviour.</li>
<li>Second, overloading on <code class="language-plaintext highlighter-rouge">async</code> is timely in a way that <code class="language-plaintext highlighter-rouge">throws</code> is not. There are no <code class="language-plaintext highlighter-rouge">async</code> APIs now, but the Swift community will be adding them as soon as Swift 5.5 becomes available. Without overloading on <code class="language-plaintext highlighter-rouge">async</code>, the Swift ecosystem will end up with a nontrivial number of APIs with non-ideal names (e.g., an <code class="language-plaintext highlighter-rouge">Async</code> suffix) that won’t be able to be fixed later. <code class="language-plaintext highlighter-rouge">throws</code> is different, because the overloading rule has been in place since Swift 2.0. Delaying the ability to overload on <code class="language-plaintext highlighter-rouge">async</code> has long-term costs that the Core Team feels are not justified by the potential for inconsistency.</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0316</a> <em>Global Actors</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0316-global-actors/50116">accepted</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0316-second-review-global-actors/49804">second review 4</a> for <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0316-global-actors.md">SE-0316: Global Actors 7</a> ran until June 28th, 2021. The core team has decided to <strong>accept the proposal with modifications</strong>. A few important points were raised during the review and core team discussion, and the proposal will be accepted to address these points:</p>
<ul>
<li>
<p><a href="https://forums.swift.org/u/bigsur">@BigSur</a> asked <a href="https://forums.swift.org/t/se-0316-second-review-global-actors/49804/9">whether classes annotated with <code class="language-plaintext highlighter-rouge">@globalActor</code> impart global-actor-ness on their subclasses</a>, and <a href="https://forums.swift.org/u/filip-sakel">@filip-sakel</a> <a href="https://forums.swift.org/t/se-0316-second-review-global-actors/49804/5">raised questions about the ramifications of global actor subclassing on the type system 4</a>. The uses for subclassing a global actor seem limited, so for simplicity’s sake, <strong>non-final classes should not be allowed to be annotated as <code class="language-plaintext highlighter-rouge">@globalActor</code></strong>. This restriction could be lifted by a future proposal.</p>
</li>
<li>
<p>As reviewed, the proposal allowed for generic arguments that conform to <code class="language-plaintext highlighter-rouge">GlobalActor</code> to be used as global actor attributes, as in <code class="language-plaintext highlighter-rouge">@T func foo<T: GlobalActor>(...)</code>. <a href="https://forums.swift.org/u/zhu_shengqi">@Zhu_Shengqi</a> noted that <a href="https://forums.swift.org/t/se-0316-second-review-global-actors/49804/4">this could create readability problems 2</a>, since it isn’t clear what <code class="language-plaintext highlighter-rouge">T</code> is referring to until you read further into the declaration. Supporting this also imposes technical challenges on the implementation of user-defined attributes, and opens potential new design questions. For instance, if we later add another protocol for another kind of user-defined attribute, and a generic argument is constrained by two such protocols, then which kind of attribute is <code class="language-plaintext highlighter-rouge">@T</code>? Is there a way to control it? Furthermore, if we did support <code class="language-plaintext highlighter-rouge">@globalActor</code> on subclassable classes, there would also be interesting interactions possible where a class may inherit a <code class="language-plaintext highlighter-rouge">GlobalActor</code> protocol conformance, but not be marked <code class="language-plaintext highlighter-rouge">@globalActor</code> itself, but nonetheless be used indirectly as a global actor constraint by being bound to a generic type argument.</p>
</li>
</ul>
<p>For these reasons, <strong>the ability to use a generic parameter as a global actor constraint should be removed from this proposal</strong>. A future proposal could add this ability, but it will need to consider the design questions raised above.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a>: <em>Allow overloads that differ only in async</em> <a href="https://github.com/apple/swift-evolution/pull/1392">amendment</a> is <a href="https://forums.swift.org/t/amendment-se-0296-allow-overloads-that-differ-only-in-async/49808">under review</a>.</p>
<blockquote>
<p>Based on the <a href="https://forums.swift.org/t/concurrency-asynchronous-functions/41619">discussion of the first pitch</a>, this ability was <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md#revision-history">removed from the proposal</a>. However, experience <a href="https://forums.swift.org/t/async-feedback-overloads-that-differ-only-in-async/49573">augmenting existing Swift libraries with async/await functionality</a> has demonstrated that this overloading might be useful, so we would like to reconsider the limitation.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0315-placeholder-types.md">SE-0315</a>: <em>Placeholder types</em> is <a href="https://forums.swift.org/t/se-0315-placeholder-types/49801">under review</a>.</p>
<blockquote>
<p>Swift’s type inference system is quite powerful, but there are many situations where it is impossible (or simply infeasible) for the compiler to work out the type of an expression, or where the user needs to override the default types worked out by the compiler. Directly referencing the heavily-overloaded <code class="language-plaintext highlighter-rouge">Double.init</code> initializer, as seen above, is one such situation where the compiler does not have the necessary context to determine the type of the expression without additional context.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0316-global-actors.md">SE-0316</a>: <em>Placeholder types</em> is <a href="https://forums.swift.org/t/se-0316-second-review-global-actors/49804">under the second review</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0316-global-actors/48905">previous review</a> ended on June 7th. Relative to the previous review, the following changes have been made:</p>
<ul>
<li>Added the <code class="language-plaintext highlighter-rouge">GlobalActor</code> protocol, to which all global actors implictly conform.</li>
<li>Remove the requirement that all global and static variables be annotated with a global actor.</li>
<li>Added a grammar for closure attributes.</li>
<li>Clarified the interaction between the main actor and the main thread. Make the main actor a little less “special” in the initial presentation.</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0314-async-stream.md">SE-0314</a>: <em>AsyncStream and AsyncThrowingStream</em> is <a href="https://forums.swift.org/t/se-0314-second-review-asyncstream-and-asyncthrowingstream/49803">under the second review</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0314-asyncstream-and-asyncthrowingstream/48198/33">first review 7</a> received a lot of very useful feedback. In response, the authors have made several changes to the proposal for the second review, summarized here:</p>
<ul>
<li>added <code class="language-plaintext highlighter-rouge">YieldResult</code> to express the action of yielding’s impact, either something is enqueued, dropped or the continuation is already terminated</li>
<li>added <code class="language-plaintext highlighter-rouge">init(unfolding: @escaping () async -> Element?)</code> to offer an initializer for unfolding to handle back-pressure based APIs.</li>
<li>made <code class="language-plaintext highlighter-rouge">AsyncThrowingStream</code> generic on Failure but the initializers only afford for creation <code class="language-plaintext highlighter-rouge">where Failure == Error</code></li>
<li>removed the example of <code class="language-plaintext highlighter-rouge">DispatchSource</code> signals since the other <code class="language-plaintext highlighter-rouge">DispatchSource</code> types might be actively harmful to use in <em>any</em> async context</li>
<li>initialization now takes a buffering policy to both restrict the buffer size as well as configure how elements are dropped</li>
</ul>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> started <a href="https://forums.swift.org/t/running-an-async-task-with-a-timeout/49733">a discussion</a> about running an <code class="language-plaintext highlighter-rouge">async</code> task with a timeout.</p>
<blockquote>
<p>I wrote a function <code class="language-plaintext highlighter-rouge">async(timeoutAfter:work:)</code>. Its goal is to run an async task with a timeout. If the timeout expires and the work hasn’t completed, it should cancel the task and throw a <code class="language-plaintext highlighter-rouge">TimedOutError</code>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/iillx">Isabel Lima</a> pitched <a href="https://forums.swift.org/t/add-shared-storage-to-property-wrappers/49898">a proposal</a> that would add shared storage to property wrappers.</p>
<blockquote>
<p>Property Wrappers are responsible for wrapping common getting and setting boilerplate and also for storing any auxiliary helper properties. Often, these helpers are constant across different instances of the wrapper, not changing after initialization. Thus, having to store these properties in each individual wrapper instance should be avoided. In the following <code class="language-plaintext highlighter-rouge">Clamped</code> example, every wrapped instance will store its own <code class="language-plaintext highlighter-rouge">range</code> — even though there isn’t a way for this range to change across different <code class="language-plaintext highlighter-rouge">Hud</code> initializations.</p>
</blockquote>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> briefed about Swift on the Server Workgroup <a href="https://forums.swift.org/t/may-26th-2021/49863">May 26th 2021 meeting</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> informed us about the <a href="https://github.com/apple/swift-evolution/pull/1397">amendment</a> to <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0313-actor-isolation-control.md">SE-0313</a>.</p>
<blockquote>
<p>.. requires any <code class="language-plaintext highlighter-rouge">nonisolated</code> declaration to only involve <code class="language-plaintext highlighter-rouge">Sendable</code> types. This eliminates the potential for data races due to non-<code class="language-plaintext highlighter-rouge">Sendable</code> values being accessible from any actor.</p>
</blockquote>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a> pitched <a href="https://forums.swift.org/t/pre-pitch-import-access-control-a-modest-proposal/50087">an idea</a> to improve the import access control.</p>
<blockquote>
<p>Over the last few years, the <code class="language-plaintext highlighter-rouge">import</code> statement has been collecting unofficial, unsupported features to help manage the dependencies between libraries. We (<a href="https://forums.swift.org/u/xymus">@xymus</a> and <a href="https://forums.swift.org/u/beccadax">@beccadax</a>) are thinking about how to stabilize some of these into officially-supported language features.</p>
<p>Chief among them is the <code class="language-plaintext highlighter-rouge">@_implementationOnly</code> attribute. An <code class="language-plaintext highlighter-rouge">@_implementationOnly import</code> is completely hidden from clients who import your module. This allows clients to import your module even if they do not have access to that module, so it’s great for hiding libraries that you use only as an implementation detail. To make this work, though, the compiler stops you from using a declaration imported via an <code class="language-plaintext highlighter-rouge">@_implementationOnly import</code> in a <code class="language-plaintext highlighter-rouge">public</code>, <code class="language-plaintext highlighter-rouge">open</code>, or <code class="language-plaintext highlighter-rouge">@usableFromInline</code> declaration (including the function body if it’s <code class="language-plaintext highlighter-rouge">@inlinable</code>) if that use would be visible to your clients.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/kylemacomber">Kyle Macomber</a> pitched <a href="https://forums.swift.org/t/pitch-conform-never-to-identifiable/50110">a proposal</a> that allows <code class="language-plaintext highlighter-rouge">Never</code> conform to <code class="language-plaintext highlighter-rouge">Identifiable</code> to make it usable as a “bottom type” for generic constraints that require <code class="language-plaintext highlighter-rouge">Identifiable</code>.</p>
<blockquote>
<p>With the acceptance of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0215-conform-never-to-hashable-and-equatable.md">SE-0215</a>, <code class="language-plaintext highlighter-rouge">Never</code> was deemed as being a “blessed bottom type”, but that it wouldn’t implicitly conform to all protocols—instead explicit conformance should be added where valuable.</p>
<p>The conformance of <code class="language-plaintext highlighter-rouge">Never</code> to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> in SE-0215 was motivated by examples like using <code class="language-plaintext highlighter-rouge">Never</code> as a generic constraint in types like <code class="language-plaintext highlighter-rouge">Result</code> and in enumerations. These same use cases motivate the conformance of <code class="language-plaintext highlighter-rouge">Never</code> to <code class="language-plaintext highlighter-rouge">Identifiable</code>, which is pervasive in commonly used frameworks like SwiftUI.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://twitter.com/harshil/status/1405376218665406466">When it hits you that async/await requires iOS 15</a>.</li>
<li><a href="https://twitter.com/jckarter/status/1405988641726365697">[Pitch] Allow async functions to specify hold music while being awaited</a></li>
<li><a href="https://twitter.com/jckarter/status/1407095099046039554">Dracula</a></li>
</ul>
Issue #187
https://swiftweeklybrief.com/issue-187
2021-06-17T00:00:00-07:00
2021-06-17T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p><a href="https://developer.apple.com/wwdc21/">WWDC21</a> is over and it was a crazy week - full of new stuff, great sessions and things to learn during the summer. What were your favorite sessions?</p>
<p>If you have thoughts on how to make next year’s WWDC even better, you can <a href="https://developer.apple.com/news/?id=lb12ga2i">express them here</a>.</p>
<p>I loved all the sessions about Swift concurrency and the new SwiftUI stuff, but I haven’t watched them all. Don’t worry if you haven’t seen everything. We’ll have time to consume and learn all this new stuff. Take it easy and enjoy!</p>
<p>We are looking for sponsors for Swift Weekly. You can find all the information about sponsorship <a href="https://swiftweeklybrief.com/sponsorship/">here</a>.</p>
<p>We have a jam-packed issue this time, so let’s get to it!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-14720">SR-14720</a> [Compiler] Mismatched <code class="language-plaintext highlighter-rouge">@escaping</code> for closure parameter produces inaccurate diagnostic</p>
</blockquote>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.swiftbysundell.com/podcast/99/">episode 99</a> of the Swift by Sundell podcast, <a href="https://twitter.com/dgregor79">Doug Gregor</a> joins <a href="https://twitter.com/johnsundell">John Sundell</a> to discuss Swift 5.5’s new concurrency features in great detail. How do features like async/await and actors work under the hood, and how were those concepts adapted in order to feel right at home within Swift’s existing ecosystem? That, and much more, on this WWDC21 special episode of the show.
Worth to read this <a href="https://twitter.com/dgregor79/status/1403428438980005888">Twitter thread</a> about this same topic.</p>
<h3 id="news-and-community">News and community</h3>
<h4 id="concurrency">Concurrency</h4>
<p><a href="Concurrency">https://docs.swift.org/swift-book/LanguageGuide/Concurrency.html</a> guide.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> wrote a post about Concurrency in Swift 5 and 6.</p>
<p><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> is <a href="https://forums.swift.org/t/swift-concurrency-feedback-wanted/49336">asking feedback</a> about Swift concurrency.</p>
<p>A great Twitter <a href="https://twitter.com/peterfriese/status/1405223758479101954">thread</a> by Peter Friese about Swift concurrency in condense way.</p>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> wrote <a href="https://swift.org/blog/package-collections/">a blog post</a> introducing Swift package collections.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/37917">a pull request</a> that introduces the <code class="language-plaintext highlighter-rouge">GlobalActor</code> protocol to describe global actors.</p>
<p><a href="https://github.com/etcwilde">Evan Wilde</a> merged <a href="https://github.com/apple/swift/pull/37880">a pull request</a> that fixes actor <code class="language-plaintext highlighter-rouge">init</code> diagnostic.</p>
<p><a href="https://github.com/shahmishal">Mishal Shah</a> merged <a href="https://github.com/apple/swift/pull/37824">a pull request</a> that adds support to Xcode 13 beta.</p>
<p><a href="https://github.com/al45tair">Alastair Houghton</a> merged <a href="https://github.com/apple/swift/pull/37787">a pull request</a> that fixes demangling of optionals containing function types.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0318-package-creation.md">SE-0318</a>: <em>Package Creation</em> is <a href="https://forums.swift.org/t/se-0318-package-creation/49659">under review</a>.</p>
<blockquote>
<p>In order to clearly separate the roles of transforming an existing directory of source files into a Swift package, from creating a new package from scratch we propose adding a new command <code class="language-plaintext highlighter-rouge">swift package create</code>. <code class="language-plaintext highlighter-rouge">swift package init</code> will continue to exist as is, but will be updated to focus on the former, while the new <code class="language-plaintext highlighter-rouge">swift package create</code> will focus on the latter.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> <a href="https://forums.swift.org/t/amendment-se-0291-package-collections/49341">updated</a> us about SE-0291: Package Collections status.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md#requirements-on-signing-certificate">SE-0291 signing section</a> currently says Apple Distribution certificates from <a href="http://developer.apple.com/">developer.apple.com</a> satisfy all of the signing certificate requirements stated in the proposal. There are details about these certificates that need to be worked out further, so in the meantime we are <a href="https://github.com/apple/swift-evolution/pull/1383">removing this statement from the proposal</a>.</p>
<p>The technical requirements for signing certificates, and the mechanism to sign package collections remain unchanged.</p>
</blockquote>
<p><a href="https://twitter.com/tim_vermeulen">Tim Vermeulen</a> <a href="https://forums.swift.org/t/pitch-2-add-indexed-and-collection-conformances-for-enumerated-and-zip/49604">updated</a> us about the second pitch of the <a href="https://github.com/timvermeulen/swift-evolution/blob/indexed-enumerated-zip-v2/proposals/0312-indexed-and-enumerated-zip-collections.md"><code class="language-plaintext highlighter-rouge">indexed()</code></a> proposal.</p>
<blockquote>
<ul>
<li>The return type of the <code class="language-plaintext highlighter-rouge">indexed()</code> method has been renamed from <code class="language-plaintext highlighter-rouge">Indexed</code> to <code class="language-plaintext highlighter-rouge">IndexedCollection</code>.</li>
<li>The conditional <code class="language-plaintext highlighter-rouge">RandomAccessCollection</code> conformance of <code class="language-plaintext highlighter-rouge">Zip2Sequence</code> has been removed in favor of a new <code class="language-plaintext highlighter-rouge">zip(_:_:)</code> overload for random-access collections that returns a new <code class="language-plaintext highlighter-rouge">Zip2RandomAccessCollection</code> type, due to implementation difficulties. This has been elaborated on in the <a href="https://github.com/timvermeulen/swift-evolution/blob/indexed-enumerated-zip-v2/proposals/0312-indexed-and-enumerated-zip-collections.md#add-conditional-conformance-to-randomaccesscollection-for-zip2sequence-rather-than-overloading-zip">Alternatives considered</a>.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/alexito4">Alejandro Martinez</a> <a href="https://forums.swift.org/t/will-swift-concurrency-deploy-back-to-older-oss/49370">asked</a> a if Swift Concurrency is going to be compatible with older OS versions. <a href="https://twitter.com/tkremenek">Ted Kremenek</a> replied:</p>
<blockquote>
<p>Concurrency requires runtime support that does not backward deploy. The release notes imply that this is an “issue” that just needs to be fixed. It’s not. It’s a feature that would need to be implemented. At this time, folks should assume that concurrency does not backward deploy. That said, everyone is aware of the value of it doing so, and is something that is being explored/considered.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/bastianinuk">Bastian Inuk Christensen</a> pitched <a href="https://forums.swift.org/t/expressible-by-function-literal/49298">an idea</a> to conform the <code class="language-plaintext highlighter-rouge">ResultBuilder</code> to <code class="language-plaintext highlighter-rouge">ExpressibleByFunctionLiteral</code>.</p>
<p><a href="https://github.com/johnno1962">John Holdsworth</a> pitched <a href="https://forums.swift.org/t/automatic-mutable-pointer-conversion/49304">an idea</a> that adds automatic conversion from mutable unsafe pointers to their immutable counterparts.</p>
<blockquote>
<p>In C, you may pass mutable pointers (specifically, <code class="language-plaintext highlighter-rouge">void *</code>, <code class="language-plaintext highlighter-rouge">Type *</code>) to calls expecting immutable pointers (<code class="language-plaintext highlighter-rouge">const void *</code>, <code class="language-plaintext highlighter-rouge">const Type *</code>). This access is safe and conventional as immutable access to a pointer’s memory can be safely assumed when you have mutable access. The same reasoning holds true for Swift but no such implicit cast to immutable counterparts exists. Instead, you must explicitly cast mutable unsafe pointer types (<code class="language-plaintext highlighter-rouge">UnsafeMutableRawPointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer<Type></code>) to immutable versions (<code class="language-plaintext highlighter-rouge">UnsafeRawPointer</code> and <code class="language-plaintext highlighter-rouge">UnsafePointer<Type></code>). This adds unneeded friction when passing mutable pointers to C functions or comparing pointers of differing mutability.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/eventomer">Tomer Even</a> pitched <a href="https://forums.swift.org/t/special-syntax-for-blocks-who-capture-all-variables-as-weak/49290">an idea</a> for special syntax for blocks that capture all variables as weak.</p>
<blockquote>
<p>Many of the UI related use of blocks requires the developer to add lots of boilerplate code to allow weak capturing of self and other variables used in the scope of the block when updating the UI to avoid retain cycles. It also doesn’t make sense to strongly capture the UI only for updating it if its already dismissed.</p>
<p>By introducing the new syntax to weakly capture all variables in the scope we can also avoid bugs caused by the default behaviour of implicitly strong capturing all variables in the block scope.</p>
<p>This moves the focus away from deciding if strongly capturing a variable in this block will cause a retain cycle or not to letting the developer focus on whether this block must execute or is the block optional and should only be executed if all of its non optional capture list still exists.</p>
</blockquote>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> <a href="https://forums.swift.org/t/atomic-blonde-is-back/49288">let us know</a> that the <a href="https://atom.io/packages/atomic-blonde">Atomic Blonde</a> syntax highlighter is back.</p>
<blockquote>
<p>The <a href="https://atom.io/packages/atomic-blonde"><code class="language-plaintext highlighter-rouge">atomic-blonde</code></a> syntax highlighter for the Atom text has been out-of-commission for the last few months due to source-breaking changes in the V8 javascript engine, but I’ve just <a href="https://github.com/kelvin13/atomic-blonde/releases">updated</a> it to work with the latest version of <code class="language-plaintext highlighter-rouge">node-gyp</code> and <code class="language-plaintext highlighter-rouge">V8</code>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/jacobcaraballo">Jacob Caraballo</a> pitched <a href="https://forums.swift.org/t/pitch-try-catch-expose-error-for-try-expressions-by-allowing-catch-after-the-function/49445">a proposal</a> that exposes error for <code class="language-plaintext highlighter-rouge">try?</code> expressions by allowing catch after the function.</p>
<blockquote>
<p>My pitch is to allow <code class="language-plaintext highlighter-rouge">catch</code> to be declared after a throwing function with a preceding <code class="language-plaintext highlighter-rouge">try?</code> keyword to expose any resulting error.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/joakim_hassila1">Joakim Hassila</a> asked <a href="https://forums.swift.org/t/swift-concurrency-threading-model-questions/49520">two interesting questions</a> about the Swift Concurrency threading model.</p>
<blockquote>
<p>I did view the behind-the-scenes talk and have tried to keep up with the discussions in various threads, but there are a few questions I have:</p>
<ol>
<li>It is still is unclear to me how the default executor keeps its pool of threads around and how threads are both created and woken up to get started to work. Is this fundamentally just a pool of pthreads which are woken up with the usual mechanisms, or something else? I understand the non-blocking (possible) out-of-order continuation execution, but how are things bootstrapped at a lower level? Where can I find out more about that (source pointers are fine :-) ) - I am curious as there was a comment about the performance characteristics being unknown on e g. Linux and I’d like to understand more and see if there is some work that needs to be done there. (Possible that it would require support for custom executors)</li>
<li>Same goes for thread shutdown when no more work is around (so basically, how are the threads managed in the default executor)</li>
</ol>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://twitter.com/slava_pestov/status/1400650772426244097">Pseudo-code” Swift for C++</a></li>
<li><a href="https://twitter.com/ericasadun/status/1402317358555795462">Pay attention to what’s on the desk</a></li>
<li><a href="https://twitter.com/AirspeedSwift/status/1403369770171260937">Labs with turkies</a></li>
</ul>
Issue #186
https://swiftweeklybrief.com/issue-186
2021-06-03T00:00:00-07:00
2021-06-03T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p><a href="https://developer.apple.com/wwdc21/">WWDC21</a> is just a couple of days away! Everyone is super excited, and there will be many <a href="https://developer.apple.com/wwdc21/beyond-wwdc/">community events</a> throughout the week and later this month. Don’t worry if you can’t follow everything. We have plenty of time afterwards! The most important thing is to enjoy this moment and follow along at your own pace!</p>
<p>This month we celebrate Pride Month, and with it the new <a href="https://swift.org/diversity/#community-groups">Pride in Swift</a> community group, which is now open.</p>
<p>I want to end this introduction by congratulating Apple’s WWDC21 <a href="https://www.apple.com/newsroom/2021/06/apples-wwdc21-swift-student-challenge-winners-code-to-change-the-world/">Swift Student Challenge</a> winners. This year the intake includes three women, Damilola Awofisayo, Gianna Yan, and Abinaya Dinesh, whose code will definitely change our world!</p>
<p>Now let’s get to the news and enjoy WWDC21. Thanks!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.spokestack.io/?utm_source=swift_weekly&utm_medium=email&utm_campaign=maker_launch_PAID?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_186" target="_blank">Machine learning for voice made easy</a></h4>
<p>Why don’t more Swift apps use voice? Machine learning for voice is full of pitfalls, and the native platform solutions are both clunky and uncustomizable. So we open-sourced our modular library for iOS that integrates with Siri (along with libraries for Node, Python, Android, & React Native) and then built a no-code service for creating custom wake words, domain-specific speech recognition, and custom synthetic AI voices—without a steep learning curve.</p>
<p><small><a href="https://www.spokestack.io/?utm_source=swift_weekly&utm_medium=email&utm_campaign=maker_launch_PAID?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_186" target="_blank">www.spokestack.io</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-14667">SR-14667</a> (Compiler) Deprecation warning about the use of <code class="language-plaintext highlighter-rouge">dynamicType</code> when it’s a real property.</p>
</blockquote>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/hollyborla/">Holly Borla</a> <a href="https://forums.swift.org/t/pride-in-swift-is-open/48837">posted</a> about the new <a href="https://swift.org/diversity/#community-groups">Pride in Swift</a> community group, which is now open on the Swift forums. She also <a href="https://forums.swift.org/t/announcing-the-swift-mentorship-program/48021/17">updated</a> us about the Swift Mentorship Program.</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> wrote <a href="https://www.hackingwithswift.com/articles/233/whats-new-in-swift-5-5">an article</a> about what’s new in Swift 5.5.</p>
<p><a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> posted <a href="https://www.youtube.com/watch?v=MZPeg8dqqzI">a video</a> explaining <code class="language-plaintext highlighter-rouge">CaseIterable</code>.</p>
<p>Swift 5.4.1 for Linux and Windows has been released. Downloads are available <a href="https://swift.org/download">here</a>.</p>
<p>Swift Trunk (main) nightly development Ubuntu 20.04 arch64 Snapshots are <a href="https://swift.org/download/#snapshots">available</a>!</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0317-async-let.md">SE-0317</a>: <em>Async Let</em> is <a href="https://forums.swift.org/t/se-0317-async-let/48848">under review</a>.</p>
<blockquote>
<p>Note that this feature builds upon the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md">structured concurrency proposal</a>, the <a href="https://forums.swift.org/t/se-0304-3rd-review-structured-concurrency/48847">third review</a> of which is happening concurrently to better discuss common aspects such as naming.</p>
<p>This review is part of the large <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">concurrency feature</a>, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0317-async-let.md">SE-0304</a>: <em>Structured Concurrency</em> is <a href="https://forums.swift.org/t/se-0304-3rd-review-structured-concurrency/48847">under the third review</a>.</p>
<blockquote>
<p>Following on from the <a href="https://forums.swift.org/t/se-0304-2nd-review-structured-concurrency/47217">second review</a>, the proposal authors have made several changes. The changes made after the second review can be found at the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md#review-changes">end of the proposal</a>, and the full diff can be found <a href="https://github.com/apple/swift-evolution/commit/01bdbdc2be26f9f26e4fad97e89d6648be1a6917#diff-6e3f26a7c1e2c41a13bcf34ef4c7d84625339b2898702f5e0bed0d6e05f1a778">here</a>.</p>
<p>Note that this feature is closely tied to the <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0317-async-let.md">async let proposal</a>, the <a href="https://forums.swift.org/t/se-0317-async-let/48848">first review</a> of which is happening concurrently to better discuss common aspects such as naming.</p>
<p>This review is part of the large <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">concurrency feature</a>, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0316-global-actors.md">SE-0316</a>: <em>Global Actors</em> is <a href="https://forums.swift.org/t/se-0316-global-actors/48905">under review</a>.</p>
<blockquote>
<p>This review is part of the large <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">concurrency feature</a>, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0316-global-actors.md">SE-0292</a>: <em>Package Registry Service</em> is <a href="https://forums.swift.org/t/se-0292-3rd-review-package-registry-service/49107">under third review</a>.</p>
<blockquote>
<p>The proposal has been <a href="https://github.com/apple/swift-evolution/pull/1319">amended</a> to address the feedback from the <a href="https://forums.swift.org/t/se-0292-2nd-review-package-registry-service">second review</a>, and is ready for another review.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md">SE-0311</a>: <em>Task-local values</em> is <a href="https://forums.swift.org/t/se-0311-3rd-review-task-local-values/49122">under third review</a>.</p>
<blockquote>
<p>The second review of SE-0311 was run to consider a significantly different language approach for binding and accessing task-local values, one based around property wrappers rather than an explicit key type. Shortly after the second review started, the community provided strong feedback that the proposal’s new use of property wrappers didn’t match their expectations because of the indirection through a wrapper value. The author agreed to re-revise the proposal, and the review was extended.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Swift on the Server Workgroup posted their <a href="https://forums.swift.org/t/sswg-annual-update-2020/49223">Annual Update for 2020</a>.</p>
<p><a href="https://twitter.com/alexito4">Alejandro Martinez</a> shared his <a href="https://forums.swift.org/t/swift-concurrency-video-series/48872">video series</a> about Swift Concurrency.</p>
<p><a href="https://twitter.com/grynspan">Jonathan Grynspan</a> pitched <a href="https://forums.swift.org/t/pitch-temporary-uninitialized-buffers/48954">an idea</a> to add temporary uninitialised buffers.</p>
<blockquote>
<p>I’d like to propose a new inlinable function in the standard library that allocates a buffer of a specified type and capacity, provides that buffer to a closure, and then deallocates the buffer. The buffer would be passed to the closure in an uninitialised state and treated as uninitialised on closure return—that is, the closure would be responsible for initialising and deinitialising the elements in the buffer.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/alexisqapa">Alexis Schultz</a> explained <a href="https://forums.swift.org/t/idea-switch-without-subject/49075">an idea</a> about using <code class="language-plaintext highlighter-rouge">switch</code> without a subject.</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/ashleeaburnett/status/1399721526216343563">Happy Pride Month! 🏳️🌈🏳️⚧️</a></p>
Issue #185
https://swiftweeklybrief.com/issue-185
2021-05-20T00:00:00-07:00
2021-05-20T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p><a href="https://developer.apple.com/wwdc21/">WWDC21</a> is just around the corner, and I believe we will have many significant updates then.</p>
<p>My favourite news piece in the last two weeks is the <a href="https://swift.org/blog/swift-mentorship-program/">Swift Mentorship Program</a> announcement. Mentoring and discovering how I can help others grow in their careers is very demanding but rewarding. I wish I had someone who could help me early in my career. So I encourage you to use this opportunity to get involved. Thank you to everyone who is making this possible.</p>
<p>Now let’s check out what’s happened in the last two weeks!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://mailchi.mp/hey/weekly-swift-exercise-signup?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_185" target="_blank">Weekly Swift Exercises</a></h4>
<p>Sometimes opening Xcode and building something by yourself is a daunting task. Increasing your confidence is key and there’s an easy way to do it: practice. Fernando’s weekly exercises help you practice concepts like closures and protocols while implementing actual features like dark mode. It’s free to join!</p>
<p><small><a href="https://mailchi.mp/hey/weekly-swift-exercise-signup?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_185" target="_blank">Weekly Swift Exercise Signup</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p>The Diversity in Swift workgroup announced the <a href="https://swift.org/blog/swift-mentorship-program/">Swift Mentorship Program</a>.</p>
<p><a href="https://twitter.com/leogdion">Leo G Dion</a> wrote a great article: <a href="https://learningswift.brightdigit.com/swift-dependency-management-spm/">Swift Packages – Dependency Management of the Future</a>.</p>
<p><a href="https://twitter.com/AndyIbanezK">Andy Ibanez</a> <a href="https://www.andyibanez.com/posts/swift-print-in-depth/">explored</a> Swift’s print, in depth.</p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> wrote <a href="https://oleb.net/2021/ordered-set/">an article</a> about how <code class="language-plaintext highlighter-rouge">OrderedSet</code> works.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/invalidname">Chris Adamson</a> merged <a href="https://github.com/apple/swift/pull/37383">a pull request</a> that provides documentation comments for <code class="language-plaintext highlighter-rouge">AsyncSequence</code> and related types.</p>
<p><a href="https://github.com/jirid">Jiri Dutkevic</a> merged <a href="https://github.com/apple/swift/pull/37397">a pull request</a> that removes the <code class="language-plaintext highlighter-rouge">UseSwiftCall/enable_swiftcall</code> frontend option because it wasn’t used and resolves <a href="https://bugs.swift.org/browse/SR-14453">SR-14453</a>.</p>
<p><a href="https://github.com/fredriss">fredriss</a> merged <a href="https://github.com/apple/swift/pull/37325">a pull request</a> that adds a unique Task ID to <code class="language-plaintext highlighter-rouge">AsyncTask</code>.</p>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> merged <a href="https://github.com/apple/swift/pull/37186">a pull request</a> that adds a missing <code class="language-plaintext highlighter-rouge">_Concurrency</code> dependency to the <code class="language-plaintext highlighter-rouge">Dispatch</code> overlay.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://forums.swift.org/t/se-0313-improved-control-over-actor-isolation/47813/35">SE-0313</a> <em>Improved control over actor isolation</em> was <a href="https://forums.swift.org/t/accepted-with-revisions-se-0313-improved-control-over-actor-isolation/48573">accepted with revisions</a>.</p>
<blockquote>
<p>The core team (with discussion with the proposal authors) has decided to accept a subset of the proposal. The revised (and accepted) proposal has the following parts removed:</p>
<ul>
<li>Support for multiple <strong>isolated</strong> parameters</li>
<li>The proposed changes for closure isolation control</li>
</ul>
<p>The removed parts, which were the most controversial sources in the review discussion, can be revisited in a future Swift Evolution proposal.</p>
<p>The review discussion also discussed the tradeoffs between a syntax-driven versus type-driven approach. The core team discussed the tradeoffs of the two methods and observed that a type-based approach would (by design) pervade the type system and potentially result in a more complicated system. The core team thus preferred the syntax-based approach in the proposal.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://forums.swift.org/t/se-0292-2nd-review-package-registry-service">SE-0292</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0292-package-registry-service/48338">returned for revision</a>.</p>
<blockquote>
<p>Before diving into further details, the core team would like to acknowledge it took an unusual long time to provide feedback to this proposal given Swift’s concurrency model proposals, which taken precedence over other proposals including SE-0292. The core team would like to thank the authors of SE-0292 for their patience and reiterate the importance of SE-0292, especially given its potential role in defining how Swift module disambiguation could work.</p>
<p>Most reviewers, as well as the core team, felt the 2nd iteration made significant progress towards acceptance. With that said, the core team would like to see the following points addressed before putting the proposal into a narrowly scoped third review.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0314-async-stream.md">SE-0314</a>: <em>AsyncStream and AsyncThrowingStream</em> is <a href="https://forums.swift.org/t/se-0314-asyncstream-and-asyncthrowingstream/48198">under review</a>.</p>
<blockquote>
<p>The continuation types added in <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0300</a> act as adaptors for synchronous code that signals completion by calling a delegate method or callback function. For code that instead yields multiple values over time, this proposal adds new types to support implementing an <code class="language-plaintext highlighter-rouge">AsyncSequence</code> interface.</p>
<p>Swift-evolution threads:</p>
<ul>
<li><a href="https://forums.swift.org/t/pitch-asyncstream-and-asyncthrowingstream/47820">[Pitch] AsyncStream and AsyncThrowingStream</a></li>
<li><a href="https://forums.swift.org/t/concurrency-yieldingcontinuation/47126">[Concurrency] YieldingContinuation</a></li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">SE-0306</a>: <em>Actors and <code class="language-plaintext highlighter-rouge">nonisolated let</code></em> <a href="https://github.com/apple/swift-evolution/pull/1354/files">amendment</a> is <a href="https://forums.swift.org/t/amendment-se-0306-actors-and-nonisolated-let/48386">under a review</a>.</p>
<blockquote>
<p>This amendment is motivated by having more hands-on experience incrementally adopting actors into an existing app. Immutable object state is very common, and as originally accepted, the proposal requires even immutable <code class="language-plaintext highlighter-rouge">let</code> properties in actors to be treated as actor-isolated unless explicitly marked <code class="language-plaintext highlighter-rouge">isolated</code>. The proposal authors feel that in practice this creates too heavy of an annotation burden when turning existing code into actor code, since every immutable value must either be marked <code class="language-plaintext highlighter-rouge">nonisolated</code> or <code class="language-plaintext highlighter-rouge">await</code>-ed everywhere. There were however legitimate concerns about library evolution in the original review if <code class="language-plaintext highlighter-rouge">public let</code>s would be implicitly exported as non-isolated by default, since that would limit the library author’s ability to turn the declarations into locally-mutable state or computed properties with isolated computation in the future. This amendment seeks to balance the competing considerations by allowing <code class="language-plaintext highlighter-rouge">let</code> properties on actors to be accessed without isolation locally within a module, but not across modules unless the declaration is explicitly <code class="language-plaintext highlighter-rouge">nonisolated</code>.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/chockenberry">Craig Hockenberry</a> pitched <a href="https://forums.swift.org/t/lets-fix-if-let-syntax/48188">an idea</a> to fix <code class="language-plaintext highlighter-rouge">if let</code> syntax.</p>
<p><a href="https://twitter.com/k__mahar">Kaitlin Mahar</a> updated us about Swift on the <a href="https://forums.swift.org/t/april-28-2021/48265">Server Workgroup April 28, 2021 meeting notes</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/pitch-2-global-actors/48332">informed</a> that he updated the <a href="https://github.com/DougGregor/swift-evolution/blob/global-actors/proposals/nnnn-global-actors.md">revision</a> of the global actors proposal.</p>
<blockquote>
<p>Changes from the first pitch include:</p>
<ul>
<li>Clarify that the types of global-actor-qualified functions are global-actor-qualified.</li>
<li>State that global-actor-qualified types are Sendable</li>
<li>Expand on the implicit conversion rules for function types</li>
<li>Require global and static variables to be immutable & non-isolated or global-actor-qualified.</li>
<li>Describe the relationship between global actors and instance actors</li>
<li>Update inference rules for global actors</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/ktosopl">Konrad Malawski</a> <a href="https://forums.swift.org/t/pitch-3-async-let/48336">updated</a> the <code class="language-plaintext highlighter-rouge">async let</code> <a href="https://github.com/ktoso/swift-evolution/blob/d44f5dc31fa91c7e029ae9c17a5256af0c1a91aa/proposals/mmmm-async-let.md">proposal</a> with the latest semantics and spelling details.</p>
<blockquote>
<p>This is the first pitch of the feature as a stand-alone thing, it was previously pitched as part of structured concurrency <a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">pitch #1 3</a>, and <a href="https://forums.swift.org/t/pitch-2-structured-concurrency/43452">pitch #2</a> and was separated out later on as it’s a feature large enough to deserve its own discussion.</p>
<p>Changes since the original pitch are mostly focused around additional discussion and details around exact semantics of the feature, e.g., we added:</p>
<ul>
<li>longer discussion of throwing semantics
<ul>
<li>this is an area we’d welcome discussion of. I.e. currently if an async let has a throwing initialiser, and is <em>not</em> awaited explicitly, the task is awaited on implicitly but the thrown error is silently dropped. This is equivalent to TaskGroup semantics and in line with “since you didn’t await on it, you clearly don’t care about it” however it may have some tricky implications.</li>
</ul>
</li>
<li>more details about cancellation handling</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/igor-makarov">Igor Makarov</a> pitched <a href="https://forums.swift.org/t/allow-calling-type-members-from-instance-members-without-self/48389">an idea</a> to allow calling type members from instance members without <code class="language-plaintext highlighter-rouge">Self.</code>.</p>
<blockquote>
<p>Following up on the <a href="https://forums.swift.org/t/modifier-to-make-a-func-on-a-type-a-free-function/47749">previous discussion</a>, I wanted to refine my suggestion with the one <a href="https://forums.swift.org/t/modifier-to-make-a-func-on-a-type-a-free-function/47749/18">Svein proposed</a>.</p>
<p>Make the prefix <code class="language-plaintext highlighter-rouge">Self.</code> non-required when calling a type member (<code class="language-plaintext highlighter-rouge">static</code> or <code class="language-plaintext highlighter-rouge">class</code>) from an instance member. This can apply to botb methods and properties.</p>
</blockquote>
<p><a href="https://twitter.com/o_aberration">Adam Fowler</a> <a href="https://forums.swift.org/t/about-the-soto-category/48509/2">explained</a> how Swift SDK for AWS works.</p>
<blockquote>
<p>Soto is a third-party Swift SDK for Amazon Web Services (AWS). The library provides access to all AWS services and works on Linux, macOS, and iOS.</p>
<p>Soto is heavily integrated with a number of Swift on Server packages including AsyncHTTPClient, SwiftNIO, Logging, Metrics and is primarily targeted for Swift on Server. All the API calls are designed to be called in an asynchronous manner to avoid blocking your current thread.</p>
<p>Even though it isn’t the primary target we have still put in a fair amount of work to ensure the library works on iOS and will continue to ensure this is the case.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/rvenable">Richard Venable</a> pitched <a href="https://forums.swift.org/t/pitch-enum-case-inferencing/48536">an idea</a> about enum case inferencing.</p>
<blockquote>
<p>I was reading the discussion on <a href="https://forums.swift.org/t/lets-fix-if-let-syntax">Let’s fix <code class="language-plaintext highlighter-rouge">if let</code> syntax</a>. It’s a good discussion, but it overlooks how weird Swift is to encourage us to create variables that replace existing variables but with a different type (optional type replaced with non-optional type). <code class="language-plaintext highlighter-rouge">let x = x</code> is a weird pattern, but we are all just accustomed to it.</p>
<p>Meanwhile, the proposal to just use <code class="language-plaintext highlighter-rouge">if x != nil { }</code> is not getting enough attention. There was an <a href="https://forums.swift.org/t/lets-fix-if-let-syntax/48188/12">objection</a> saying “I find it really weird that merely performing a comparison would change the type of a variable from optional to non-optional.” But what if we weren’t changing the type of a variable? What if it is the <em>same variable</em> - the Swift compiler just infers what we want to do with it based on prior knowledge.</p>
</blockquote>
<p><a href="https://twitter.com/ktosopl">Konrad Malawski</a> <a href="https://forums.swift.org/t/swift-to-participate-in-gsoc-2021/44689/29">informed</a> about 5 accepted projects for this year’s Swift in GSoC.</p>
<blockquote>
<ul>
<li>SwiftPM support for Swift scripts</li>
<li>Inlay type hints for SourceKit-LSP</li>
<li>Alive2 for SIL</li>
<li>A “Bite-Sized” BitArray</li>
<li>Shared Storage for Property Wrappers</li>
</ul>
<p>Details about the accepted projects can be found here: <a href="https://summerofcode.withgoogle.com/organizations/5050498865954816/#projects">https://summerofcode.withgoogle.com/organizations/5050498865954816/#projects</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1392892679852199939">What is the real age of Swift?</a></p>
Issue #184
https://swiftweeklybrief.com/issue-184
2021-05-06T00:00:00-07:00
2021-05-06T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Let’s start with the most important news: <a href="https://swift.org/blog/swift-5-4-released/">Swift 5.4</a> has been released alongside Xcode 12.5. It has some notable new features and additions like result builders, multiple variadic parameters, and more.</p>
<p>WWDC is just one month away! Who knows, maybe this is the reason why so many Swift Evolution proposals are in review or have been accepted?</p>
<p>For the last couple of weeks I have been pretty swamped with work, and I’m glad that I’m not alone on this project. If you want to get involved, or your company wants to sponsor, it would be very much appreciated. Thank you, everyone!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://pasteapp.io/?utm_source=SwiftWeeklyBrief&utm_medium=email_web&utm_campaign=sponsor-2021?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_184" target="_blank">Paste – unlimited clipboard for Mac, iPhone, and iPad</a></h4>
<p>Never lose a copy again with Paste. It’s like a time machine for your clipboard that stores every link, image, file, or piece of code you copy and lets you access it within seconds. Try Paste for free and start working faster, better, and smarter.</p>
<p><small><a href="https://pasteapp.io/?utm_source=SwiftWeeklyBrief&utm_medium=email_web&utm_campaign=sponsor-2021?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_184" target="_blank">pasteapp.io</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14587">SR-14587</a> <code class="language-plaintext highlighter-rouge">refactor-check-compiles</code> should generate both <code class="language-plaintext highlighter-rouge">-dump-text</code> and <code class="language-plaintext highlighter-rouge">dump-rewritten</code> from a single <code class="language-plaintext highlighter-rouge">swift-refactor</code> invocation</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> wrote <a href="https://swift.org/blog/swift-5-4-released/">a blog post</a> about the release of Swift 5.4.</p>
<p><a href="https://twitter.com/zntfdr">Federico Zanetello</a> wrote <a href="https://www.fivestars.blog/articles/spm-5-4/">an article</a> explaining what’s new in Swift Package Manager in Swift 5.4.</p>
<p><a href="https://twitter.com/alexsteinerde">Alexander Steiner</a> created <a href="https://github.com/alexsteinerde/docker-client-swift">a Docker Client written in Swift</a>. It uses the NIO Framework to communicate with the Docker Engine via sockets.</p>
<p><a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> created <a href="https://www.youtube.com/watch?v=6F3SJ4a08sc">a video</a> to walk us through what’s new in Swift 5.4.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/eeckstein/">Erik Eckstein</a> created <a href="https://github.com/apple/swift/pull/37058">a pull request</a> that starts implementing SIL optimizations in Swift.</p>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> created <a href="https://github.com/vapor/vapor/pull/2613">a pull request</a> that adds support for <code class="language-plaintext highlighter-rouge">async/await</code> to Vapor.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">SE-0306</a> <em>Actors</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0306-actors/47662">accepted with modification</a>.</p>
<blockquote>
<p>For this second review, we had asked the community to explore the question of whether let bindings should be exceptional in their default actor isolation behavior, and based on community feedback, the Core Team has accepted the proposal with the modification that let bindings should be isolated by default, consistent with what is proposed for other declarations. Several topics, in addition to isolation of lets, came up in the second review…</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> <em>Package Manager Extensible Build Tools</em> was <a href="https://forums.swift.org/t/accepted-se-0303-package-manager-extensible-build-tools/47741">accepted</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0303-2nd-review-package-manager-extensible-build-tools/">second review</a> of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> has concluded. Feedback in the <a href="https://forums.swift.org/t/se-0303-package-manager-extensible-build-tools/">first review</a> was positive and feedback from the <a href="https://forums.swift.org/t/se-0303-2nd-review-package-manager-extensible-build-tools/">second review</a> has been largely informational. The proposal is <strong>accepted</strong> with some minor clarifications (<a href="https://github.com/apple/swift-evolution/commit/c107cd34e880bed2e8b0915fdd239272d3b49eb8">diff</a>).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a> <em>Package Manager Binary Target Improvements</em> was <a href="https://forums.swift.org/t/accepted-se-0305-package-manager-binary-target-improvements/47742">accepted</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0305-2nd-review-package-manager-binary-target-improvements/">second review</a> of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a> has concluded. Feedback in the <a href="https://forums.swift.org/t/se-0305-package-manager-binary-target-improvements/">first review</a> was positive and feedback from the <a href="https://forums.swift.org/t/se-0305-2nd-review-package-manager-binary-target-improvements/">second review</a> has been largely informational. The proposal is <strong>accepted</strong> with some minor clarifications (<a href="https://github.com/apple/swift-evolution/commit/884df3ad6020f0724e06184534b21dd76bd6f4bf">diff</a>).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0310-effectful-readonly-properties.md">SE-0310</a> <em>Effectful Read-only Properties</em> was <a href="https://forums.swift.org/t/accepted-se-0310-effectful-read-only-properties/47739">accepted</a>.</p>
<blockquote>
<p>The Core Team considered a number of points that came up in the discussion:</p>
<ul>
<li>There was some discussion about the placement of effects specifiers (<code class="language-plaintext highlighter-rouge">async</code> and <code class="language-plaintext highlighter-rouge">throws</code>), with a request to move the specifiers to the property declaration itself rather than being specified on the getter. The proposal author has <a href="https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401/38">clarified</a> why the proposed syntax is the appropriate syntax. The proposal will be amended with this rationale.</li>
<li>It <a href="https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401/49">was noted</a> that further extension of effects to writable properties would make it hard for users to separate the getter and setter declarations</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0308-postfix-if-config-expressions.md">SE-0308</a> <em>postfix <code class="language-plaintext highlighter-rouge">#if</code> config expressions</em> was <a href="https://forums.swift.org/t/accepted-se-0308-postfix-if-config-expressions/47780">accepted</a>.</p>
<blockquote>
<p>Beyond the enthusiastic positive response, there was additional interest in further enhancements in the same direction. The core team believes that additional refinement of conditional compilation is something that the language would benefit from. As such, proposals extending support towards conditional compilation of repeated lexical constructs, e.g. elements within an array literal, would be welcome. For non-repeated constructs, there are potential issues with the parsing, for example in the removal of a binary operator may change the operator precedence of subsequent expressions, and this would require careful, deliberate handling. Such a change is not unreasonable, but would demand an appropriate level of design and care towards an implementation.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md">SE-0309</a> <em>Unlock Existentials for All Protocols</em> was <a href="https://forums.swift.org/t/accepted-se-0309-unlock-existentials-for-all-protocols/47902">accepted</a>.</p>
<blockquote>
<p>There was a lot of enthusiasm for removing the infamous “protocol can only be used as a generic constraint because it has Self or associated type requirements” restriction, and the Core Team agrees that at this point in Swift’s development, it serves no technical purpose, and the problems it causes are worse than the ones it tries to avoid. The Core Team also acknowledges that this proposal by itself does not solve all the problems with existentials in Swift, but that it is important progress in unblocking further improvements to generics and existentials going forward.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0312-indexed-and-enumerated-zip-collections.md">SE-0312</a>: <em>Add <code class="language-plaintext highlighter-rouge">indexed()</code> and Collection conformances for <code class="language-plaintext highlighter-rouge">enumerated()</code> and <code class="language-plaintext highlighter-rouge">zip(_:_:)</code></em> is <a href="https://forums.swift.org/t/se-0312-add-indexed-and-collection-conformances-for-enumerated-and-zip/47740">under a review</a>.</p>
<blockquote>
<p>This proposal aims to fix the lack of <code class="language-plaintext highlighter-rouge">Collection</code> conformance of the sequences returned by <code class="language-plaintext highlighter-rouge">zip(_:_:)</code> and <code class="language-plaintext highlighter-rouge">enumerated()</code>, preventing them from being used in a context that requires a <code class="language-plaintext highlighter-rouge">Collection</code>. Also included is the addition of the <code class="language-plaintext highlighter-rouge">indexed()</code> method on <code class="language-plaintext highlighter-rouge">Collection</code> as a more ergonomic, efficient, and correct alternative to <code class="language-plaintext highlighter-rouge">c.enumerated()</code> and <code class="language-plaintext highlighter-rouge">zip(c.indices, c)</code>.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/pitch-add-indexed-and-collection-conformances-for-enumerated-and-zip/47288">Pitch</a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md">SE-0311</a>: <em>Task-local values</em> is <a href="https://forums.swift.org/t/se-0311-2nd-review-task-local-values/47738">under a second review</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0311-task-local-values/47478">first review</a> received a lot of very useful feedback. In response, the author has made major changes to the proposal. The Core Team has decided to put up the revised proposal for <em>de novo</em> review; that is, you should essentially review this proposal as if it were an entirely different proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0313-actor-isolation-control.md">SE-0313</a>: <em>Improved control over actor isolation</em> is <a href="https://forums.swift.org/t/se-0313-improved-control-over-actor-isolation/47813">under a review</a>.</p>
<blockquote>
<p>The <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">Swift actors proposal</a> introduces the notion of <em>actor-isolated</em> declarations, which are declarations that can safely access an actor’s isolated state. In that proposal, all instance methods, instance properties, and instance subscripts on an actor type are actor-isolated, and they can synchronously use those declarations on <code class="language-plaintext highlighter-rouge">self</code>. This proposal generalizes the notion of actor isolation to allow better control, including the ability to have actor-isolated declarations that aren’t part of an actor type (e.g., they can be non-member functions) and have non-isolated declarations that are instance members of an actor type (e.g., because they are based on immutable, non-isolated actor state). This allows better abstraction of the use of actors, additional actor operations that are otherwise not expressible safely in the system, and enables some conformances to existing, synchronous protocols.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> pitched <a href="https://forums.swift.org/t/initiating-asynchronous-work-from-synchronous-code/47714">a proposal</a> that adds a better way to initiate asynchronous work from synchronous code. You can read the full proposal <a href="https://gist.github.com/DougGregor/2dd62cb9130db678f3fc8cd44b5535bc">here</a>.</p>
<blockquote>
<p>Swift <code class="language-plaintext highlighter-rouge">async</code> functions can only directly be called from other <code class="language-plaintext highlighter-rouge">async</code> functions. In synchronous code, the only mechanism provided by the Swift Concurrency model to create asynchronous work is <code class="language-plaintext highlighter-rouge">detach</code>. The <code class="language-plaintext highlighter-rouge">detach</code> operation creates a new, detached task that is completely independent of the code that initiated the <code class="language-plaintext highlighter-rouge">detach</code>: the closure executes concurrently, is independent of any actor unless it explicitly opts into an actor, and does not inherit certain information (such as priority).</p>
</blockquote>
<p><a href="https://github.com/Sammcb">Samuel McBroom</a> pitched <a href="https://forums.swift.org/t/add-isprependconcatenationmark-to-unicode-scalar-properties/47682">an idea</a> to add <code class="language-plaintext highlighter-rouge">isPrependConcatenationMark</code> to <code class="language-plaintext highlighter-rouge">Unicode.Scalar.Properties</code>.</p>
<blockquote>
<p>Swift’s Unicode.Scalar.Properties struct includes many useful property checks for scalars, such as <code class="language-plaintext highlighter-rouge">isAlphabetic</code>, <code class="language-plaintext highlighter-rouge">isHexDigit</code>, etc. I think including a new <code class="language-plaintext highlighter-rouge">isPrependConcatenationMark</code> property check would also be useful, corresponding to the <a href="https://unicode.org/reports/tr44/#Prepended_Concatenation_Mark">Prepend_Concatenation_Mark property</a> listed in the <a href="http://unicode.org/reports/tr44/#Property_Index">Unicode Standard</a>.</p>
</blockquote>
<p>Swift on the Server Workgroup meetings:</p>
<ul>
<li><a href="https://forums.swift.org/t/april-14th-2021/47756">14th April 2021</a></li>
<li><a href="https://forums.swift.org/t/march-31-2021/47770">March 31, 2021</a></li>
</ul>
<p><a href="https://github.com/phausler">Philippe Hausler</a> pitched <a href="https://forums.swift.org/t/pitch-asyncstream-and-asyncthrowingstream/47820">a proposal</a>: <em>Continuations for interfacing async tasks with synchronous code</em>.</p>
<blockquote>
<p>Asynchronous Swift code needs to be able to work with existing synchronous
code that uses techniques such as completion callbacks and delegate methods to
respond to events. Asynchronous tasks can suspend themselves on
<strong>continuations</strong> which synchronous code can then capture and invoke to
resume the task in response to an event.</p>
<p>Swift-evolution thread:</p>
<ul>
<li><a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">Structured concurrency</a></li>
<li><a href="https://forums.swift.org/t/concurrency-continuations-for-interfacing-async-tasks-with-synchronous-code/43619">Continuations for interfacing async tasks with synchronous code</a></li>
</ul>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/AndrewCrow/status/1388258928794898434">There is only one use case for AirTags</a>.</p>
Issue #183
https://swiftweeklybrief.com/issue-183
2021-04-22T00:00:00-07:00
2021-04-22T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>I want to thank <a href="https://twitter.com/AppForce1">Jeroen</a> for helping out with last week’s issue. He did a great job spicing up the usual flow. How did you like it? <a href="https://twitter.com/swiftlybrief">Let us know</a>.</p>
<p>We finally have the <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-release-notes#Swift">Xcode 12.5 RC</a>, and it has some notable Swift language fixes and improvements.</p>
<p>In the last two weeks it seems like the Swift core team have woken up after a winter slumber. Dozens of proposals are now in review and many have been returned.</p>
<p>Now let’s go to the news!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.git-tower.com" target="_blank">A Better Way to Work With Git</a></h4>
<p>Imagine you could undo mistakes in Git with a simple keyboard shortcut, use Interactive Rebase via drag and drop or clone a repository from GitHub with a single click. Tower lets you do exactly that and so much more. Finally take advantage of Git’s powerful feature set - in a beautiful GUI that will make you more productive every single day. Try it free for 30 days.</p>
<p><small><a href="https://www.git-tower.com" target="_blank">www.git-tower.com</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-release-notes#Swift">Xcode 12.5 RC</a> is out and has a lot of new Swift features, improvements, and fixes.</p>
<p><a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> created <a href="https://www.youtube.com/watch?v=pSTU6UlA4uw">a video</a> explaining why we should read Swift Evolution Proposals.</p>
<p><a href="https://twitter.com/Leo_Pugliese">Leonardo Maia Pugliese</a> wrote <a href="https://holyswift.app/single-forward-pipe-operator-in-swift">an article</a> exploring the single forward pipe operator in Swift.</p>
<p><a href="https://twitter.com/mishaldshah">Mishal Shah</a> informed us that Swift 5.5 nightly development <a href="https://swift.org/download/#snapshots">snapshots</a> are now available.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/DavidGoldman">David Goldman</a> created <a href="https://github.com/apple/sourcekit-lsp/pull/388">a pull request</a> that adds support for <code class="language-plaintext highlighter-rouge">clangd</code>’s semantic highlighting.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/36940">a pull request</a> that fixes the issue where <code class="language-plaintext highlighter-rouge">SIL</code> type lowering did not commute with <code class="language-plaintext highlighter-rouge">subst()</code>.</p>
<p><a href="https://github.com/hassila">Joakim Hassila</a> created <a href="https://github.com/apple/swift-nio/pull/1804">a pull request</a> that adds support for <code class="language-plaintext highlighter-rouge">io_uring</code> for the SwiftNIO project.</p>
<p><a href="https://github.com/Lukasa">Cory Benfield</a> merged <a href="https://github.com/apple/swift-nio/pull/1701">a pull request</a> that adds <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code> support to the SwiftNIO.</p>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> created <a href="https://github.com/swift-server/swift-backtrace/pull/42">a pull request</a> that adds backtrace support for Windows.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://forums.swift.org/t/se-0305-package-manager-binary-target-improvements/45589">SE-0305</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0305-package-manager-binary-target-improvements/47441">returned for revision</a>.</p>
<blockquote>
<p>The feedback to the idea of extending SwiftPM to support new kind of binary targets, in conjunction with the plugin system proposed in <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> was positive. However, given <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> was returned to review, as well as feedback from reviewers requesting additional details on the structure suggested on <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a>, the core team decided to ask that <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a> is refined alongside <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a>.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">SE-0306</a>: <em>Actors</em> is <a href="https://forums.swift.org/t/se-0306-second-review-actors/47291">under a second review</a>.</p>
<blockquote>
<p>The core team sees two competing draws for consistency here—first, as Chris notes, in other places where Swift models API design, <code class="language-plaintext highlighter-rouge">let</code> is externally treated equivalently with a get-only <code class="language-plaintext highlighter-rouge">var</code>, and by that principle, actors should follow suit and not expose <code class="language-plaintext highlighter-rouge">let</code>s as implicitly <code class="language-plaintext highlighter-rouge">nonisolated</code> outside of the actor even if they are immutable. That would reserve for the actor the ability to evolve the interface into an internally-mutable variable, or get-only computed property, without breaking API or ABI. It would also result in a consistent rule for how <code class="language-plaintext highlighter-rouge">isolated</code> and <code class="language-plaintext highlighter-rouge">nonisolated</code> apply to actor members; instead of <code class="language-plaintext highlighter-rouge">let</code>s being a special case, <em>any</em> actor declaration would require <code class="language-plaintext highlighter-rouge">nonisolated</code> to be explicitly annotated to declare it as safe to access from outside the actor without isolation.</p>
<p>On the other hand, “<code class="language-plaintext highlighter-rouge">let</code>s are immutable and safe to share across threads” has also been a common message through Swift’s history, and it could seem boilerplatey to require an explicit annotation on top of <code class="language-plaintext highlighter-rouge">let</code> to say that, yes, this immutable value is actually immutable. If actors in practice end up carrying a lot of immutable state, the annotation burden could be onerous. The core team would like to hear from the community, particularly adopters who have experimented with actors, to get more signal about how much burden treating the isolation <code class="language-plaintext highlighter-rouge">let</code>s equivalently with other declarations will be in practice.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0310-effectful-readonly-properties.md">SE-0310</a>: <em>Effectful Read-only Properties</em> is <a href="https://forums.swift.org/t/se-0310-effectful-read-only-properties/47401">under a review</a>.</p>
<blockquote>
<p>Nominal types such as classes, structs, and enums in Swift support <a href="https://docs.swift.org/swift-book/LanguageGuide/Properties.html">computed properties</a> and <a href="https://docs.swift.org/swift-book/LanguageGuide/Subscripts.html">subscripts</a>, which are members of the type that invoke programmer-specified computations when getting or setting them. The recently accepted proposal <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a> introduced asynchronous functions via <code class="language-plaintext highlighter-rouge">async</code>, in conjunction with <code class="language-plaintext highlighter-rouge">await</code>, but did not specify that computed properties or subscripts can support effects like asynchrony. Furthermore, to take full advantage of <code class="language-plaintext highlighter-rouge">async</code> properties, the ability to specify that a property <code class="language-plaintext highlighter-rouge">throws</code> is also important.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a>: <em>Package Manager Binary Target Improvements</em> is <a href="https://forums.swift.org/t/se-0305-2nd-review-package-manager-binary-target-improvements/47439">under a second review</a>.</p>
<blockquote>
<p>The Swift Package Manager’s binaryTarget type lets packages vend libraries that either cannot be built in Swift Package Manager for technical reasons, or for which the source code cannot be published for legal or other reasons.</p>
<p>In the current version of SwiftPM, binary targets only support libraries in an Xcode-oriented format called XCFramework, and only for Apple platforms.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a>: <em>Package Manager Extensible Build Tools</em> is <a href="https://forums.swift.org/t/se-0303-2nd-review-package-manager-extensible-build-tools/47438">under a second review</a>.</p>
<blockquote>
<p>This is a proposal for extensible build tools support in Swift Package Manager. The initial set of functionality is intentionally basic, and focuses on a general way of allowing build tool plugins to add commands to the build graph. The approach is to:</p>
<ul>
<li>provide a scalable way for packages to define plugins that can provide build-related capabilities</li>
<li>support a narrowly scoped initial set of possible capabilities that plugins can provide</li>
</ul>
<p>The set of possible capabilities can then be extended in future SwiftPM versions. The goal is to provide short-term support for common tasks such as source code generation, with a design that can scale to more complex tasks in the future.</p>
<p>This proposal depends on improvements to the existing Binary Target type in SwiftPM — those details are the subject of the separate proposal <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0311-task-locals.md">SE-0311</a>: <em>Task-local values</em> is <a href="https://forums.swift.org/t/se-0311-task-local-values/47478">under a review</a>.</p>
<blockquote>
<p>This proposal is part of the larger <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">concurrency feature</a>. There have been quite a lot of these reviews, and there are a quite a few more coming, I’m afraid; still, we seem to have got through most of the more difficult ones. Thank you for your patience with all this.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0309-unlock-existential-types-for-all-protocols.md">SE-0309</a>: <em>Unlock existential types for all protocols</em> is <a href="https://forums.swift.org/t/se-0309-unlock-existential-types-for-all-protocols/47515">under a review</a>.</p>
<blockquote>
<p>Swift allows one to use a protocol as a type when its <em>requirements</em> meet a rather unintuitive list of criteria, among which is the absence of associated type requirements, and emits the following error otherwise: <code class="language-plaintext highlighter-rouge">Protocol can only be used as a generic constraint because it has 'Self' or associated type requirements</code>. Our objective is to <em>alleviate</em> this limitation to impact only the ability to access certain members (instead of preemptively sealing off the entire protocol interface), and adjust the specified criteria to further reduce the scope of the restriction.</p>
<p>This proposal is a preamble to a series of changes aimed at generalizing value-level abstraction (existentials) and improving its interaction with type-level abstraction (generics). For an in-depth exploration of the relationships among different built-in abstractions models, we recommend reading the <a href="https://forums.swift.org/t/improving-the-ui-of-generics/22814">design document for improving the UI of the generics model</a>.</p>
<p>Swift-Evolution Pitch Threads: <a href="https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025">Thread #1</a>, <a href="https://forums.swift.org/t/unlock-existential-types-for-all-protocols/40665">Thread #2</a></p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/timv">Tim Vermeulen</a> pitched a <a href="https://forums.swift.org/t/pitch-add-indexed-and-collection-conformances-for-enumerated-and-zip/47288">proposal</a> to add <code class="language-plaintext highlighter-rouge">indexed()</code> and <code class="language-plaintext highlighter-rouge">Collection</code> conformances for <code class="language-plaintext highlighter-rouge">enumerated()</code> and <code class="language-plaintext highlighter-rouge">zip(_:_:)</code>.</p>
<blockquote>
<p>This proposal aims to fix the lack of <code class="language-plaintext highlighter-rouge">Collection</code> conformance of the sequences returned by <code class="language-plaintext highlighter-rouge">zip(_:_:)</code> and <code class="language-plaintext highlighter-rouge">enumerated()</code>, preventing them from being used in a context that requires a <code class="language-plaintext highlighter-rouge">Collection</code>. Also included is the addition of the <code class="language-plaintext highlighter-rouge">indexed()</code> method on <code class="language-plaintext highlighter-rouge">Collection</code> as a more ergonomic, efficient, and correct alternative to <code class="language-plaintext highlighter-rouge">c.enumerated()</code> and <code class="language-plaintext highlighter-rouge">zip(c.indices, c)</code>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/1oo7">Jonathan G.</a> started an interesting <a href="https://forums.swift.org/t/make-it-official-the-undocumented-private-api-signifier/47381">discussion</a> about making the “Undocumented/Private API” signifier <code class="language-plaintext highlighter-rouge">_</code> official.</p>
<blockquote>
<p>There is an undocumented convention in Swift, of appending an underscore “_” to a public symbol or attribute to communicate some special meaning.</p>
<p>However, you will not find any mention of this practice within Swift’s own documentation on <a href="http://swift.org/">swift.org</a>, nor any explanation of the often subtle differences in meaning of “_”. (Please correct me if I’m wrong. I did several searches and came up with nothing, and several read-throughs.)</p>
</blockquote>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> started <a href="https://forums.swift.org/t/why-is-dictionary-position-not-settable/47435">a discussion</a> about why <code class="language-plaintext highlighter-rouge">Dictionary[position:]</code> is not settable?</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">Dictionary</code> type exposes a non-nil subscript <a href="https://developer.apple.com/documentation/swift/dictionary/2831255-subscript"><code class="language-plaintext highlighter-rouge">[position:]</code></a> which takes a <code class="language-plaintext highlighter-rouge">Dictionary.Index</code>. I always wondered why this subscript is <code class="language-plaintext highlighter-rouge">get</code>-only, since I often find myself wanting to check if a key-value pair is present in the dictionary, and then mutate the value only if it exists.</p>
</blockquote>
<p>Swift on the Server Workgroup meeting notes:</p>
<ul>
<li><a href="https://forums.swift.org/t/march-17th-2021/47427">March 17th, 2021</a></li>
<li><a href="https://forums.swift.org/t/march-31st-2021/47404">March 31st, 2021</a></li>
</ul>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/towernter/status/1383815365520629760">When you forget to get rid of your debugging statements</a></p>
Issue #182
https://swiftweeklybrief.com/issue-182
2021-04-08T00:00:00-07:00
2021-04-08T00:00:00-07:00
Jeroen Leenarts
https://twitter.com/appforce1
https://github.com/appforce1.png?size=100
appforce1
<p>Big announcement this week: <a href="https://developer.apple.com/wwdc21/">WWDC21 will happen from June 7 to 11.</a> It will be online only, so everyone in our community can join in on the fun.</p>
<p><a href="https://twitter.com/fassko">Kristaps</a> asked me to take care of the newsletter this week. So hi, my name is <a href="https://appforce1.net/swiftweeklybrief/">Jeroen</a> and I recently got involved with <a href="https://swiftweeklybrief.com/">Swift Weekly Brief</a> by running some infrastructure. Writing for you all is a bit of a leap for me, so <a href="https://twitter.com/swiftlybrief">let us know what you think</a>!</p>
<p>Just like in issue 181 I will start by mentioning the wonderful work being done to build a more inclusive Swift developer ecosystem: <a href="https://swift.org/diversity/">Diversity in Swift</a>.</p>
<p>As always Swift Evolution is moving fast. Quite a few interesting proposals have been accepted, and a number of interesting pitches have been proposed. On top of that, we’ve decided to add a community section below, to highlight a few members whose work we think you will like.</p>
<p>Thank you so much for reading, and enjoy issue 182.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-14443">SR-14443</a> [Compiler] [C++] Don’t crash on invalid dependent values.</p>
</blockquote>
<h3 id="news-and-community">News and community</h3>
<p>Check out the new <a href="https://swift.org/blog/swift-collections/">Swift Collections</a> package, a new open-source package focused on extending the set of available Swift data structures. Like the <a href="https://github.com/apple/swift-algorithms">Swift Algorithms</a> and <a href="https://github.com/apple/swift-numerics">Swift Numerics</a> packages before it, it is being released to help incubate new functionality for the Swift Standard Library. <a href="https://forums.swift.org/t/introducing-swift-collections/47169">Join the conversation on Swift Collections on the Swift forums</a>.</p>
<blockquote>
<p>The Swift Standard Library currently implements the three most essential general-purpose data structures: Array, Set and Dictionary. These are the right tool for a wide variety of use cases, and they are particularly well-suited for use as currency types. But sometimes, in order to efficiently solve a problem or to maintain an invariant, Swift programmers would benefit from a larger library of data structures.</p>
</blockquote>
<p><a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> creates great videos relevant to Swift developers. Here’s a few you might like to try: <a href="https://www.youtube.com/watch?v=D8C9jbx0FMU">Exploring Swift Evolution Proposals</a>, <a href="https://www.youtube.com/watch?v=YhaeD8kEjr8">What’s the difference between Swift error mechanisms</a> and
<a href="https://www.youtube.com/watch?v=6jj5egDNW4M">Why Never is such a special type</a>.</p>
<p><a href="https://twitter.com/jesse_squires">Jesse Squires</a>, the original founder of this newsletter, has done some digging on why <a href="https://www.jessesquires.com/blog/2021/04/05/why-swift-closures-are-not-equatable/">Swift Closures are not equatable</a>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0285-ease-pound-file-transition.md">SE-0285</a> <em>Ease the transition to concise magic file strings</em> was <a href="https://forums.swift.org/t/accepted-se-0285-ease-the-transition-to-concise-magic-file-strings/38516">accepted</a></p>
<blockquote>
<p>The feedback was generally positive, and to address the concern around which variants of #file library authors should use the proposal was modified to include <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0285-ease-pound-file-transition.md#swift-api-design-guidelines-amendment">Swift API Design Guidelines amendment</a> encouraging library authors to prefer #fileID over alternatives.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a> <em>async/await</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318">accepted with modification</a></p>
<blockquote>
<p>Feedback was very positive on the concept of adding async/await in general with a few key points raised. Read about those points in the forum post.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0307-allow-interchangeable-use-of-double-cgfloat-types.md">SE-0307</a> <em>Allow interchangeable use of CGFloat and Double types</em> was <a href="https://forums.swift.org/t/se-0307-allow-interchangeable-use-of-cgfloat-and-double-types/45756">accepted</a></p>
<blockquote>
<p>After careful consideration of the thoughtful discussion during the review and pitch threads, the Core Team has decided to accept SE-0307. The Core Team recognizes this was a divisive topic.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0300</a> <em>Continuations for interfacing with async</em> was <a href="https://forums.swift.org/t/accepted-se-0300-continuations-for-interfacing-with-async/47046">accepted</a></p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0300-third-review-continuations-for-interfacing-async-tasks-with-synchronous-code/45245">third review</a> of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0300</a> has concluded. Feedback in the third round of review was positive. The proposal is <em>accepted</em> with some minor clarifications (<a href="https://github.com/apple/swift-evolution/commit/69cfc17651e35a8ac8a6e1480de0443a1fea89d8">diff</a>).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a> <em>Extend Property Wrappers to Function and Closure Parameters</em> was <a href="https://forums.swift.org/t/accepted-se-0293-extend-property-wrappers-to-function-and-closure-parameters/47030">accepted</a></p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0293-third-review-extend-property-wrappers-to-function-and-closure-parameters/46827">third review</a> of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a> has concluded. Feedback in the third round of review was quite positive, a result of the great iteration from the previous rounds of proposal. As such, the core team has accepted the proposal as written.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a> <em>Sendable and @Sendable closures</em> was <a href="https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786">accepted</a></p>
<blockquote>
<p>Feedback in the second round of review was generally positive. There was a fair amount of discussion about the new names, and people seemed to generally approve of the name Sendable for the protocol. Consensus was weaker about the name @sendable for the function-type attribute.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md">SE-0298</a> <em>Async/Await: Sequences</em> <a href="https://forums.swift.org/t/amendment-se-0298-async-await-sequences/47038">amendment accepted</a></p>
<blockquote>
<p>The Core Team has accepted an <a href="https://github.com/apple/swift-evolution/pull/1312">amendment</a> to <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md">SE-0298</a> that clarifies the end-of-iteration behavior.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> <em>Package Manager Extensible Build Tools</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640">returned for revision</a></p>
<blockquote>
<p>The feedback to idea of extending SwiftPM with plugins, the concrete design of the plugin system, and the tradeoffs the design make was very positive. Both authors and users of potential future plugins have provided input that the proposed design would work in real-world use cases, and that today require solutions outside of SwiftPM. However, there were a number of ideas that came up during the review that the core team feels would be good to adopt.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md">SE-0304</a> <em>(2nd review): Structured Concurrency</em> is <a href="https://forums.swift.org/t/se-0304-2nd-review-structured-concurrency/47217">under review</a></p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/se-0304-structured-concurrency/">first review</a> received largely positive comment, but led to a number of revisions, particularly regarding naming of methods. You can find a diff for the revision <a href="https://github.com/apple/swift-evolution/compare/9b5e0cbd552b4c8b570aedcb94c0cb72b9f591b0..309f60fcb4f0ad4e1412adb1d0ee9ccaad0419c1#diff-6e3f26a7c1e2c41a13bcf34ef4c7d84625339b2898702f5e0bed0d6e05f1a778">here</a>.</p>
<p>This review is part of the large <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">concurrency feature</a>, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its own merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0308-postfix-if-config-expressions.md">SE-0308</a> <em><code class="language-plaintext highlighter-rouge">#if</code> for postfix member expressions</em> is <a href="https://forums.swift.org/t/se-0308-if-for-postfix-member-expressions/47163/2">under review</a></p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md">SE-0292</a> <em>Package Registry Service</em> <a href="https://forums.swift.org/t/se-0292-2nd-review-package-registry-service/46917">under 2nd review</a></p>
<blockquote>
<p>Based on the feedback from the <a href="https://forums.swift.org/t/se-0292-package-registry-service/">first review</a>, the core team feels confident that the ideas behind Package Registry Service are useful and put the Swift packages ecosystem on the right path. One key area the core team asked to further explore in response to the first review, was the nature of the package identifiers given their potential utility in addressing Swift module name conflicts.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>As always, there are lots of pitches going on. Here are some that peaked my interest:</p>
<ul>
<li><a href="https://forums.swift.org/t/concurrency-yieldingcontinuation/47126">[Concurrency] YieldingContinuation</a></li>
<li><a href="https://forums.swift.org/t/pitch-conformance-builders/46980">[Pitch] Conformance Builders</a></li>
<li><a href="https://forums.swift.org/t/pitch-introduce-let-else-syntax-as-alternative-for-single-expression-guard-let-else/46989">[Pitch] Introduce <code class="language-plaintext highlighter-rouge">let-else</code> syntax as alternative for single expression <code class="language-plaintext highlighter-rouge">guard-let-else</code></a></li>
<li><a href="https://forums.swift.org/t/access-control-for-enum-cases/47142">Access control for enum cases</a></li>
<li><a href="https://forums.swift.org/t/allowing-unknown-in-arbitrarily-nested-patterns/47224">Allowing @unknown in arbitrarily nested patterns</a></li>
</ul>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://forums.swift.org/t/schrodingers-variables/47108">Schrödinger’s Variables</a></li>
<li><a href="https://twitter.com/AirspeedSwift/status/1377319786833707009">Structured programming was introduced as a better alternative to use of goths</a></li>
</ul>
Issue #181
https://swiftweeklybrief.com/issue-181
2021-03-25T00:00:00-07:00
2021-03-25T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>We have a fantastic new domain: <a href="https://swiftweeklybrief.com/">swiftweeklybrief.com</a>. 🎉</p>
<p>I would like to personally thank <a href="https://twitter.com/AppForce1">Jeroen Leenarts</a> for his tremendous help with the new email marketing platform.</p>
<p>This month is also an opportunity to celebrate the amazing women in our community. <a href="https://twitter.com/hollyborla/">Holly Borla</a>, a lead member of the <a href="https://swift.org/diversity/#community-groups">Diversity in Swift</a> work group, highlights many prominent contributers <a href="https://swift.org/blog/womens-history-month/">on the Swift.org blog</a>. If you’d like to get involved, please message <a href="https://forums.swift.org/new-message?groupname=diversity-work-group&title=Join+Community+Group&body=1.+Which+community+group(s)+would+you+like+to+join%0D%0A2.+What+support+do+you+hope+to+get+out+of+this+community+group">@diversity-work-group</a> on the Swift Forums.</p>
<p>We’re glad to say that the <em>Actors</em> proposal is now <a href="https://forums.swift.org/t/se-0306-actors/45734">under review</a>. Some vast improvements are coming to Swift later this year!</p>
<p>There are so many <a href="https://forums.swift.org/tag/gsoc-2021">great pitches</a> for this year’s <a href="https://summerofcode.withgoogle.com">Google Summer of Code</a> for the Swift language. Some of these pitches will be implemented by university students over the summer.</p>
<p>Thank you, everyone, for reading and supporting this project!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://gumroad.com/l/leaddeveloper/SwiftWeeklyBrief" target="_blank">eBook: Lead Software Developer</a></h4>
<p>Be the best lead software developer you can be. Learn best practices for being a great lead software developer. In this book Jeroen will provide you with best practices and tools to be the best lead developer you can be. For yourself, your peers and the business leaders you are working with.</p>
<p><small><a href="https://gumroad.com/l/leaddeveloper/SwiftWeeklyBrief" target="_blank">https://gumroad.com/l/leaddeveloper/SwiftWeeklyBrief</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/racer_girl27">Nicole Jacque</a> <a href="https://forums.swift.org/t/swift-5-5-release-process/45644">shared</a> the release process and estimated schedule for Swift 5.5.</p>
<p><a href="https://twitter.com/hollyborla/">Holly Borla</a> and <a href="https://twitter.com/twostraws">Paul Hudson</a> wrote <a href="https://swift.org/blog/womens-history-month/">a blog post</a> celebrating Women’s History Month.</p>
<p>Great Twitter <a href="https://twitter.com/airspeedswift/status/1372912670542757891?s=21">thread</a> about how to initialize an array and what effects this has during compile time.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/cachemeifyoucan">Steven Wu</a> merged <a href="https://github.com/apple/swift/pull/36520">a pull request</a> that emits diagnostics and errors out when swift-api-extract fails to load a module. This PR resolves <a href="https://bugs.swift.org/browse/SR-14311">SR-14311</a>.</p>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> merged <a href="https://github.com/apple/swift/pull/36521">a pull request</a> that reworks the dependencies between property wrapper requests.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a>: <em>Sendable and <code class="language-plaintext highlighter-rouge">@Sendable</code> closures</em> was <a href="https://forums.swift.org/t/accepted-se-0302-sendable-and-sendable-closures/45786">accepted with modifications</a>.</p>
<blockquote>
<p>Feedback in the second round of review was generally positive. There was a fair amount of discussion about the new names, and people seemed to generally approve of the name <code class="language-plaintext highlighter-rouge">Sendable</code> for the protocol. Consensus was weaker about the name <code class="language-plaintext highlighter-rouge">@sendable</code> for the function-type attribute; the Core Team discussed this and decided to steal an idea from <a href="https://forums.swift.org/t/pitch-4-concurrentvalue-and-concurrent-closures-evolution-pitches/44446/4">Matthew Johnson</a> and <a href="https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253/62">rename the attribute to <code class="language-plaintext highlighter-rouge">@Sendable</code></a>. This name better emphasizes the core idea of the attribute (that so-modified function values have to conform to <code class="language-plaintext highlighter-rouge">Sendable</code>, and thus their captures must, too), and it also aligns with an interesting future direction (to allow similar protocol-based constraints on specific function types). The review was briefly extended, and feedback on that rename was strongly positive.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0226-package-manager-target-based-dep-resolution.md">SE-0226</a>: <em>Package Manager Target Based Dependency Resolution</em> amendment was <a href="https://forums.swift.org/t/accepted-se-0226-amendment-package-manager-target-based-dependency-resolution/46636">accepted</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0295-codable-synthesis-for-enums-with-associated-values.md">SE-0295</a>: <em>Codable Synthesis for enums with Associated Values</em> was <a href="https://forums.swift.org/t/accepted-se-0295-codable-synthesis-for-enums-with-associated-values/46851">accepted</a>.</p>
<blockquote>
<p>There was general consensus that the solution would help a number of users, even if the encoding was not unanimously agreed upon. The core team does not believe that <code class="language-plaintext highlighter-rouge">Codable</code> represents the complete solution for the needs of serialization. There is a new <a href="https://forums.swift.org/t/serialization-in-swift">thread</a> which discusses the various requirements of the serialization solution in Swift.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0303-swiftpm-extensible-build-tools.md">SE-0303</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0303-package-manager-extensible-build-tools/46640">returned for revision</a>.</p>
<blockquote>
<p>The feedback to idea of extending SwiftPM with plugins, the concrete design of the plugin system, and the tradeoffs the design make was very positive. Both authors and users of potential future plugins have provided input that the proposed design would work in real-world use cases, and that today require solutions outside of SwiftPM. However, there were a number of ideas that came up during the review that the core team feels would be good to adopt.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0305-swiftpm-binary-target-improvements.md">SE-0305</a>: <em>Package Manager Binary Target Improvements</em> is <a href="https://forums.swift.org/t/se-0305-package-manager-binary-target-improvements/45589">under review</a>.</p>
<blockquote>
<p>This proposal extends SwiftPM binary targets to also support other kinds of prebuilt artifacts, such as command line tools. It does not in and of itself add support for non-Darwin binary libraries, although the proposed improvements could be a step towards such support.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0306-actors.md">SE-0306</a>: <em>Actors</em> is <a href="https://forums.swift.org/t/se-0306-actors/45734">under review</a>.</p>
<blockquote>
<p>This review is part of the large <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">concurrency feature</a>, which we are reviewing in several parts. While we’ve tried to make it independent of other concurrency proposals that have not yet been reviewed, it may have some dependencies that we’ve failed to eliminate. Please do your best to review it on its own merits, while still understanding its relationship to the larger feature. You may also want to raise interactions with previous already-accepted proposals – that might lead to opening up a separate thread of further discussion to keep the review focused.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0307-allow-interchangeable-use-of-double-cgfloat-types.md">SE-0307</a>: <em>Allow interchangeable use of CGFloat and Double types</em> is <a href="https://forums.swift.org/t/se-0307-allow-interchangeable-use-of-cgfloat-and-double-types/45756">under a review</a>.</p>
<blockquote>
<p>I propose to extend the language and allow Double and CGFloat types to be used interchangeably by means of transparently converting one type into the other as a sort of retroactive typealias between these two types. This is a <em>narrowly</em> defined implicit conversion intended to be part of the <em>existing family</em> of implicit conversions (including NSType <=> CFType conversions) supported by Swift to strengthen Objective-C and Swift interoperability. The only difference between the proposed conversion and existing ones is related to the fact that interchangeability implies both narrowing conversion (<code class="language-plaintext highlighter-rouge">Double</code> -> <code class="language-plaintext highlighter-rouge">CGFloat</code>) and widening one (<code class="language-plaintext highlighter-rouge">CGFloat</code> -> <code class="language-plaintext highlighter-rouge">Double</code>) on 32-bit platforms. This proposal is not about generalizing support for implicit conversions to the language.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/pitch-allow-interchangeable-use-of-cgfloat-and-double-types/45324">Discussion thread topic for that proposal</a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a>: <em>Extend Property Wrappers to Function and Closure Parametersors</em> is <a href="https://forums.swift.org/t/se-0293-third-review-extend-property-wrappers-to-function-and-closure-parameters/46827">under a third review</a>.</p>
<blockquote>
<p>Property Wrappers were <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md">introduced in Swift 5.1</a>, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending <em>where</em> property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/pitch-global-actors/45706">shared</a> a <a href="https://github.com/DougGregor/swift-evolution/blob/global-actors/proposals/nnnn-global-actors.md">draft proposal for global actors 139</a>.</p>
<blockquote>
<p>Global actors use the same actor-isolation model from the main proposal, but allow us to state that various functions and types scattered throughout the program will nonetheless need to be synchronized through one, global, actor. This is particularly important for allowing us to model the main thread as an actor.</p>
</blockquote>
<p><a href="https://twitter.com/johannesweiss/">Johannes Weiss</a> pitched <a href="https://forums.swift.org/t/pitch-introduce-module-to-get-the-current-module-name/45806">a proposal</a> to introduce <code class="language-plaintext highlighter-rouge">#module</code> to get the current module name.</p>
<blockquote>
<p>Currently Swift has a number <a href="https://github.com/apple/swift/blob/a73a8087968f9111149073107c5242d83635107a/include/swift/AST/MagicIdentifierKinds.def">“magic identifiers”</a>: <code class="language-plaintext highlighter-rouge">#fileID</code>, <code class="language-plaintext highlighter-rouge">#file</code>, <code class="language-plaintext highlighter-rouge">#filePath</code>, <code class="language-plaintext highlighter-rouge">#file</code>, <code class="language-plaintext highlighter-rouge">#function</code>, <code class="language-plaintext highlighter-rouge">#line</code>, <code class="language-plaintext highlighter-rouge">#column</code>, and <code class="language-plaintext highlighter-rouge">#dsohandle</code> which are extremely useful, for example for debugging and <a href="https://github.com/apple/swift-log/blob/main/Sources/Logging/Logging.swift#L73-L74">logging</a>.</p>
<p>In log output, it’s a common practise to output the filename (and sometimes the line number) where the log message was emitted from. In most cases however, only the basename of a file is logged, ie. if a log messages originates from <code class="language-plaintext highlighter-rouge">/Users/me/MyProject/Sources/MyModule/MySubfolder/BestFile.swift</code>, then commonly only the “basename” <code class="language-plaintext highlighter-rouge">BestFile.swift</code> is logged because the full paths can become very long.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/cdcarter">Christian Carter</a> started <a href="https://forums.swift.org/t/using-swift-corelibs-foundation-on-mac-os/46651">a discussion</a> about <code class="language-plaintext highlighter-rouge">swift-corelibs-foundation</code> on Mac OS.</p>
<h3 id="finally">Finally</h3>
<p>Happy <a href="https://twitter.com/jckarter/status/1372298143505653764">St. Patrick’s Day</a> ☘️</p>
Issue #180
https://swiftweeklybrief.com/issue-180
2021-03-11T00:00:00-08:00
2021-03-11T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Another two weeks have passed in the blink of an eye. I’ve been busy launching my new project into the wild, listening to critical feedback from early users, and doing my best to improve it.</p>
<p><a href="https://twitter.com/AppForce1">Jeroen Leenarts</a> and I teamed up to improve the mailing list platform we’re using to send out this newsletter, and hopefully to cut costs. This week is the first real test. If this email finds your mailbox, then we know it’s working. :)</p>
<p>I want to thank all the supporters, sponsors and everyone in the Swift community who help make this project happen. If you have any ideas about things to change, improve upon, or help <a href="https://swiftweeklybrief.com/sponsorship/">support this newsletter financially</a>, please <a href="mailto:fassko@gmail.com">let me know</a>.</p>
<p>Without further ado, we have some great news this time!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.keysmith.app?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_180" target="_blank">Keep your hands on the keyboard with Keysmith</a></h4>
<p>Keysmith is a native Mac app that makes it easy to create macros for your favorite apps and websites. Hit record and do your thing - Keysmith detects buttons, lists, and page loads automatically. Advanced features like AppleScript support, macro repetition, and Cyborg Mode make Keysmith a well-loved Mac power user tool. Try it for free with no time limit, up to 5 macros at a time.</p>
<p><small><a href="https://www.keysmith.app?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_180" target="_blank">www.keysmith.app</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://swiftbysundell.com/podcast/92/">episode 92</a> of the Swift by Sundell podcast, <a href="https://twitter.com/k__mahar">Kaitlin Mahar</a> joins <a href="https://twitter.com/johnsundell">John Sundell</a> to discuss the current state of server-side Swift, designing APIs for server-side libraries, and Swift’s upcoming suite of structured concurrency features.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/o_aberration">Adam Fowler</a> wrote <a href="https://opticalaberration.com/2021/02/hummingbird.html">a blog post</a> about <a href="https://github.com/hummingbird-project/hummingbird">Hummingbird</a>: A Swift HTTP server framework. Hummingbird is a lightweight, flexible server framework. It is split into three sections: HummingbirdCore, the HTTP server; Hummingbird, the web application framework; and finally the extension modules.</p>
<p><a href="https://twitter.com/davedelong">Dave DeLong</a> wrote <a href="https://davedelong.com/blog/2021/03/04/exploiting-string-interpolation-for-fun-and-for-profit/">a great article</a> talking about exploiting String interpolation for fun and profit.</p>
<p><a href="https://twitter.com/tiborbodecs">Tibor Bödecs</a> wrote <a href="https://theswiftdev.com/memory-layout-in-swift/">an article</a> explaining memory layout in Swift.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/36109">a pull request</a> that adds a new algorithm for identifying redundant non-same-type requirements.</p>
<p><a href="https://twitter.com/call1cc">Kavon Farvardin</a> merged <a href="https://github.com/apple/swift/pull/35965">a pull request</a> that allows <code class="language-plaintext highlighter-rouge">get</code> access to properties from outside the actor.</p>
<p><a href="https://twitter.com/vguerra">Victor Guerra</a> merged <a href="https://github.com/apple/swift/pull/36128">a pull request</a> that improves diagnostics for when a registered derivative function differs from the function it derived from.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://forums.swift.org/t/se-0299-second-review-extending-static-member-lookup-in-generic-contexts/44565">SE-0299</a>: <em>Extending Static Member Lookup in Generic Contexts</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0299-extending-static-member-lookup-in-generic-contexts/45238">accepted with modifications</a>.</p>
<blockquote>
<p>The second review period for <a href="https://forums.swift.org/t/se-0299-second-review-extending-static-member-lookup-in-generic-contexts/44565">SE-0299: Extending Static Member Lookup in Generic Contexts</a> has concluded. The core team has decided to <strong>accept</strong> this revision proposal, with one more modification suggested by John McCall:</p>
</blockquote>
<blockquote>
<p>I’m somewhat happy with the new restriction requiring a <code class="language-plaintext highlighter-rouge">Self</code> constraint, but I’m worried that making that unconditional is going to be unnecessarily limiting on the case where you’re just building a value of protocol type. Or does that not work because we don’t know what to bind <code class="language-plaintext highlighter-rouge">Self</code> to?</p>
<p>I would suggest the rule that the variable type / function return type should be required to be a subtype of the <code class="language-plaintext highlighter-rouge">Self</code> type.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0302-concurrentvalue-and-concurrent-closures/45251">returned for revision</a>.</p>
<blockquote>
<p>SE-0302 is <strong>accepted</strong> in its basic approach. It will be revised according to the above decisions, and the community will have an opportunity to review the result shortly. We ask that reviewers focus on just the changed aspects of the proposal, unless they feel that something important was missed in the first review.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0295-codable-synthesis-for-enums-with-associated-values.md">SE-0295</a>: <em>Codable synthesis for enums with associated values</em> is <a href="https://forums.swift.org/t/se-0295-codable-synthesis-for-enums-with-associated-values-third-review/45190">under a third review</a>.</p>
<blockquote>
<p>For the third review, the goal is not to re-litigate the entire proposal, but to focus on reviewing the additional details around the schema evolution. The updates for handling of certain overloaded enums and the choice to exclude certain enums from auto-synthesis due to evolution restrictions as specified in the proposal are also in scope.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a>: <em>Sendable and sendable closures</em> is <a href="https://forums.swift.org/t/se-0302-second-review-sendable-and-sendable-closures/45253">under a second review</a>.</p>
<blockquote>
<p>This is a narrow re-review, and reviewers should focus on the changes made in the first revision, which are described in the <a href="https://forums.swift.org/t/returned-for-revision-se-0302-concurrentvalue-and-concurrent-closures/45251">announcement post</a>. To briefly summarize them:</p>
<ul>
<li>The <code class="language-plaintext highlighter-rouge">@concurrent</code> function attribute is now named <code class="language-plaintext highlighter-rouge">@sendable</code>.</li>
<li>The <code class="language-plaintext highlighter-rouge">ConcurrentValue</code> protocol is now named <code class="language-plaintext highlighter-rouge">Sendable</code>.</li>
<li>The <code class="language-plaintext highlighter-rouge">UnsafeConcurrentValue</code> protocol no longer exists, but <code class="language-plaintext highlighter-rouge">Sendable</code> conformances may be explicitly decorated with <code class="language-plaintext highlighter-rouge">@unchecked</code>, e.g.</li>
</ul>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">class</span> <span class="kt">MyClass</span><span class="p">:</span> <span class="kd">@unchecked</span> <span class="kt">Sendable</span> <span class="p">{}</span>
</code></pre></div> </div>
<ul>
<li>Non-<code class="language-plaintext highlighter-rouge">public</code> <code class="language-plaintext highlighter-rouge">struct</code> and <code class="language-plaintext highlighter-rouge">enum</code> types now implicitly conform to <code class="language-plaintext highlighter-rouge">Sendable</code> if their stored properties and case payloads all conform.</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0300</a>: <em>Continuations for interfacing async tasks with synchronous code</em> is <a href="https://forums.swift.org/t/se-0300-third-review-continuations-for-interfacing-async-tasks-with-synchronous-code/45245">under a third review</a>.</p>
<blockquote>
<p>Following the <a href="https://forums.swift.org/t/se-0300-second-review-continuations-for-interfacing-async-tasks-with-synchronous-code/">second review</a> of this proposal, the core team feels that the proposal is close to acceptance, and is an important feature as part of Swift’s concurrency roadmap. However, a small number of amendments have been made based on feedback during the second review.</p>
<ul>
<li>Replaced separate <code class="language-plaintext highlighter-rouge">*Continuation<T></code> and <code class="language-plaintext highlighter-rouge">*ThrowingContinuation<T></code> types with a single <code class="language-plaintext highlighter-rouge">Continuation<T, E: Error></code> type parameterized on the error type.</li>
<li>Added a convenience <code class="language-plaintext highlighter-rouge">resume()</code> equivalent to <code class="language-plaintext highlighter-rouge">resume(returning: ())</code> for continuations with a <code class="language-plaintext highlighter-rouge">Void</code> return type.</li>
<li>Changed <code class="language-plaintext highlighter-rouge">with*ThrowingContinuation</code> to take an <code class="language-plaintext highlighter-rouge">operation</code> block that may throw, and to immediately resume the task throwing the error if an uncaught error propagates from the operation</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0304-structured-concurrency.md">SE-0304</a>: <em>Structured Concurrency</em> is <a href="https://forums.swift.org/t/se-0304-structured-concurrency/45314">under a review</a>.</p>
<blockquote>
<p><a href="https://github.com/DougGregor/swift-evolution/blob/async-await/proposals/nnnn-async-await.md"><code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code></a> is a language mechanism for writing natural, efficient asynchronous code. Asynchronous functions (introduced with <code class="language-plaintext highlighter-rouge">async</code>) can give up the thread on which they are executing at any given suspension point (marked with <code class="language-plaintext highlighter-rouge">await</code>), which is necessary for building highly-concurrent systems.</p>
<p>However, the <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code> proposal does not introduce concurrency <em>per se</em>: ignoring the suspension points within an asynchronous function, it will execute in essentially the same manner as a synchronous function. This proposal introduces support for <a href="https://en.wikipedia.org/wiki/Structured_concurrency">structured concurrency</a> in Swift, enabling concurrent execution of asynchronous code with a model that is ergonomic, predictable, and admits efficient implementation.</p>
<p>Swift-evolution threads:
<a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">Pitch #1</a>,
<a href="https://forums.swift.org/t/pitch-2-structured-concurrency/43452">Pitch #2</a>,
<a href="https://forums.swift.org/t/pitch-3-structured-concurrency/44496">Pitch #3</a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0226-package-manager-target-based-dep-resolution.md">SE-0226</a>: <em>Package Manager Target Based Dependency Resolution</em> <a href="https://github.com/apple/swift-evolution/pull/1278">amendment</a> is <a href="https://forums.swift.org/t/amendment-se-0226-package-manager-target-based-dependency-resolution/45552">under a review</a>.</p>
<blockquote>
<p>The <a href="https://github.com/apple/swift-evolution/pull/1278">amendment</a> goal is to address a usability issue introduced in the original design of target based dependencies and was discussed in a recent <a href="https://forums.swift.org/t/pitch-simplifying-target-based-dependencies-syntax/45102">pitch thread</a> on the topic.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/pitch-4-actors/45215">updated us</a> about changes to the <a href="https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md">actors proposal</a>.</p>
<blockquote>
<ul>
<li>Allow cross-actor references to actor properties, so long as they are reads (not writes or inout references)
Added isolated parameters, to generalize the previously-special behavior of self in an actor and make the semantics of nonisolated more clear.</li>
<li>Limit nonisolated(unsafe) to stored instance properties. The prior definition was far too broad.</li>
<li>Clarify that super is isolated if self is.</li>
<li>Prohibit references to actor-isolated declarations in key paths.</li>
<li>Clarify the behavior of partial applications.</li>
<li>Added a “future directions” section describing isolated protocol conformances.</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/sherlouk">James Sherlock</a> pitched <a href="https://forums.swift.org/t/pitch-swift-package-access-control/45174">an idea</a> for how the Swift language could be evolved to add a new access control keyword designed for use in Swift Packages.</p>
<blockquote>
<p>Swift currently has a handful of access control modifiers, namely: <code class="language-plaintext highlighter-rouge">open public internal private fileprivate</code>. These keywords change the visibility of parts of our code to change what other parts of our codebase have access to said code.</p>
<p>Swift Packages define targets which are groups of code. Targets can depend on other targets, and multiple targets can be combined to create a product. A product can be a dependency of another application or package.</p>
</blockquote>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> started <a href="https://forums.swift.org/t/formalizing-swift-generics-as-a-term-rewriting-system/45175">a discussion</a> about formalizing Swift generics as a term rewriting system.</p>
<blockquote>
<p>Previously I wrote about how the full generality of <a href="https://forums.swift.org/t/swift-type-checking-is-undecidable/39024">the Swift generic system is undecidable</a>. The basic idea is that “finitely-presented monoids” can be written as a Swift protocol where the “word problem” on the monoid reduces to proving an equivalence between two types. Since the word problem is known to be undecidable, this shows that Swift generics (as currently defined) are undecidable.</p>
</blockquote>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> pitched the <a href="https://github.com/vapor/multipart-kit">MultipartKit</a> to the SSWG. MultipartKit is a Swift library for encoding and decoding multipart form data based on SwiftNIO. It contains a C library used for the actual parsing of the request data and a Swift wrapper to integrate the C library with SwiftNIO.</p>
<blockquote>
<p>Multipart is a popular mechanism for sending data to servers, especially when doing file uploads. It’s supported by both browsers and HTTP libraries and we feel that having a Swift implementation in the SSWG is an important step for the ecosystem.</p>
<p>MultipartKit was originally built into Vapor for the release of Vapor 4 with the intention of splitting it out at a later date and pitching it to the SSWG so here we are! Since the implementation has been used in Vapor 4 it’s fairly well battle tested and deployed.</p>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> posted the Swift on the Server Workgroup <a href="https://forums.swift.org/t/jan-20th-2020/45276">Jan 20th, 2020 meeting</a> notes.</p>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> pitched <a href="https://forums.swift.org/t/pitch-allow-interchangeable-use-of-cgfloat-and-double-types/45324">an idea</a> to allow interchangeable use of <code class="language-plaintext highlighter-rouge">CGFloat</code> and <code class="language-plaintext highlighter-rouge">Double</code> types.</p>
<blockquote>
<p>When Swift was first released, the type of <code class="language-plaintext highlighter-rouge">CGFloat</code> presented a challenge. At the time, most iOS devices were still 32-bit. SDKs such as CoreGraphics provided APIs that took 32-bit floating point values on 32-bit platforms, and 64-bit values on 64-bit platforms. When these APIs were first introduced, 32-bit scalar arithmetic was faster on 32-bit platforms, but by the time of Swift’s release, this was no longer true: then, as today, 64-bit scalar arithmetic was just as fast as 32-bit even on 32-bit platforms (albeit with higher memory overhead). But the 32/64-bit split remained, mostly for source and ABI stability reasons.</p>
</blockquote>
<p><a href="https://twitter.com/tim_vermeulen">Tim Vermeulen</a> pitched <a href="https://forums.swift.org/t/pitch-efficient-collection-startindex-throughout-the-standard-library/45317">an idea</a> about efficient <code class="language-plaintext highlighter-rouge">Collection.startIndex</code> throughout the standard library.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">Collection.startIndex</code> is <a href="https://github.com/apple/swift/blob/main/stdlib/public/core/Collection.swift#L322-L329">expected</a> to be an O(1) operation, but some collections in the standard library deviate from this, which can lead to unpredictable performance. We should change these collections to properly meet this O(1) performance expectation, by doing any expensive work needed to reach the first element ahead of time, in the collection’s initializer.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> informed us again about more revisions to the <a href="https://forums.swift.org/t/pitch-6-actors/45519">Actors</a> proposal.</p>
<blockquote>
<p>After yet more interesting discussion in <a href="https://forums.swift.org/t/pitch-4-actors/45215">pitch #4 (and 5)</a>, we’ve revised the <a href="https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md">actor proposal</a> for this, pitch #6, addressing more feedback.</p>
<p>Changes in the sixth pitch:</p>
<ul>
<li>Make the instance requirements of <code class="language-plaintext highlighter-rouge">Actor</code> protocols actor-isolated to <code class="language-plaintext highlighter-rouge">self</code> , and allow actor types to conform to such protocols using actor-isolated witnesses.</li>
<li>Reflow the “Proposed Solution” section to get the bigger ideas out earlier.</li>
<li>Remove <code class="language-plaintext highlighter-rouge">nonisolated(unsafe)</code>.</li>
</ul>
</blockquote>
<p>Gwendal Roué pitched <a href="https://forums.swift.org/t/pitch-scoped-functions/45486">a proposal</a> about introducing scoped functions.</p>
<blockquote>
<p>Scoped Functions are functions that enhance the leading dot syntax inside their body, so that it gives short-hand access to the members of a specific value. Such functions exist so that API designers and their consumers can collaborate towards a way to write focused code where an agreed implicit and obvious context does not have to be spelled out.</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched an idea to codify end-of-iteration behavior for <code class="language-plaintext highlighter-rouge">AsyncSequence</code> and its iterators to match the existing <code class="language-plaintext highlighter-rouge">Sequence</code> protocol.</p>
<blockquote>
<p>The recent <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md">proposal for asynchronous sequences</a> left open a question about how asynchronous iterators must behave when reaching the end of their elements. We should amend the proposal to clarify that after returning <code class="language-plaintext highlighter-rouge">nil</code> or throwing an error from an iterator’s <code class="language-plaintext highlighter-rouge">next()</code> method, all subsequent calls to <code class="language-plaintext highlighter-rouge">next()</code> must return <code class="language-plaintext highlighter-rouge">nil</code>.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/IanKay/status/1367523396272058368">fatalError(“this should never happen”)</a></p>
Issue #179
https://swiftweeklybrief.com/issue-179
2021-02-25T00:00:00-08:00
2021-02-25T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>This month we are <a href="https://swift.org/blog/black-history-month/">celebrating</a> Black History Month, which makes this a good time to recognize those Swift community members who have had a tremendous impact on all of us. I want to thank them and everyone else who enriches and moves our community forward.</p>
<p>It’s sad to see that <a href="https://github.com/tensorflow/swift">Swift for TensorFlow</a> has been archived. On a positive note, the project shows us that Swift can be used for advanced experiments in machine learning.</p>
<p>Lately, I have been enjoying discussions on <a href="https://www.joinclubhouse.com">Clubhouse</a>, the drop-in audio chat app. There is already a large Swift community putting on events like Ladies Who Code, daily get-togethers, interview coaching, even teaching Swift — thanks to <a href="https://twitter.com/stephanielatte_">Stephanie Chiu</a>, <a href="https://twitter.com/Teekachu1">Ting Becker</a>, <a href="https://twitter.com/vivianphung">Vivian Phung</a>, <a href="https://twitter.com/twostraws">Paul Hudson</a>, and <a href="https://twitter.com/mecid">Majid Jabrayilov</a> for setting up some of these rooms.</p>
<p>We still have several <a href="/sponsorship">sponsorship slots</a> available. Please reach out to me <a href="mailto:fassko@gmail.com">through email</a>, or <a href="https://twitter.com/swiftlybrief">say hello on Twitter</a>.</p>
<p>Thank you. Now it’s time for the news!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14221">SR-14221</a> [Compiler] Add tricky parsing test case.</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> and <a href="https://twitter.com/krstnfx/">Kristina Fox
</a> wrote an <a href="https://swift.org/blog/black-history-month/">excellent article</a> celebrating Black History Month. They have curated a handful of outstanding contributions from the Black Swift community to acknowledge and celebrate their impact on the Swift ecosystem.</p>
<p>The Swift language has been included in the <a href="https://summerofcode.withgoogle.com/">Google Summer of Code</a> this year again. The program is currently collecting ideas, matching them with mentors, and slowly putting them up on the (work in progress) <a href="https://swift.org/gsoc2021/">Swift.org - Project Ideas for GSoC 2021</a> site.</p>
<p>Robert Pieta shared a great <a href="https://www.advancedswift.com/typealias-examples/">article</a> explaining variable, tuple, closure, and generic typealias in Swift.</p>
<p><a href="https://twitter.com/tiborbodecs">Tibor Bödecs</a> wrote <a href="https://theswiftdev.com/the-swift-compiler-for-beginners/">an article explaining the Swift compiler for beginners</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/LucianoPAlmeida">Luciano Almeida</a> merged <a href="https://github.com/apple/swift/pull/36076">a pull request</a> that implements a rule on ranking where overload choices that have <code class="language-plaintext highlighter-rouge">@autoclosure</code> parameters are disfavored over the ones that aren’t to avoid ambiguity and resolves <a href="https://bugs.swift.org/browse/SR-2705">SR-2705</a>.</p>
<p><a href="https://github.com/ktoso">Konrad Malawski</a> merged <a href="https://github.com/apple/swift/pull/36032">a pull request</a> that implements <code class="language-plaintext highlighter-rouge">withCancellationHandler</code>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0301-package-editing-commands.md">SE-0301</a>: <em>Package Editor Commands</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318](https://forums.swift.org/t/accepted-with-modification-se-0301-package-editor-commands/45069)">accepted with modifications</a>.</p>
<blockquote>
<p>The feedback from the <a href="https://forums.swift.org/t/pitch-package-editor-commands/">pitch</a> and <a href="https://forums.swift.org/t/se-0301-package-editor-commands/">review</a> has been enthusiastically positive and the proposal has been accepted with a few minor revisions:</p>
<ol>
<li>Change comma delimited arguments to space delimited.</li>
<li>Add <code class="language-plaintext highlighter-rouge">—to</code> and <code class="language-plaintext highlighter-rouge">—through</code> flags to <code class="language-plaintext highlighter-rouge">add-dependency</code> command.</li>
<li>Add information in the “alternatives considered” about alternative command spelling and their tradeoffs.</li>
</ol>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a> has been <a href="https://forums.swift.org/t/returned-for-revision-2-se-0293-extend-property-wrappers-to-function-and-closure-parameters/44832">returned for revision</a>.</p>
<blockquote>
<p>The improvements from the first draft are significant and addressed all of the concerns from the first round of core team feedback. Community feedback was very positive, including a number of useful discussions and clarifications. While the proposal is very close, the core team would like more exploration of one specific topic: protocol conformance with property wrappers.</p>
<p>The core team feels that property wrappers on functions should compose (somehow) with protocol requirements. The overall model explained in the proposal is that the exposed function type does not have the wrappers on it. One approach would be to be consistent with that where implementations with wrappers on them would fulfill the projected types, an alternate approach would allow fulfilling requirements with the wrapped types. Either way, the core team feels that this should be defined as part of the proposal.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0291</a>: <em>Package Collection Signing</em> is <a href="https://forums.swift.org/t/amendment-se-0291-package-collection-signing/44887">under a review</a>.</p>
<blockquote>
<p>The <a href="https://github.com/apple/swift-evolution/pull/1270">amendment</a> was requested by the core team to reflect the security model for package collections as discusses in a recent <a href="https://forums.swift.org/t/package-collection-signing/">discussion thread</a> on the topic. The goal of the amendment is to provide transparency and document that security model.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0302-concurrent-value-and-concurrent-closures.md">SE-0302</a>: <em>ConcurrentValue and <code class="language-plaintext highlighter-rouge">@concurrent</code> closures</em> is <a href="https://forums.swift.org/t/se-0302-concurrentvalue-and-concurrent-closures/44919">under a review</a>.</p>
<blockquote>
<p>The <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611/">Swift Concurrency Roadmap</a> was recently announced, and a key goal of that roadmap is to “provide a mechanism for isolating state in concurrent programs to eliminate data races.” Such a mechanism will be a major progression for widely used programming languages — most of them provide concurrent programming abstractions in a way that subjects programmers to a wide range of bugs, including race conditions, deadlocks and other problems.</p>
<p>This proposal describes an approach to address one of the challenging problems in this space — how to type check value passing between structured concurrency constructs and actors messages. As such, this is a unifying theory that provides some of the underlying type system mechanics that make them both safe and work well together.</p>
<p>This implementation approach involves marker protocols named <code class="language-plaintext highlighter-rouge">ConcurrentValue</code> and <code class="language-plaintext highlighter-rouge">UnsafeConcurrentValue</code>, as well as a <code class="language-plaintext highlighter-rouge">@concurrent</code> attribute that may be applied to functions.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/zoecarver">Zoe Carver</a> <a href="https://forums.swift.org/t/a-short-term-roadmap-for-c-interop/44768">updated</a> the short-term roadmap for C++ interop.</p>
<blockquote>
<p>My primary goal over the next few months will be to fully import libc++ headers, LLVM headers, and Swift headers without crashing. This doesn’t mean we’ll necessarily be able to use any of these APIs, just that we’ll be able to load the headers without crashing or having other errors. Ideally, we won’t regress in terms of what C++ programs we can accept.</p>
<p>This should be mostly compiler bug fixes. However, there will be some larger projects, such as making all the headers we plan to use self-contained.</p>
</blockquote>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> <a href="https://forums.swift.org/t/pitch-4-se-0293-extend-property-wrappers-to-function-and-closure-parameters/44858">informed</a> us about updates to <a href="https://github.com/hborla/swift-evolution/blob/se-0293-revision-3/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a>.</p>
<blockquote>
<ul>
<li>The distinction between property wrappers that are API and property wrappers that are implementation detail is formalized via the <code class="language-plaintext highlighter-rouge">api</code> option in the <code class="language-plaintext highlighter-rouge">@propertyWrapper</code> attribute, i.e. <code class="language-plaintext highlighter-rouge">@propertyWrapper(api)</code></li>
<li>Implementation-detail property wrappers on parameters are sugar for a local wrapped variable.</li>
<li>API-level property wrappers on parameters use caller-side application of the property wrapper. The design of API-level property wrappers attached to parameters is the same as the previous revision of SE-0293.</li>
<li>Overload resolution for property wrapper initializers will always be done at the property wrapper declaration.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> pitched <a href="https://forums.swift.org/t/pitch-fix-rethrows-checking-and-add-rethrows-unsafe/44863">a proposal</a> that fixes a soundness hole in <code class="language-plaintext highlighter-rouge">rethrows</code> checking, and introduces a new <code class="language-plaintext highlighter-rouge">rethrows(unsafe)</code> escape hatch for situations where a function has the correct behavior at runtime, but the compiler is unable to prove that this is the case.</p>
<p><a href="https://forums.swift.org/u/abertelrud">Anders Bertelrud</a> pitched <a href="https://forums.swift.org/t/pitch-swiftpm-extensible-build-tools/44715">a proposal</a> to add SwiftPM Extensible build tools.</p>
<blockquote>
<p>Because extensibility is a broad topic and there are a wide variety of needs, this proposal takes the approach of:</p>
<ol>
<li>Providing a way for packages to implement extensions and letting them define the capabilities of those extensions</li>
<li>Providing a way for packages to vend extensions to other packages (or choose to keep them as a private implementation detail of the package)</li>
<li>Providing an initial set of extension capabilities that is narrowly focused on source generation and analysis, which seems to be one of the most common needs today</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/johannesweiss/">Johannes Weiss</a> shared Swift on the Server Workgroup <a href="https://forums.swift.org/t/january-6-2021/44908">January 6, 2021 meeting notes</a>.</p>
<p><a href="https://forums.swift.org/u/xwu">Xiaodi Wu</a> pitched <a href="https://forums.swift.org/t/exponentiation-operator-and-precedence-group/44895">a proposal</a> to add an exponentiation operator and precedence group.</p>
<blockquote>
<p>We propose the addition of <code class="language-plaintext highlighter-rouge">**</code> as the exponentiation operator, assigned to a precedence group named <code class="language-plaintext highlighter-rouge">ExponentiationPrecedence</code> that is higher than <code class="language-plaintext highlighter-rouge">MultiplicationPrecedence</code>.</p>
</blockquote>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> shared news from the Vapor team that they are <a href="https://forums.swift.org/t/vapor-branch-renaming/45017">renaming the default branch</a> and an update describing how they <a href="https://forums.swift.org/t/vapor-4-40-1-denial-of-service-vulnerability-in-the-metrics-integration/44985">found and fixed</a> a vulnerability in Vapor’s Swift Metrics integration.</p>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> informed us that <a href="https://forums.swift.org/u/filip-sakel">Filip Sakel</a> has revised the design of SE-0293 again, and the latest proposal draft is available <a href="https://github.com/hborla/swift-evolution/blob/se-0293-revision-3/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">here</a>.</p>
<blockquote>
<p>Here is a list of changes to the design in this revision (compared to the last reviewed version):</p>
<ul>
<li>The distinction between API wrappers and implementation-detail wrappers is formalized, and determined by the compiler based on whether the property wrapper type allows the call-site to pass a different type of argument.</li>
<li>Implementation-detail property wrappers on parameters are sugar for a local wrapped variable.</li>
<li>API property wrappers on parameters use caller-side application of the property wrapper.</li>
<li>Overload resolution for property wrapper initializers will always be done at the property wrapper declaration to minimize the semantic differences between the two property wrapper models.</li>
</ul>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li><a href="https://twitter.com/jckarter/status/1359983768488955904"><code class="language-plaintext highlighter-rouge">then</code></a></li>
<li><a href="https://twitter.com/gregheo/status/1361589553463664640">souiphte</a></li>
</ul>
Issue #178
https://swiftweeklybrief.com/issue-178
2021-02-11T00:00:00-08:00
2021-02-11T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks passed by so quickly! I’ve been busy with a new project, launching this week, and I’ve been exploring SwiftUI 2 new features like <code class="language-plaintext highlighter-rouge">LazyVStack</code>, <code class="language-plaintext highlighter-rouge">LazyHGrid</code>, <code class="language-plaintext highlighter-rouge">@StateObject</code> and more. So far, I love it a lot.</p>
<p>In the interim, Apple released Xcode 12.5 Beta, which includes many important additions and fixes for the Swift language. We still need to wait a little longer for <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code>, but it’s getting closer.</p>
<p>As always, thank you for supporting this newsletter. We are looking for all kinds of assistance - <a href="/sponsorship/">financial</a>, putting together new issues, or <a href="https://github.com/SwiftWeekly/.github/blob/master/CONTRIBUTING.md">contributing</a> to improve the site. If there’s something you think you can do, we’d love to hear from you.</p>
<p>Now, straight to the news!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://duckduckgo.applytojob.com/apply/oEuc5CypGM?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_178" target="_blank">DuckDuckGo is Hiring iOS Mobile Developers</a></h4>
<p>DuckDuckGo are on the hunt for senior iOS engineers to help shape the technology that powers the DuckDuckGo search experience. If you’re an engineer that enjoys the autonomy of leading projects and questioning the status quo this could be the perfect role for you. We’re a globally distributed team so regardless of where you’re based we’d love to hear from you.</p>
<p><small><a href="https://duckduckgo.applytojob.com/apply/oEuc5CypGM?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_178" target="_blank">duckduckgo.applytojob.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14137">SR-14137</a> [C++] Cache failed imports.</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-12_5-beta-release-notes#Swift">Xcode 12.5</a> Beta has been released with some new and notable Swift features and issues resolved.</p>
<p><a href="https://github.com/tomerd">Tomer Doron</a> announced <a href="https://forums.swift.org/t/announcing-swift-5-3-3-for-linux-and-windows/44258">Swift 5.3.3 for Linux and Windows</a>.</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> wrote <a href="https://www.hackingwithswift.com/articles/228/whats-new-in-swift-5-4">an article</a> explaining what’s new in Swift 5.4.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/atrick">Andrew Trick</a> merged <a href="https://github.com/apple/swift/pull/35677">a pull request</a> that adds <code class="language-plaintext highlighter-rouge">PhiOperand</code> and <code class="language-plaintext highlighter-rouge">PhiValue</code> types.</p>
<p><a href="https://github.com/adrian-prantl">Adrian Prantl</a> merged <a href="https://github.com/apple/swift/pull/35444">a pull request</a> that adds debug info support for boxed arguments in <code class="language-plaintext highlighter-rouge">async</code> functions and fixes <a href="https://bugs.swift.org/browse/SR-14059">SR-14059</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/35784">a pull request</a> that enables <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code> by default.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0299</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0299-extending-static-member-lookup-in-generic-contexts/44466">returned for revision</a>.</p>
<blockquote>
<p>The review period for <a href="https://forums.swift.org/t/se-0299-extending-static-member-lookup-in-generic-contexts/43958">SE-0299: Extending Static Member Lookup in Generic Contexts</a> has concluded. The core team has decided to <strong>return this proposal for revision</strong>. We agree that extending <code class="language-plaintext highlighter-rouge">.leadingDot</code> contextual member lookup to work in generic contexts fits well with the direction of Swift, and that extending it to find members from protocol extensions corresponding to constraints on the generic context is a reasonable incremental expansion of the existing model. However, the core team is concerned about the potential for namespace pollution when using this new feature as exemplified in the proposal, an issue the review discussion also raised concerns about, and would like to see the proposal revised to address this concern.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0295-codable-synthesis-for-enums-with-associated-values.md">SE-0295</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0295-codable-synthesis-for-enums-with-associated-values/44653">returned for revision</a>.</p>
<blockquote>
<p>We agree that having a default <code class="language-plaintext highlighter-rouge">Coding</code> synthesis for <code class="language-plaintext highlighter-rouge">enum</code>s with payloads is valuable. Although the encoding may not be perfect for every use case, the default encoding is still valuable as it simplifies the cases where the encoding is sufficient. For the other use cases, the user is still able define the synthesis as they could previously.</p>
<p>Furthermore, the extensibility of <code class="language-plaintext highlighter-rouge">Codable</code> is beyond the scope of this proposal as is the “readability” of the serialization itself. The design choices of <code class="language-plaintext highlighter-rouge">Codable</code> are not grounds for preventing improvements to serialization in Swift.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0300</a>: <em>Continuations for interfacing async tasks with synchronous code</em> is <a href="https://forums.swift.org/t/se-0300-second-review-continuations-for-interfacing-async-tasks-with-synchronous-code/44366">under the second review</a>.</p>
<blockquote>
<p>Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event.
…
Following the <a href="https://forums.swift.org/t/se-0300-continuations-for-interfacing-async-tasks-with-synchronous-code/">first review</a> of this proposal, the core team feels that this is a good addition to the language, and is an important feature as part of Swift’s concurrency roadmap. However, a number of clarifications to the proposal resulted from the first review, and so a second review of this clarified proposal is being conducted.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0301-package-editing-commands.md">SE-0301</a>: <em>Package Editor Commands</em> is <a href="https://forums.swift.org/t/se-0301-package-editor-commands/44447">under a review</a>.</p>
<blockquote>
<p>Because Swift package manifests are written in Swift using the PackageDescription API, it is difficult to automate common tasks like adding a new product, target, or dependency. This proposal introduces new <code class="language-plaintext highlighter-rouge">swift package</code> subcommands to perform some common editing tasks which can streamline users’ workflows and enable new higher-level tools.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0299-extend-generic-static-member-lookup.md">SE-0299</a>: <em>Extending Static Member Lookup in Generic Contexts</em> is <a href="https://forums.swift.org/t/se-0299-second-review-extending-static-member-lookup-in-generic-contexts/44565">under the second review</a>.</p>
<blockquote>
<p>Using static member declarations to provide semantic names for commonly used values which can then be accessed via leading dot syntax is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of this syntax. This proposal aims to relax restrictions on accessing static members on protocols to afford the same call-site legibility to generic APIs.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/pitch-3-actors/44470">updated us</a> about about the third <strong>Actors</strong> pitch.</p>
<blockquote>
<p>After yet more interesting discussion in <a href="https://forums.swift.org/t/pitch-2-actors/44094">pitch #2</a>, we’ve revised the <a href="https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md">actor proposal</a> for this, pitch #3.</p>
<p>Changes in the third pitch:</p>
<ul>
<li>Narrow the proposal down to only support re-entrant actors. Capture several potential non-reentrant designs in the Alternatives Considered as possible future extensions.</li>
<li>Replaced <code class="language-plaintext highlighter-rouge">@actorIndependent</code> attribute with a <code class="language-plaintext highlighter-rouge">nonisolated</code> modifier, which follows the approach of <code class="language-plaintext highlighter-rouge">nonmutating</code> and ties in better with the “actor isolation” terminology (thank you to Xiaodi Wu for the suggestion).</li>
<li>Replaced “queue” terminology with the more traditional “mailbox” terminology, to try to help alleviate confusion with Dispatch queues.</li>
<li>Introduced “cross-actor reference” terminology and the requirement that cross-actor references always traffic in <code class="language-plaintext highlighter-rouge">ConcurrentValue</code> types. This goes along with the <a href="https://forums.swift.org/t/pitch-4-concurrentvalue-and-concurrent-closures-evolution-pitches/44446">latest pitch on <code class="language-plaintext highlighter-rouge">ConcurrentValue</code></a>.</li>
<li>Reference <code class="language-plaintext highlighter-rouge">@concurrent</code> function types from their separate proposal (which his the same proposal as <code class="language-plaintext highlighter-rouge">ConcurrentValue</code>).</li>
<li>Moved Objective-C interoperability into its own section.</li>
<li>Clarify the “class-like” behaviors of actor types, such as satisfying an <code class="language-plaintext highlighter-rouge">AnyObject</code> conformance.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> <a href="https://forums.swift.org/t/pitch-4-concurrentvalue-and-concurrent-closures-evolution-pitches/44446">pitched</a> the fourth draft of <strong>ConcurrentValue and <code class="language-plaintext highlighter-rouge">@concurrent</code> closures Evolution</strong>.</p>
<blockquote>
<p>Thank you for all the great feedback on the proposal. Doug and I have been iterating on it a bit and have a <a href="https://docs.google.com/document/d/1m2fLLq9_ArY1ySt108soxOZNX7XT0ixMlNLFK08789M/edit#">draft #4</a> up. My sense is that this is getting close to convergence for a formal review.</p>
</blockquote>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> pitched <a href="https://forums.swift.org/t/support-custom-executors-in-swift-concurrency/44425">an idea</a> to add support custom executors in Swift concurrency.</p>
<blockquote>
<p>It is sometimes important to control exactly how code is executed. This proposal lays out a system of custom executors which can schedule and run opaque jobs, and it describes how actors and tasks can be directed to run on a specific executor.</p>
<p>Motivation
Swift’s concurrency design is intentionally vague about the details of how code is actually run. Most code does not rely on specific properties of the execution environment, such as being run to a specific operating system thread, and instead needs only high-level semantic properties, such as that no other code will be accessing certain variables concurrently. Maintaining flexibility about how work is scheduled onto threads allows Swift to avoid certain performance pitfalls by default.</p>
</blockquote>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> <a href="https://forums.swift.org/t/pitch-3-structured-concurrency/44496">informed us</a> about another revision of the <a href="https://github.com/DougGregor/swift-evolution/blob/eb149799aac93b3fb84a97adb2bb3db47179a21b/proposals/nnnn-structured-concurrency.md">Structured Concurrency proposal</a>.</p>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> <a href="https://forums.swift.org/t/exploration-type-system-considerations-for-actor-proposal/44540">expressed</a> his <a href="https://docs.google.com/document/d/1rka0MkYMQ31EhtmCO-ZEHw1zar5M3ZzA6oBitcf-cYg/edit#">concerns</a> about the actor proposal.</p>
<p><a href="https://forums.swift.org/u/morten_bek_ditlevsen">Morten Bek Ditlevsen</a> pitched <a href="https://forums.swift.org/t/pitch-allow-coding-of-non-string-int-keyed-dictionary-into-a-keyedcontainer/44593">an idea</a> that solves an issue with the current state of <code class="language-plaintext highlighter-rouge">Dictionary</code> encoding and decoding.</p>
<blockquote>
<p>The current conformance of Swift’s <code class="language-plaintext highlighter-rouge">Dictionary</code> to the <code class="language-plaintext highlighter-rouge">Codable</code> protocols has a somewhat-surprising limitation in that dictionaries whose key type is not <code class="language-plaintext highlighter-rouge">String</code> or <code class="language-plaintext highlighter-rouge">Int</code> (values directly representable in <code class="language-plaintext highlighter-rouge">CodingKey</code> types) encode not as <code class="language-plaintext highlighter-rouge">KeyedContainer</code>s but as <code class="language-plaintext highlighter-rouge">UnkeyedContainer</code>s. This behavior has caused much confusion for users and I would like to offer a way to improve the situation.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/george">George</a> proposed <a href="https://forums.swift.org/t/new-de-en-codingcontainer-types-to-support-enums-with-associated-types-and-tuples/44647">a solution</a> for how to fix the issue of automatic <code class="language-plaintext highlighter-rouge">Codable</code> synthesis for enums with associated types.</p>
<blockquote>
<p>I think we can solve both of these issues by introducing four new codable container types: <code class="language-plaintext highlighter-rouge">Tagged{En,De}codingContainer<Tag></code>, and <code class="language-plaintext highlighter-rouge">Tuple{En,De}codingContainer<Tag></code>.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/stu_bot3000/status/1356921895883571200">Typical swifts</a>.</p>
Issue #177
https://swiftweeklybrief.com/issue-177
2021-01-28T00:00:00-08:00
2021-01-28T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks have passed very quickly. I volunteered to help my country plan and develop a system for distributing Covid-19 vaccines to those most in need. I hope everything runs as smoothly as it can.</p>
<p>I want to say thank you to the people and companies that have reached out about sponsorship. Thank you for that! It makes a big difference, and we still have free spots to <a href="/sponsorship">support this newsletter</a> and help us cover the running costs.</p>
<p>Lately, we have seen a rapid increase in new proposals from the community. It’s been great to see new folks joining and expressing their ideas. That means there’ll be more for us to cover, so let’s get on with the news.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://matteomanferdini.com/architecting-swiftui-apps-with-mvc-and-mvvm/swift-weekly-brief/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_177" target="_blank">Architecting SwiftUI apps with MVC and MVVM</a></h4>
<p>It’s easy to make an app by throwing some code together. But without best practices and a robust architecture, you soon end up with unmanageable spaghetti code. Learn to create solid and maintainable apps with fewer bugs with this free guide.</p>
<p><small><a href="https://matteomanferdini.com/architecting-swiftui-apps-with-mvc-and-mvvm/swift-weekly-brief/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_177" target="_blank">matteomanferdini.com/architecting-swiftui-apps-with-mvc-and-mvvm/swift-weekly-brief/</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-14058">SR-14058</a> Trying to coerce regular function to <code class="language-plaintext highlighter-rouge">@convention(c)</code> traps</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.empowerapps.show/77">Empower Apps #77</a>, <a href="https://twitter.com/leogdion">Leo Dion</a> talks with <a href="https://twitter.com/_sa_s">Sven A. Schmidt</a>, co-creator of the Swift Package Index. They discuss the challenges of supporting thousands of Swift Packages, dealing with metrics and site ops with Vapor, running CI for the site and the plethora of Swift packages as well as Apple Silicon support.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/khanlou">Soroush Khanlou</a> wrote <a href="https://khanlou.com/2021/01/meridian/">a blog post</a> about launching <a href="https://github.com/khanlou/Meridian/">Meridian</a> - a web server written in Swift that lets you write your endpoints in a declarative way.</p>
<p><a href="https://twitter.com/maxdesiatov">Max Desiatov</a> wrote <a href="https://desiatov.com/swift-structured-concurrency-introduction/">an excellent article</a> explaining structured concurrency in Swift.</p>
<p><a href="https://github.com/gonsolo">Andreas Wendleder</a> wrote <a href="https://gonsoloblog.wordpress.com/2021/01/14/rendering-moana-with-swift/">a great article</a> about rendering <a href="https://www.disneyanimation.com/resources/moana-island-scene/">Disney’s Moana island scene</a> with Swift. It’s worth reading the <a href="https://news.ycombinator.com/item?id=25779611">Hacker News thread</a> which contains a lot of valuable insights.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/hborla">Holly Borla</a> merged <a href="https://github.com/apple/swift/pull/35025">a pull request</a> which implements heuristics for pruning the generic operator overload search space.</p>
<p><a href="https://github.com/meg-gupta">Meghana Gupta</a> merged <a href="https://github.com/apple/swift/pull/35380">a pull request</a> that enables <code class="language-plaintext highlighter-rouge">ArrayBoundsCheckElimination</code> on OSSA.</p>
<p><a href="https://github.com/eeckstein/">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/35474">a pull request</a> that fixes a crash related to single-element tuples containing a label and a closure.</p>
<p><a href="https://github.com/etcwilde">Evan Wilde</a> merged <a href="https://github.com/apple/swift/pull/35215">a pull request</a> that adds <code class="language-plaintext highlighter-rouge">async-main</code> support.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md">SE-0298</a>: <em>Async/Await: Sequences</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318">accepted with modifications</a>.</p>
<blockquote>
<p>Feedback was overwhelmingly positive, with most of the discussion (and concerns) focused on the <code class="language-plaintext highlighter-rouge">cancel()</code> requirement of <code class="language-plaintext highlighter-rouge">AsyncSequence</code>. In light of this feedback, the proposal authors have <a href="https://forums.swift.org/t/se-0298-async-await-sequences/43786/67">determined at <code class="language-plaintext highlighter-rouge">cancel()</code> should be removed</a>. The Core Team has <strong>accepted this proposal</strong> with the following modifications:</p>
<ul>
<li>The <code class="language-plaintext highlighter-rouge">cancel()</code> requirement has been removed from <code class="language-plaintext highlighter-rouge">AsyncSequence</code>, per discussion feedback.</li>
<li>The <code class="language-plaintext highlighter-rouge">first()</code> method has been removed. It’s <a href="https://developer.apple.com/documentation/swift/collection/3017676-first">non-asynchronous counterpart</a> is a property, but at present properties cannot be <code class="language-plaintext highlighter-rouge">async</code>. With <code class="language-plaintext highlighter-rouge">async</code> properties <a href="https://forums.swift.org/t/pitch-effectful-read-only-properties/44090">under active discussion</a>, the Core Team felt that it would be better to let that discussion settle first (which may result in <code class="language-plaintext highlighter-rouge">first</code> becoming an <code class="language-plaintext highlighter-rouge">async</code> property) than risk having to change this declaration from a method to a function soon.</li>
<li>The <code class="language-plaintext highlighter-rouge">makeAsyncIterator</code> has been marked as <code class="language-plaintext highlighter-rouge">__consuming</code>. This is mostly an implementation detail, but is in line with <code class="language-plaintext highlighter-rouge">Sequence.makeIterator</code>.</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0300-continuation.md">SE-0300</a>: <em>Continuations for interfacing async tasks with synchronous code</em> is <a href="https://forums.swift.org/t/se-0300-continuations-for-interfacing-async-tasks-with-synchronous-code/43891">under a review</a>.</p>
<blockquote>
<p>Asynchronous Swift code needs to be able to work with existing synchronous code that uses techniques such as completion callbacks and delegate methods to respond to events. Asynchronous tasks can suspend themselves on continuations which synchronous code can then capture and invoke to resume the task in response to an event.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0299-extend-generic-static-member-lookup.md">SE-0299</a>: <em>Extending Static Member Lookup in Generic Contexts</em> is <a href="https://forums.swift.org/t/se-0299-extending-static-member-lookup-in-generic-contexts/43958">under a review</a>.</p>
<blockquote>
<p>Using static member declarations to provide semantic names for commonly used values which can then be accessed via leading dot syntax is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of this syntax. This proposal aims to relax restrictions on accessing static members on protocols to afford the same call-site legibility to generic APIs.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0295-codable-synthesis-for-enums-with-associated-values.md">SE-0295</a>: <em>Codable synthesis for enums with associated values</em> is <a href="https://forums.swift.org/t/se-0295-codable-synthesis-for-enums-with-associated-values-second-review/44036">under the second review</a>.</p>
<blockquote>
<p>Codable was introduced in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>
with support for synthesizing <code class="language-plaintext highlighter-rouge">Encodable</code> and <code class="language-plaintext highlighter-rouge">Decodable</code> conformance for <code class="language-plaintext highlighter-rouge">class</code> and <code class="language-plaintext highlighter-rouge">struct</code> types, that only contain values that also conform
to the respective protocols.</p>
<p>This proposal will extend the support for auto-synthesis of these conformances to enums with associated values.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a>: <em>Extend Property Wrappers to Function and Closure Parameters</em> is <a href="https://forums.swift.org/t/se-0293-second-review-extend-property-wrappers-to-function-and-closure-parameters/44220">under the second review</a>.</p>
<blockquote>
<p>Property Wrappers were <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md">introduced in Swift 5.1</a>, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending <em>where</em> property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> updated the <a href="https://github.com/filip-sakel/swift-evolution/blob/NNNN-extend-property-wrappers-to-functions-and-closures-amended/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a>: <em>Extend Property Wrappers to Function and Closure Parameters</em> pitch.</p>
<blockquote>
<ul>
<li>Passing a projected value using the <code class="language-plaintext highlighter-rouge">$</code> calling syntax is supported via <code class="language-plaintext highlighter-rouge">init(projectedValue:)</code>.</li>
<li>The type of the unapplied function reference uses the wrapped-value type by default. Referencing the function using the projected-value type is supported by writing <code class="language-plaintext highlighter-rouge">$</code> in front of the argument label, or <code class="language-plaintext highlighter-rouge">$_</code> if there is no argument label.</li>
<li>Closures with property-wrapper parameters have the same semantics as unapplied function references.</li>
<li>Additional arguments in the wrapper attribute are supported, and these arguments have the same evaluation semantics as default function arguments.</li>
</ul>
</blockquote>
<p><a href="https://github.com/yim-lee/">Yim Lee</a> <a href="https://forums.swift.org/t/package-collection-signing/43855">purposed</a> an idea to add <em>signed</em> package collections.</p>
<blockquote>
<p>Since <strong>Package Collections</strong> (<a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a>) can be created and published by anyone, issues related to authenticity and integrity may emerge.</p>
<ul>
<li>Publishers can establish authenticity and protect their collections from tampering.</li>
<li>Users can choose and consume collections based on trust guarantees and therefore help prevent package collections from being used as an attack vector.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> <a href="https://forums.swift.org/t/pitch-3-concurrentvalue-and-concurrent-closures/43947">informed</a> the community about updates to the <code class="language-plaintext highlighter-rouge">ConcurrentValue</code> and <code class="language-plaintext highlighter-rouge">@concurrent</code> closures pitch.</p>
<blockquote>
<p>After a long hiatus due to the holidays and other constraints, I was able to incorporate <a href="https://forums.swift.org/t/pitch-2-protocol-based-actor-isolation/42123/">a bunch of feedback</a> (primarily from <a href="https://forums.swift.org/t/preventing-data-races-in-the-swift-concurrency-model/43175">Doug</a>) into <a href="https://docs.google.com/document/d/1BEO6QwzcYCUhaGyA-WRoM_phRa7O7mGPNIMdSV4StEE/edit">the old ActorSendable proposal</a> – largely rewriting it in the process.</p>
</blockquote>
<p><a href="https://twitter.com/mishaldshah/">Mishal Shah</a> <a href="https://forums.swift.org/t/updating-llvm-project-swift-main-branch/44019">let folks know</a> that an update will be performed to the <code class="language-plaintext highlighter-rouge">swift/main</code> branch for <code class="language-plaintext highlighter-rouge">apple/llvm-project</code> repository.</p>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> <a href="https://forums.swift.org/t/introducing-swift-http-structured-headers/44041">announced</a> a new project: <a href="https://github.com/apple/swift-http-structured-headers">Swift HTTP Structured Headers</a> - a brand-new package that enables the Swift HTTP ecosystem to take advantage of new work being done by the IETF HTTP Working Group.</p>
<blockquote>
<p>HTTP Structured Header fields are <a href="https://tools.ietf.org/html/draft-ietf-httpbis-header-structure-19">a draft specification</a> being worked on by the IETF. They provide a set of data types and algorithms for handling HTTP header field values in a consistent way, allowing a single parser and serializer to handle a wide range of header field values. Working with HTTP header fields in the absence of Structured Header Fields often requires separate parsers and serialisers for each individual field, leading to a proliferation of parsers and serializers. Structured Header Fields address this head-on, defining a common base language for defining header fields going forward.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> updated the community regarding the revised <a href="https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md">actor proposal</a>.</p>
<blockquote>
<ul>
<li>Added a discussion of the tradeoffs with actor reentrancy, performance, and deadlocks, with various examples, and the addition of new attribute <code class="language-plaintext highlighter-rouge">@reentrant(never)</code> to disable reentrancy at the actor or function level.</li>
<li>Removed global actors; they will be part of a separate document.</li>
<li>Separated out the discussion of data races for reference types.</li>
<li>Allow asynchronous calls to synchronous actor methods from outside the actor.</li>
<li>Removed the <code class="language-plaintext highlighter-rouge">Actor</code> protocol; we’ll tackle customizing actors and executors in a separate proposal.</li>
<li>Clarify the role and behavior of actor-independence.
*Add a section to “Alternatives Considered” that discusses actor inheritance.</li>
<li>Replace “actor class” with “actor”.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/call1cc">Kavon Farvardin</a> shared <a href="https://forums.swift.org/t/pitch-effectful-read-only-properties/44090">a proposal</a> that allows some properties to have effects specifiers (<code class="language-plaintext highlighter-rouge">throws</code> and <code class="language-plaintext highlighter-rouge">async</code>) added to them.</p>
<blockquote>
<p>Nominal types such as classes, structs, and enums in Swift support <a href="https://docs.swift.org/swift-book/LanguageGuide/Properties.html">computed properties</a>, which are members of the type that invoke programmer-specified computations when getting or setting them; instead of being tied to storage like stored properties. The recently accepted proposal <a href="https://github.com/kavon/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a> introduced asynchronous functions via <code class="language-plaintext highlighter-rouge">async</code>, in conjunction with <code class="language-plaintext highlighter-rouge">await</code>, but did not specify that computed properties can support effects like asynchrony. Furthermore, to take full advantage of <code class="language-plaintext highlighter-rouge">async</code> properties, the ability to specify that a property <code class="language-plaintext highlighter-rouge">throws</code> is also important. This document aims to partially fill in this gap by proposing a syntax and semantics for effectful read-only computed properties.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/duan">Daniel Duan</a> <a href="https://forums.swift.org/t/idea-bytes-literal/44124">pitched</a> the idea of “bytes literals”.</p>
<blockquote>
<p>I think Swift should have “bytes literals”, supported by the compiler, as well as the standard library. Both <code class="language-plaintext highlighter-rouge">'hello'</code> and <code class="language-plaintext highlighter-rouge">'\x68\x65\x6C\x6C\x6F'</code> would be valid bytes literals, representing the same value.</p>
<p><strong>What <em>is</em> a byte literal?</strong>
They are similar to literals for strings/integers/bools. The standard library would provide similar treatment as for other literals. Specifically:</p>
<ul>
<li>Byte - Signless 8-bit value, not an int but has bit-twiddling facilities</li>
<li>Bytes - Collection of bytes with continuous storage: random access, range replaceable, etc.</li>
<li><code class="language-plaintext highlighter-rouge">ExpressibleByBytesLiteral</code>, <code class="language-plaintext highlighter-rouge">BytesLiteralType</code></li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/rintaro">Rintaro Ishizaki</a> pitched <a href="https://forums.swift.org/t/if-for-postfix-member-expressions/44159">a feature</a> that expands <code class="language-plaintext highlighter-rouge">#if</code> functionality to postfix member expressions. Aan update-version of this proposal will be kept <a href="https://github.com/rintaro/swift-evolution/blob/proposal-postfix-ifconfig-expressions/proposals/NNNN-postfix-ifconfig-expressions.md">here</a> and implementation <a href="https://github.com/apple/swift/pull/35097">here</a>.</p>
<blockquote>
<p>Swift has conditional compilation block <code class="language-plaintext highlighter-rouge">#if ... #endif</code> which allows code to be conditionally compiled depending on the value of one or more compilation conditions. Currently, unlike <code class="language-plaintext highlighter-rouge">#if</code> in C family languages, the body of each clause must surround complete statements. However, in some cases, especially in result builder contexts, demand for applying <code class="language-plaintext highlighter-rouge">#if</code> to partial expressions has emerged. This proposal expands <code class="language-plaintext highlighter-rouge">#if ... #endif</code> to be able to surround postfix member expressions.</p>
</blockquote>
<p><a href="https://twitter.com/ilseman">Michael Ilseman</a> updated us about version 2 of the <code class="language-plaintext highlighter-rouge">FilePath</code> APIs.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">FilePath</code> appeared in <a href="https://github.com/apple/swift-system/releases/tag/0.0.1">System 0.0.1</a> with a minimal API. This proposal adds API for <em>syntactic operations</em>, which are performed on the structure of the path and thus do not consult with the file system or make any system calls. These include inspecting the structure of paths, modifying paths, and accessing individual components.</p>
<p>Additionally, this proposal greatly expands Windows support and enables writing platform-agnostic path manipulation code.</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched <a href="https://forums.swift.org/t/renaming-subranges-where-of/44226">an idea</a> to rename the <code class="language-plaintext highlighter-rouge">subranges(where:)</code> and <code class="language-plaintext highlighter-rouge">subranges(of:)</code> methods, approved as part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md">SE-0270</a>, to <code class="language-plaintext highlighter-rouge">indices(where:)</code> and <code class="language-plaintext highlighter-rouge">indices(of:)</code>.</p>
<blockquote>
<p>The two methods in questions will be renamed to <code class="language-plaintext highlighter-rouge">indices(where:)</code> and <code class="language-plaintext highlighter-rouge">indices(of:)</code>. In addition to solving the problem described above, this brings these methods inline with their documentation, which describes the methods as returning the indices of the matching elements.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1354460688740061185">TDD</a>: <a href="https://twitter.com/jesse_squires?lang=en">Thirsty Driven Development</a></p>
Issue #176
https://swiftweeklybrief.com/issue-176
2021-01-14T00:00:00-08:00
2021-01-14T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>We are back from the holiday break. Whether you celebrate or not, I hope you took some time off to relax after this crazy 2020. We’re now in 2021, and I believe this year we will slowly move back to a more normal life. I hope we can meet in smaller meetups at the end of the year and start to safely travel again.</p>
<p>We have significant updates from <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code> field. A proposal adding this functionality has been accepted! There is a great <a href="https://t.co/V6O6RDgjMe?amp=1">video</a> by <a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> demonstrating how we can experiment with it already using the Swift development snapshot. Check it out.</p>
<p>I want to end this issue by calling for sponsors. Swift Weekly is a great place to promote your solution or company and target the Swift language professional audience. You’d also be supporting a community-backed project. This email and website would not be possible without our sponsors. We need to cover running costs and have some exciting plans to bring this project to the next level. Financial support would go a long way towards achieving these goals.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13976">SR-13976</a> [Compiler] Improve compiler error message: “partial application of ‘mutating’ method is not allowed”</li>
<li><a href="https://bugs.swift.org/browse/SR-14015">SR-14015</a> [Docs] Update references master -> main for branch related information</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.empowerapps.show/34">Empower Apps #74</a>, <a href="https://twitter.com/leogdion">Leo Dion</a> and <a href="https://twitter.com/0xtim">Tim Condon</a> talk about the Swift Server Work Group, SwiftNIO, Server-Side Swift’s growth in 2020 and Swift on Server-Side ARM.</p>
<h3 id="news-and-community">News and community</h3>
<p>The founder of this newsletter, <a href="https://twitter.com/jesse_squires">Jesse Squires</a>, wrote a <a href="https://www.jessesquires.com/blog/2020/12/28/the-different-types-of-self-in-swift/">post exploring the type of <code class="language-plaintext highlighter-rouge">self</code></a> in a Swift self-executing anonymous closure used to initialize a stored property. <a href="https://bugs.swift.org/secure/ViewProfile.jspa?name=nolanw">Nolan Waite</a> pointed out that this bug is being tracked at <a href="https://bugs.swift.org/browse/SR-4559">SR-4559</a> and <a href="https://bugs.swift.org/browse/SR-4865">SR-4865</a>.</p>
<p><a href="https://twitter.com/Kilo_Loco">Kilo Loco</a> shared a tool called <a href="https://github.com/Kilo-Loco/SLaM">Swift Lambda Maker</a>. Swift Lambda Maker is a CLI tool used to create and package AWS Lambda functions written in Swift. It can create a new executable Swift Package where you can start coding your Lambda as well as package that Lambda as a zipped Docker image.</p>
<p>Great <a href="https://blog.swiftwasm.org/posts/update-05-december-2020/">blog post</a> about updates from SwiftWasm team.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a>: <em>Async/await</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0296-async-await/43318">accepted</a>.</p>
<blockquote>
<p>Feedback was very positive on the concept of adding async/await in general with a few key points raised.</p>
<ul>
<li>It was suggested that <code class="language-plaintext highlighter-rouge">try await</code> reads better than <code class="language-plaintext highlighter-rouge">await try</code>. The core team agrees, and the proposal will be modified accordingly.</li>
<li>There was some discussion of alternatives to <code class="language-plaintext highlighter-rouge">async</code> (such as <code class="language-plaintext highlighter-rouge">suspends</code>) which may better describe the meaning. The core team feels that the benefit of sticking with <code class="language-plaintext highlighter-rouge">async</code> as a term of art with precedent in many other languages was preferable to the the slight descriptive benefit of alternative names. Note that other uses of <code class="language-plaintext highlighter-rouge">async</code> such as <code class="language-plaintext highlighter-rouge">async let</code> will be considered in other proposals.</li>
<li>Several reviewers expressed concern that it was hard to review this proposal “stand alone”, since it interacts so closely with, and its use depends on, other yet-to-be-reviewed proposals. The core team acknowledges this, but feels that this is unavoidable given the large surface area of the whole concurrency feature. To mitigate this, reviewers of subsequent proposals should feel free to revisit parts of accepted concurrency proposals in reviewing those subsequent proposals when they interact.</li>
<li>Several reviewers were disappointed about subsetting out getters. The core team wants to be clear that this is just left as a future direction, not ruled out, and as such isn’t a reason to hold back on accepting this proposal.</li>
<li>In a separate thread to the review, there was some discussion of the necessity of <code class="language-plaintext highlighter-rouge">try</code> and <code class="language-plaintext highlighter-rouge">await</code>. The core team does not believe the current requirement to mark throwing calls with <code class="language-plaintext highlighter-rouge">try</code> should be revisited, and thinks there is a similar need to mark possible suspension points with <code class="language-plaintext highlighter-rouge">await</code>. The core team would be open to considering future proposals that allow multiple calls needing either <code class="language-plaintext highlighter-rouge">try</code> or <code class="language-plaintext highlighter-rouge">await</code> to be sugared somehow (for example, some form of try block).</li>
</ul>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md">SE-0292</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0292-package-registry-service/43402">returned for revision</a>.</p>
<blockquote>
<p>The feedback to the idea of defining an open-standard Package Registry HTTP based API, and implementing support for it in SwiftPM as an alternative to resolving dependencies via git, was very positive.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0290-negative-availability.md">SE-0290</a>: <em>Unavailability Condition</em> is <a href="https://forums.swift.org/t/se-290-second-review-unavailability-condition/43544">under a second review</a>.</p>
<blockquote>
<p>The <em>second</em> review of <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0290-negative-availability.md">SE-0290, “Unavailability Condition”</a>, begins now and runs through January 12, 2021. This proposal was <a href="https://forums.swift.org/t/se-0290-unavailability-condition/41873/34">previously returned for revision 1</a>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0298-asyncsequence.md">SE-0298</a>: <em><code class="language-plaintext highlighter-rouge">Async</code>/<code class="language-plaintext highlighter-rouge">Await</code>: Sequences</em> is <a href="https://forums.swift.org/t/se-0298-async-await-sequences/43786">under a review</a>.</p>
<blockquote>
<p>Swift’s <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">async/await</a> feature provides an intuitive, built-in way to write and use functions that return a single value at some future point in time. We propose building on top of this feature to create an intuitive, built-in way to write and use functions that return many values over time.</p>
<p>This proposal is composed of the following pieces:</p>
<ol>
<li>A standard library definition of a protocol that represents an asynchronous sequence of values</li>
<li>Compiler support to use <code class="language-plaintext highlighter-rouge">for...in</code> syntax on an asynchronous sequence of values</li>
<li>A standard library implementation of commonly needed functions that operate on an asynchronous sequence of values</li>
</ol>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> <a href="https://forums.swift.org/t/development-open-for-swift-5-3-3-for-linux-and-windows/43007">informed</a> us about development for Swift 5.3.3 for Linux and Windows.</p>
<blockquote>
<p>We are happy to announce the opening of the development phase for Swift 5.3.3 for Linux and Windows.</p>
<ul>
<li>Merge window open: 17th December 2020 (now)</li>
<li>Merge window close: 22nd January 2021</li>
<li>Planned release: End of January or February 2021</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/sherlouk">James Sherlock</a> <a href="https://forums.swift.org/t/spm-multi-package-repositories/43193">pitched</a> to add support for repositories which contain multiple packages for the first time.</p>
<blockquote>
<p>Many developers operate under a “<a href="https://en.wikipedia.org/wiki/Monorepo">mono repo</a>” design pattern where code for multiple packages or projects exists under one repository.</p>
<p>Swift Package Manager currently assumes that each repository only contains one package, this may not always be true - this proposal aims to add support for repositories which contain multiple packages.</p>
</blockquote>
<p><a href="https://twitter.com/mattt">Mattt</a> started a <a href="https://forums.swift.org/t/urls-as-swift-package-identifiers/43404">discussion</a> about URLs as Swift package identifiers.</p>
<blockquote>
<p>We believe that using URLs as package identifiers is intuitive and familiar for developers, and will best solve the immediate and future needs of this project.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> posted an <a href="https://forums.swift.org/t/pitch-2-structured-concurrency/43452">update</a> describing the <a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">Structured Concurrency</a> Pitch Document revisions.</p>
<p><a href="https://twitter.com/SlaunchaMan">Jeff Kelley</a> pitched <a href="https://forums.swift.org/t/adding-sugar-for-preconditions-and-guards/43520">an idea</a> to add sugar for preconditions and guards.</p>
<p><a href="https://forums.swift.org/u/chuquimia_max">Chuquimia_Max</a> expressed <a href="https://forums.swift.org/t/pitch-enum-composition/43598">an idea</a> to add <code class="language-plaintext highlighter-rouge">enum</code> composition.</p>
<blockquote>
<p>It seems this has <em>almost</em> been discussed <a href="https://forums.swift.org/t/enum-inheritance/9933">here</a> and <a href="https://forums.swift.org/t/enums-as-enum-underlying-types/17375/19">here</a> but never with what I would consider to be an intuitive, Swift-esque syntax.</p>
<p>Essentially, I reckon it would be beneficial to be able to create a composed enum using <code class="language-plaintext highlighter-rouge">&</code> in the same way protocol composition is currently functioning.
Composable enums could also be handy if we get typed <code class="language-plaintext highlighter-rouge">throws</code> in the future: if only enum errors are thrown the compiler could implicitly compose an error enum based on the call stack.</p>
</blockquote>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> pitched <a href="https://forums.swift.org/t/concurrency-continuations-for-interfacing-async-tasks-with-synchronous-code/43619">an idea</a> about continuations for interfacing async tasks with synchronous code.</p>
<blockquote>
<p>Asynchronous Swift code needs to be able to work with existing synchronous
code that uses techniques such as completion callbacks and delegate methods to
respond to events. Asynchronous tasks can suspend themselves on
<strong>continuations</strong> which synchronous code can then capture and invoke to
resume the task in response to an event.</p>
</blockquote>
<p><a href="https://twitter.com/mishaldshah">Mishal Shah</a> <a href="https://forums.swift.org/t/swift-5-4-nightly-development-snapshots/43791">informs</a> us that Swift 5.4 nightly development snapshots are now available on <a href="https://swift.org/download/#snapshots">https://swift.org/download/#snapshots</a>.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> <a href="https://forums.swift.org/t/code-of-conduct-updated-january-12-2021/43807">updated</a> the community concerning new changes to the Code of Conduct.</p>
<blockquote>
<p>We all want the Swift community to be welcoming and inclusive, and a place where anyone can come to answer questions, propose their ideas, and help shape the future of Swift. To better promote inclusiveness, the Core team is revising the <a href="https://swift.org/code-of-conduct/">Code of Conduct</a> on <a href="http://swift.org/">Swift.org</a> that covers all aspects of the Swift project.</p>
<p>The revision incorporates changes from <a href="https://www.contributor-covenant.org/version/1/4/code-of-conduct/">v1.4 of the Contributor Covenant</a>, which provides examples of positive behaviors and suggestions for us all to keep in mind in our interactions. The revision also clarifies some policies to follow when issues arise.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://iosdevsurvey.com/updates/launching-the-2020-survey/">The iOS Developer Community Survey 2020</a>.</p>
Issue #175
https://swiftweeklybrief.com/issue-175
2020-12-17T00:00:00-08:00
2020-12-17T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Before heading into the holiday period, we have some great news about <code class="language-plaintext highlighter-rouge">async/await</code>. The proposal adding this functionality is <a href="https://forums.swift.org/t/se-0296-async-await/42605">under review</a>. It’s a good opportunity to express your opinion.</p>
<p>We have some news from the Swift Server Workgroup. Three new people have <a href="https://forums.swift.org/t/december-15th-2020-special-update/42865">joined</a> to help support future efforts.</p>
<p>We end this year with a notable and very welcome initiative - <a href="https://swift.org/blog/diversity-in-swift/">Diversity in Swift</a>. The Diversity in Swift workgroup will use the <a href="https://forums.swift.org/c/community-showcase">Community Showcase</a> to brainstorm ideas and topics for these community-focused blog posts. The <a href="https://swift.org/blog/accessibility-and-inclusion">first post</a> curates helpful resources for accessibility and inclusion in Swift, all made by awesome developers from our community.</p>
<p>This brief is the last issue of the year. We are taking a small festive break and will be back in early January.</p>
<p>Evoking the spirit of philanthropy, if you’d like to sponsor the Weekly Brief when we return, please <a href="mailto:fassko@gmail.com">get in touch</a>.</p>
<p>Wishing you the happiest of holidays and a fantastic New Year! 🍷</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://swiftpackageindex.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_175" target="_blank">Swift Package Index</a></h4>
<p>This week’s issue is supported by Dave Verwer who co-created the Swift Package Index, and publishes iOS Dev Weekly every Friday. He’s been a big advocate for the Weekly Brief since it started, and is supporting us because he wants to see it continue! It’s that simple.</p>
<p><small><a href="https://swiftpackageindex.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_175" target="_blank">https://swiftpackageindex.com/</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13969">SR-13969</a> [docs] Describe how to quickly compile a minimal multi-module project</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest episode of Swift Unwrapped, <a href="https://twitter.com/jesse_squires">Jesse</a> and <a href="https://twitter.com/simjp">JP</a> talk <a href="https://spec.fm/podcasts/swift-unwrapped/spdcC97m">about concurrency</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/eneko">Eneko Alonso</a> wrote <a href="https://www.enekoalonso.com/2020/12/06/getting-started-with-async-await-in-swift.html">a blog post</a> explaining how to get started with <code class="language-plaintext highlighter-rouge">async/await</code> in Swift.</p>
<p><a href="https://forums.swift.org/u/hborla">Holly Borla</a> wrote <a href="https://swift.org/blog/accessibility-and-inclusion/">a blog post</a> that showcases resources about accessibility and inclusion created by developers across our community.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> announced a new initiative for the Swift project called <a href="https://swift.org/blog/diversity-in-swift/">Diversity in Swift</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/maxdesiatov/">Max Desiatov</a> opened <a href="https://github.com/apple/swift/pull/34998">a pull request</a>.</p>
<p><a href="https://github.com/neonichu">Boris Bügling</a> opened <a href="https://github.com/apple/swift-package-manager/pull/3120">a pull request</a> to add a deprecation warning for the presence of version-specific manifests.</p>
<p><a href="https://github.com/rintaro">Rintaro Ishizaki</a> merged <a href="https://github.com/apple/swift/pull/35070">a pull request</a> that fixes a problem where <code class="language-plaintext highlighter-rouge">async</code> was being incorrectly consumed in <code class="language-plaintext highlighter-rouge">parseType</code>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a>: <em>Package Collections</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0291-package-collections/42622">accepted with modifications</a>.</p>
<blockquote>
<p>The feedback from the <a href="https://forums.swift.org/t/package-feeds/">pitch</a> and <a href="https://forums.swift.org/t/se-0291-package-collections/">first review</a> helped ensure Package Collections are useful and put the Swift packages ecosystem on the right path. During the <a href="https://forums.swift.org/t/se-0291-package-collections/">first review</a>, several community members requested to learn more about the Package Collection data format and the proposal was amended to include this information. The feedback from the <a href="https://forums.swift.org/t/se-0291-2nd-review-package-collections/42369">2nd review</a> was generally positive and the proposal has been accepted with one minor revision: The spelling for the command should be singular (<code class="language-plaintext highlighter-rouge">swift package-collection</code>) instead of plural (<code class="language-plaintext highlighter-rouge">swift package-collections</code>).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0294-package-executable-targets.md">SE-0294</a>: <em>Declaring executable targets in Package Manifests Evolution Announcements</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0294-declaring-executable-targets-in-package-manifests/42859">accepted with modifications</a>.</p>
<blockquote>
<p>The feedback from the pitch and review was positive and the proposal has been accepted with a minor revision: The proposal should explicitly call out that starting with SwiftPM tools-version 5.4, declaring an executable target by using .target and having it inferred to be an executable by the presence of a top-level source file named main.swift is considered deprecated; That SwiftPM will continue to infer such targets as executable for a transition period but will eventually stop doing so and treat all targets declared using .target as library targets; And that in the transition period, using .target with main.swift will emit a warning or a fix-it based on technical feasibility.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0293-extend-property-wrappers-to-function-and-closure-parameters.md">SE-0293</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0293-extend-property-wrappers-to-function-and-closure-parameters/42953">returned for revision</a>.</p>
<blockquote>
<p>Most of the discussion in the feedback thread centered around a central question of “what is the type of a function that has a property wrapper parameter?”. The proposal describes a model where the wrapper is part of the exposed type (for example <code class="language-plaintext highlighter-rouge">(Binding<Item>)->Void</code>), but many data points in the thread argued for a model where the exposed type of a function is the unwrapped type (for example <code class="language-plaintext highlighter-rouge">(Item)->Void</code>).</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0296-async-await.md">SE-0296</a>: <em>Async/await</em> is <a href="https://forums.swift.org/t/se-0296-async-await/42605">under a review</a>.</p>
<blockquote>
<p>Modern Swift development involves a lot of asynchronous (or “async”) programming using closures and completion handlers, but these APIs are hard to use. This gets particularly problematic when many asynchronous operations are used, error handling is required, or control flow between asynchronous calls gets complicated. This proposal describes a language extension to make this a lot more natural and less error prone.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0292-package-registry-service.md">SE-0292</a>: <em>Package Registry Service</em> is <a href="https://forums.swift.org/t/se-0292-package-registry-service/42623">under a review</a>.</p>
<blockquote>
<p>Swift Package Manager downloads dependencies using Git. Our proposal defines a standard web service interface that it can also use to download dependencies from package registries.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0297-concurrency-objc.md">SE-0297</a>: <em>Concurrency Interoperability with Objective-C</em> is <a href="https://forums.swift.org/t/se-0297-concurrency-interoperability-with-objective-c/42702">under a review</a>.</p>
<blockquote>
<p>Swift’s concurrency feature involves asynchronous functions and actors. While Objective-C does not have corresponding language features, asynchronous APIs are common in Objective-C, expressed manually through the use of completion handlers. This proposal provides bridging between Swift’s concurrency features (for example, <code class="language-plaintext highlighter-rouge">async</code> functions) and the convention-based expression of asynchronous functions in Objective-C. It is intended to allow the wealth of existing asynchronous Objective-C APIs to be immediately usable with Swift’s concurrency model.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/SmileyKeith">Keith Smiley</a> started discussion about supporting strict imports.</p>
<blockquote>
<p>We have a large multi-module Swift codebase where we want to support strict imports, meaning files only import what they use, and they import everything they use (not particularly at the class level with import class Foo.bar, but at least import Foo). We have a few specific reasons for wanting this to be enforced:</p>
<ol>
<li>When reading a diff it makes it clear when a new dependency on a module is being introduced</li>
<li>When this is explicitly defined we can enforce what types of modules are allowed to import what other types of modules, for example we don’t want modules with business logic importing our UI layer etc</li>
<li>By trimming unused imports, we can eliminate unnecessary intermodule dependencies, simplifying the dependency graph and speeding up compilation</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> started <a href="https://forums.swift.org/t/long-term-implications-of-async-await-for-the-programming-model/42624">a discussion</a> about long-term implications of <code class="language-plaintext highlighter-rouge">async/await</code> for the programming model.</p>
<blockquote>
<p>This is not dependent on the specifics of any of the proposals under discussion, but I wanted to explore a little bit what the introduction of async/await might mean for the way we program in the long term. I have just two related concerns at this point. I hope the proposers have considered these questions and have some answers, but I’d be interested in anyone’s thoughts.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/pitch-2-concurrency-interoperability-with-objective-c/42627">informed us</a> about an updated pitch for <a href="https://github.com/DougGregor/swift-evolution/blob/concurrency-objc/proposals/NNNN-concurrency-objc.md">Concurrency Interoperability with Objective-C</a>.</p>
<blockquote>
<p>The first <a href="https://forums.swift.org/t/concurrency-interoperability-with-objective-c/41616">pitch thread</a> provided a bit of feedback, which I’ve incorporated into this second pitch. The specific changes:</p>
</blockquote>
<blockquote>
<ul>
<li>Removed mention of asynchronous handlers, which will be in a separate proposal.</li>
<li>Introduced the <code class="language-plaintext highlighter-rouge">swift_async_error</code> Clang attribute to separate out “throwing” behavior from the <code class="language-plaintext highlighter-rouge">swift_async</code> attribute.</li>
<li>Added support for “Swift private” to the <code class="language-plaintext highlighter-rouge">swift_async</code> attribute.</li>
<li>Tuned the naming heuristics based on feedback to add (for example) <code class="language-plaintext highlighter-rouge">reply</code> , <code class="language-plaintext highlighter-rouge">replyTo</code> , <code class="language-plaintext highlighter-rouge">completionBlock</code> , and variants.</li>
<li>For the rare case where we match a parameter suffix, append the text prior to the suffix to the base name.</li>
<li>Replaced the <code class="language-plaintext highlighter-rouge">-generateCGImagesAsynchronouslyForTimes:completionHandler:</code> example with one from PassKit.</li>
<li>Added a “Future Directions” section about <code class="language-plaintext highlighter-rouge">NSProgress</code> .</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> raised a concern that the rule requiring a <code class="language-plaintext highlighter-rouge">try</code> label on every potentially-throwing statement was too indiscriminate.</p>
<blockquote>
<p>It’s not that requiring a <code class="language-plaintext highlighter-rouge">try</code> label is always a mistake, I argued—in fact, in <em>some</em> cases being forced to acknowledge a possible throw could be extremely helpful in reasoning about code—it’s just that there are so many cases where it wasn’t helpful.</p>
</blockquote>
<p><a href="https://twitter.com/glbrntt">George Barnett</a> asked a couple of questions about source location in literals and result builders.</p>
<blockquote>
<p>One issue I’ve come across recently is the fact that you cannot access the source location of the literal triggering a call to <code class="language-plaintext highlighter-rouge">ExpressibleByFooLiteral</code>, as <code class="language-plaintext highlighter-rouge">init(fooLiteral value: Foo, file: StaticString = #file)</code> would fail to fulfill the protocol requirement. There was <a href="https://forums.swift.org/t/pitch-allow-functions-with-default-arguments-to-fulfill-protocols/9186/15">a pitch</a> quite some time ago to allow functions with default arguments to satisfy protocol requirements, but not much seems to have happened as a result. <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md">Result builders</a> might have a similar problem, as it seems one cannot write <code class="language-plaintext highlighter-rouge">static func buildExpression(..., file: StaticString = #file)</code>, though since this particular method participates on overload resolution it may just work.</p>
</blockquote>
<p>Swift on the Server Workgroup meeting notes:</p>
<ul>
<li><a href="https://forums.swift.org/t/october-28-2020/42655">October 28, 2020</a> by <a href="https://twitter.com/k__mahar">Kaitlin Mahar</a></li>
<li><a href="https://forums.swift.org/t/november-11-2020/42704">November 11, 2020</a> by <a href="https://forums.swift.org/u/peteradams-a">Peter Adams</a></li>
<li><a href="https://forums.swift.org/t/december-15th-2020-special-update/42865">December 15th, 2020 Special Update</a> by <a href="https://twitter.com/TomerDoron">Tom Doron</a></li>
</ul>
<p><a href="https://twitter.com/michel_fortin">Michel Fortin</a> started a discussion about interlocking in a hierarchy of actors.</p>
<blockquote>
<p>I think it’s a bit of a problem that actors can’t talk to each other synchronously. I’m trying to find a model that would allow synchronous calls from actor to another actor while avoiding deadlocks and limiting blocking. So this an the idea I’ve come with. I’ll be keeping an updated version of this document <a href="https://gist.github.com/michelf/bb2d61f994306b61e5c26e076e4a2418">here</a>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/ktoso">Konrad <code class="language-plaintext highlighter-rouge">ktoso</code> Malawski</a> pitched <a href="https://forums.swift.org/t/pitch-task-local-values/42829">an idea</a> introducing task local values to the <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">Swift’s concurrency model </a>.</p>
<blockquote>
<p>Task local values provide a much needed missing piece in the <a href="https://github.com/apple/swift/blob/main/stdlib/public/Concurrency/Task.swift">Task</a> infrastructure puzzle. It enables instrumentation, profiling and tracing tool authors to build truly great <em>contextualized</em> experiences for debugging, profiling and tracing codebases using asynchronous functions and actors.</p>
<p>At the same time this proposal avoids pitfalls of similar APIs thanks to embracing Swift’s <a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">Structured Concurrency</a> approach.</p>
<p>Please refer to <a href="https://github.com/ktoso/swift-evolution/blob/wip-tasklocals/proposals/nnnn-task-locals.md#alternative-api-considered">the complete and up-to-date pitch document</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/NovallSwift/status/1335358897926721539">A day in the life of an Apple Engineer</a>.</p>
<p><a href="https://forums.swift.org/t/parsing-into-a-dictionary-of-int-int/42564">Advent of Code with Swift Argument Parser</a>.</p>
Issue #174
https://swiftweeklybrief.com/issue-174
2020-12-03T00:00:00-08:00
2020-12-03T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>On this day, <a href="https://developer.apple.com/swift/blog/?id=34">exactly five years ago</a>, Apple open-sourced the Swift programming language! Imagine how fast this language has moved, and what the next five years will bring.</p>
<p>We have some excellent news for server-side Swift development. Starting with the introduction of <a href="https://swift.org/blog/swiftnio-ssh/">SwiftNIO SSH</a> and an early version of Docker Desktop <a href="https://twitter.com/morlhon/status/1332609373051478016">running on Apple Silicon</a>, we can add <a href="https://developer.apple.com/news/?id=swfemvx0">Mac instances for EC2</a> which are now available from <a href="https://aws.amazon.com/blogs/aws/new-use-mac-instances-to-build-test-macos-ios-ipados-tvos-and-watchos-apps/">Amazon Web Services</a>. I think this will open even more doors for Swift, and let developers build great products in even more places!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://iosdevweekly.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_174" target="_blank">iOS Dev Weekly</a></h4>
<p>This week’s issue is supported by Dave Verwer, who publishes iOS Dev Weekly every Friday and co-created the Swift Package Index. He’s been a big advocate for the Weekly Brief since it started, and is supporting us because he wants to see it continue. Thanks Dave!</p>
<p><small><a href="https://iosdevweekly.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_174" target="_blank">https://iosdevweekly.com/</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13899">SR-13899</a> [Compiler] Missing conditional cast fix-it</li>
<li><a href="https://bugs.swift.org/browse/SR-13903">SR-13903</a> [Compiler] Make <code class="language-plaintext highlighter-rouge">ApplyInst</code> a <code class="language-plaintext highlighter-rouge">MultipleValueInstruction</code></li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.swiftbysundell.com/podcast/86/">episode 86</a> of the Swift by Sundell podcast, <a href="https://twitter.com/dimsumthinking">Daniel Steinberg</a> joins <a href="https://twitter.com/johnsundell">John</a> to discuss how various functional programming patterns can be adopted in Swift, and how many of those patterns can be found in both the standard library and in frameworks like Combine and SwiftUI.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://swift.org/blog/swiftnio-ssh/">Introducing SwiftNIO SSH</a>, a collection of APIs that allow programmers to implement SSH-speaking endpoints.</p>
<blockquote>
<p>SwiftNIO SSH is a programmatic implementation of SSH: that is, it is a collection of APIs that allow programmers to implement SSH-speaking endpoints. Critically, this means it is more like libssh2 than openssh. SwiftNIO SSH does not ship production-ready SSH clients and servers, but instead provides the building blocks for building this kind of client and server.</p>
</blockquote>
<p><a href="https://www.twitter.com/zntfdr">Federico Zanetello</a> wrote a <a href="https://fivestars.blog/swift/disfavoredOverload.html">blog post</a> about <code class="language-plaintext highlighter-rouge">@_disfavoredOverload</code>.</p>
<blockquote>
<p>Function overloading is a powerful tool that enables us to define multiple functions of the same name with different implementations:
in this article we’ve covered how Swift addresses ambiguity and how we can (<em>cautiously</em>) use the <code class="language-plaintext highlighter-rouge">@_disfavoredOverload</code> attribute in case of multiple matches.</p>
</blockquote>
<p><a href="https://twitter.com/jamesdempsey">James Dempsey</a> announced a new project - <a href="https://swiftversion.net/">Swift Version</a> - a website that shows which version of Swift shipped with which version of Xcode.</p>
<p><a href="https://twitter.com/mishaldshah">Mishal Shah</a> announced <a href="https://swift.org/platform-support">Swift Platform Support</a> - a central hub detailing which tools and capabilities are available on specific platforms for the development and deployment of Swift applications.</p>
<h3 id="videos">Videos</h3>
<p>In <a href="https://youtu.be/wbIwhv98ALg">episode 1</a> of the Swift Community series <a href="https://twitter.com/twannl">Antoine v.d. Lee</a> joins <a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> to discuss and play around with Custom Operators.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/LucianoPAlmeida">Luciano Almeida</a> created <a href="https://github.com/apple/swift/pull/34883">a pull request</a> that proposes to adjust coerce to checked cast diagnostic to be broken into the diagnostic and resolves <a href="https://bugs.swift.org/browse/SR-13899">SR-13899</a>.</p>
<p><a href="https://twitter.com/CodaFi_">Robert Widmann</a> merged <a href="https://github.com/apple/swift/pull/34808">a pull request</a> that adds a new Fingerprint currency type that centralizes a bunch of hashing invariants and gives me some room to try to experiment with different hashing regimes.</p>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a>: <em>Package Collections</em> has been revised and placed back into a <a href="https://forums.swift.org/t/se-0291-2nd-review-package-collections/">2nd review</a>.</p>
<blockquote>
<p>Based on the feedback from the <a href="https://forums.swift.org/t/package-feeds/">pitch</a> and first review, the core team feels the ideas behind Package Collections are useful and put the Swift Packages ecosystem on the right path.</p>
<p>However, during the first review, several community members requested to learn more about the Package Collection data format. The core team felt the proposal should be amended to explicitly call out if the data format is part of the feature specification or not, and provide reasoning for its inclusion or exclusion.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> posted <a href="https://gist.github.com/DougGregor/444575ac67cbd25bfc4b1d4fd241ae93">an image</a> showing Swift concurrency proposal dependencies. Cool to see everything together.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a>: <em>Package Collections</em> is <a href="https://forums.swift.org/t/se-0291-2nd-review-package-collections/42369">under a 2nd review</a>.</p>
<blockquote>
<p>This is a proposal for adding support for <strong>Package Collections</strong> to SwiftPM. A package collection is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these collections, search them via the <code class="language-plaintext highlighter-rouge">swift package-collections</code> command-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package collections.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0295-codable-synthesis-for-enums-with-associated-values.md">SE-0293</a>: <em>Package Collections</em> is <a href="https://forums.swift.org/t/se0293-extend-property-wrappers-to-function-and-closure-parameters/42400">under review</a>.</p>
<blockquote>
<p>Property Wrappers were <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0258-property-wrappers.md">introduced in Swift 5.1</a>, and have since become a popular mechanism for abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on local variables and type properties. However, with increasing adoption, demand for extending <em>where</em> property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0294-package-executable-targets.md">SE-0294</a>: <em>Declaring executable targets in Package Manifests</em> is <a href="https://forums.swift.org/t/se-0294-declaring-executable-targets-in-package-manifests/42404">under review</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0295-codable-synthesis-for-enums-with-associated-values.md">SE-0295</a>: <em>Codable synthesis for enums with associated values</em> is <a href="https://forums.swift.org/t/se-0295-codable-synthesis-for-enums-with-associated-values/42408">under review</a>.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/rxwei">Richard Wei</a> <a href="https://forums.swift.org/t/differentiable-programming-for-gradient-based-machine-learning/42147">pitched</a> a <a href="https://github.com/rxwei/swift-evolution/blob/autodiff/proposals/0000-differentiable-programming.md">proposal</a> adding differentiable programming as a first-class, language-integrated feature in Swift.</p>
<blockquote>
<p>As a compiled programming language with a modern type system, Swift has a unique opportunity to develop its own numerical computing and ML ecosystem. Driven by the growing needs of ML libraries and algorithms, we believe one key technology, differentiable programming, will help push ML development experience and developer productivity to a whole new level.</p>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> informed that with <a href="https://github.com/apple/swift-package-manager/pull/3062">the pull request #3062</a> there has been introduced a warning about the upcoming deprecation of SwiftPM’s <code class="language-plaintext highlighter-rouge">generate-xcodeproj</code> command.</p>
<blockquote>
<p>The motivation for the upcoming deprecation is the fact that starting Xcode 11, opening and building packages is directly supported by Xcode and therefore we believe that generate-xcodeproj no longer provides material value.</p>
<p>The PR generated some interesting follow-on discussion on how folks are still using generate-xcodeproj, and this thread is an RFC to track such use cases and see how they can be best addressed.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/concurrency-evolving-the-concurrency-design-and-proposals/42184">summarized</a> some of that feedback and what we’ll be adjusting in the revised proposals about Swift concurrency. Read carefully the thread and follow the updates.</p>
<blockquote>
<p>We posted the first drafts of a number of proposals related to Swift concurrency a few weeks ago. At this time of this writing, the forum topics directly related to the concurrency proposals have more than 600 posts in total (!), which includes lots of great ideas for design improvements, requests for clarification, and so on.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/somerandomiosdev">Joe Newton</a> pitched an idea to add inline <code class="language-plaintext highlighter-rouge">@convention(…)</code> attributes for closures.</p>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> pitched a proposal to adding some <code class="language-plaintext highlighter-rouge">swift package</code> subcommands for making mechanical edits to the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest.</p>
<blockquote>
<p>Because Swift package manifests are written in Swift using the PackageDescription API, it is difficult to automate common tasks like adding a new product, target, or dependency. This proposal introduces new <code class="language-plaintext highlighter-rouge">swift package</code> subcommands to perform some common editing tasks which can streamline users’ workflows and enable new higher-level tools.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/wolf">Wolf McNally</a> pitched idea about <a href="https://forums.swift.org/t/floating-point-interval/42263">floating point interval for Swift</a>.</p>
<blockquote>
<p>When working on code where I’m doing a lot of calculation in geometric spaces such as layout, animation, or color, I often find myself using the concept of a floating point interval: a closed range on the floating point number line. However, the existing ClosedRange requires its bounds to be ordered, which makes it less than useful for geometric calculations where a coordinates can travel or be interpolated in either direction.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/mrmage">Daniel Alm</a> shared <a href="https://forums.swift.org/t/speeding-up-strings-utf8-parsing/42270">an idea</a> how to speed up <code class="language-plaintext highlighter-rouge">String</code> UTF8 parsing.</p>
<blockquote>
<p>I recently came across <a href="https://lemire.me/blog/2020/10/20/ridiculously-fast-unicode-utf-8-validation/">Daniel Lemire’s work on fast UTF8 validation</a>. Given that Swift needs to UTF8-validate nearly every string that is e.g. read from a SQLite database, I was wondering whether it would be possible and worthwhile to use Lemire’s work for speeding up <a href="https://github.com/apple/swift/blob/main/stdlib/public/core/StringUTF8Validation.swift">Swift’s current UTF8 validation code</a>.</p>
</blockquote>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> asked “why should actors support subclassing?”.</p>
<blockquote>
<p>One hotly debated thing in the recent actor proposal is whether it should be <code class="language-plaintext highlighter-rouge">actor class</code> or <code class="language-plaintext highlighter-rouge">actor</code>. I think there is a more fundamental question, which is basically “why should actors support subclassing?”</p>
<p>I wrote up some thoughts on this in this whitepaper: <a href="https://docs.google.com/document/d/14e3p6yBt1kPrakLcEHV4C9mqNBkNibXIZsozdZ6E71c/edit#">Actors are reference types, but why classes?</a></p>
</blockquote>
<p><a href="https://twitter.com/dancherp">Dan Zheng</a> posted a pitch for improving the type system to make Swift code safer in certain cases. One application of this could be type-safe lists, but there’s certainly more we could do with it. He also asked two great <a href="https://forums.swift.org/t/basic-swift-ownership-y-questions/42340">questions</a> about ownerships in Swift.</p>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> wrote a whitepaper exploring the issues and making a recommendation on one way to address the problem: <a href="https://docs.google.com/document/d/1DKRs1mknTxB1s04KTVgteAmzh51ubk6-hA-HRSr7mzY/edit#">Actor isolation for Global State</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/pitch-rethrowing-protocol-conformances/42373">pitched</a> <a href="https://github.com/DougGregor/swift-evolution/blob/rethrows-protocol-conformances/proposals/NNNN-rethrows-protocol-conformances.md">an idea</a> about rethrowing protocol conformances.</p>
<blockquote>
<p>The proposed solution is to consider protocol conformances to be a source of throwing behavior for <code class="language-plaintext highlighter-rouge">rethrows</code>, allowing <code class="language-plaintext highlighter-rouge">rethrows</code> to reason about the throwing behavior of user operations provided via protocol conformances.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/tony_parker">Tony Parker</a> <a href="https://forums.swift.org/t/concurrency-asyncsequence/42417">pitched</a> <a href="https://github.com/parkera/swift-evolution/blob/asyncsequence/proposals/NNNN-asyncsequence.md">a proposal</a> to build on the Swift Concurrency pitches to add the concept of an AsyncSequence to the Swift standard library.</p>
<blockquote>
<p>Swift’s proposed <a href="https://github.com/DougGregor/swift-evolution/blob/async-await/proposals/nnnn-async-await.md">async/await</a> feature provides an intuitive, built-in way to write and use functions that return a single value at some future point in time. We propose building on top of this feature to create an intuitive, built-in way to write and use functions that return many values over time.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> informed that you can read the second pitch of the <a href="https://github.com/DougGregor/swift-evolution/blob/async-await/proposals/nnnn-async-await.md">async/await proposal</a>, which has been revised based on feedback from the <a href="https://forums.swift.org/t/concurrency-asynchronous-functions/41619">first pitch thread</a>.</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/taylorswift13/status/1331389046065684483">Taylor Swift Reacts to Her 2021 Grammy Nominations</a>.</p>
Issue #173
https://swiftweeklybrief.com/issue-173
2020-11-19T00:00:00-08:00
2020-11-19T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks passed quickly. We now have <a href="https://t.co/1dmN0Ppvf2?amp=1">Swift Evolution dashboard</a> <a href="https://github.com/apple/swift-evolution/pull/1177">working</a> in dark mode. How cool is that?</p>
<p>Great news for server-side folks. We have now <a href="https://github.com/swiftkube">Swift tooling for Kubernetes</a>. Now you can orchestrate your server containers using language you know and love.</p>
<p>We’re close again to the Holiday season and there is a special schedule when <a href="https://forums.swift.org/t/holiday-schedule/41945">merge access is locked</a>. I think it’s great to take some time and unplug. I know from myself, it is hard to do it, especially if you’re passionate about a project you’re working on.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://raycast.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_173" target="_blank">Goodbye Spotlight. Hello Raycast.</a></h4>
<p>Raycast pairs macOS Spotlight with deep integrations to your web apps. Create issues in Jira, merge pull requests in GitHub, or join Zoom calls with a few keyboard shortcuts. Extend the app with scripts to automate every-day tasks. Built for macOS with 100% Swift inside.</p>
<p><small><a href="https://raycast.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_173" target="_blank">raycast.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13848">SR-13848</a> [Compiler] Restore Note About Optionality Mismatch in Redeclared Functions Involving IUOs and Optionals.</li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/hborla">Holly Borla</a> merged <a href="https://github.com/apple/swift/pull/34399">a pull request</a> that implements heuristics for linked operator expressions in the solver proper.</p>
<p><a href="https://github.com/buttaface">buttaface</a> created <a href="https://github.com/apple/swift/pull/34491">a pull request</a> improving Android support - moving to the NDK’s unified sysroot. As well he merged <a href="https://github.com/apple/swift/pull/34661">a pull request</a> that adds support for <code class="language-plaintext highlighter-rouge">x86_64</code> arch for Android.</p>
<p><a href="https://github.com/bnbarham">Ben Barham</a> merged <a href="https://github.com/apple/swift/pull/34697">a pull request</a> that adds features file describing new available flags.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a> has been <a href="https://forums.swift.org/t/returned-for-revision-se-0291-package-collections/42109">returned for revision</a>.</p>
<blockquote>
<p>During the review, several community members requested to learn more about the Package Collection data format. The core team felt the proposal should be amended to explicitly call out if the data format is part of the feature specification or not, and provide reasoning for its inclusion or exclusion.</p>
<p>For example, it makes sense for the data format to be included if it is considered a stable API that users may build tools around, and conversely it makes sense to exclude if it is considered a non-stable API that users should not be generated directly.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0290-negative-availability.md">SE-0290</a>: <em>Unavailability Condition</em> is <a href="https://forums.swift.org/t/se-0290-unavailability-condition/41873">under a review</a>.</p>
<blockquote>
<p>Swift historically supported the <code class="language-plaintext highlighter-rouge">#available</code> condition to check if a specific symbol <strong>is</strong> available for usage, but not the opposite. In this proposal, we’ll present cases where checking for the <strong>unavailability</strong> of something is necessary, the ugly workaround needed to achieve it today and how a new <code class="language-plaintext highlighter-rouge">#unavailable</code> condition can fix it.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/support-negative-availability-literals/39946">Discussion thread topic for that proposal</a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a>: <em>Package Collections</em> is <a href="https://forums.swift.org/t/se-0291-package-collections/41905">under a review</a>.</p>
<blockquote>
<p>This is a proposal for adding support for Package Collections to SwiftPM. A package feed is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these collections, search them via the swift package-collections command-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package collections.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/racer_girl27">Nicole Jacque</a> described <a href="https://forums.swift.org/t/swift-5-4-release-process/41936">Swift 5.4 release process</a>.</p>
<blockquote>
<p>Downloadable snapshots of the Swift 5.4 release branch will be posted regularly as part of <a href="https://ci.swift.org/">continuous integration</a> testing. As support is available, snapshot downloads will be added for newly supported platforms.</p>
<p>Once Swift 5.4 is released, the official final builds will also be posted in addition to the snapshots.</p>
<p>On <strong>Dec 14, 2020</strong> the <code class="language-plaintext highlighter-rouge">release/5.4</code> branch will be cut in the swift repository and most related project repositories. This will contain the changes that will be released in Swift 5.4. After the branch is cut, changes can be landed on the branch via pull request if they meet the criteria for the release.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/slazarus">Sam Lazarus</a> pitched <a href="https://forums.swift.org/t/proposal-static-member-lookup-on-protocol-metatypes/41946">a proposal</a> that implements static member lookup on protocol metatypes.</p>
<blockquote>
<p>Using static member declarations to provide semantic names for commonly used values is an important tool in API design, reducing type repetition and improving call-site legibility. Currently, when a parameter is generic, there is no effective way to take advantage of these facilities. This proposal aims to relax restrictions on accessing static members via protocol metatypes to afford the same call-site legibility to generic APIs.</p>
</blockquote>
<p><a href="https://twitter.com/MaxDesiatov">Max Desiatov</a> <a href="https://forums.swift.org/t/first-stable-release-of-swiftwasm-5-3-is-now-available/41868">informed</a> that first stable release of <a href="https://github.com/swiftwasm/swift/releases/tag/swift-wasm-5.3.0-RELEASE">SwiftWasm 5.3</a> is now available.</p>
<blockquote>
<p>You may have seen some posts about WebAssembly support in Swift on these forums previously. These were mostly questions and discussions about the toolchain development. Today I’m excited to make an announcement first and foremost for end users of Swift interested in applying it on more platforms.</p>
<p>As a culmination of hard work from many people, the first stable release of SwiftWasm 5.3 is available. It allows you to compile your Swift code to <a href="https://webassembly.org/">WebAssembly</a>, and to interact with the host WebAssembly environment through <a href="https://github.com/swiftwasm/JavaScriptKit">libraries that the SwiftWasm team maintains</a>. WebAssembly is supported in all recently released major browsers, which means you can build browser apps written purely in Swift (although some JavaScript glue code invisible to users is required under the hood). Non-browser Wasm hosts are also supported, such as Node.js, <a href="https://wasmer.io/">Wasmer</a>, or any other <a href="https://wasi.dev/">WASI</a>-compatible hosts.</p>
</blockquote>
<p>Swift on the Server meeting notes:</p>
<ul>
<li><a href="https://forums.swift.org/t/sept-16th-2020/41928">Sept 16th, 2020</a> by <a href="https://forums.swift.org/u/varland">Todd Varland</a></li>
<li><a href="https://forums.swift.org/t/october-14th-2020/42079">October 14th, 2020</a> by <a href="https://twitter.com/johannesweiss">Johannes Weiss</a></li>
<li><a href="https://forums.swift.org/t/september-30th-2020/42072">September 30th, 2020</a> by <a href="https://twitter.com/tanner0101">Tanner Nelson</a></li>
</ul>
<p><a href="https://forums.swift.org/u/David_Ask">David Ask</a> <a href="https://forums.swift.org/t/custom-aws-cloudformation-resources-and-macros-using-swift-aws-lambda-runtime/41935">shared</a> custom AWS CloudFormation resources and macros using Swift AWS Lambda Runtime.</p>
<p><a href="https://forums.swift.org/u/abertelrud">Anders Bertelrud</a> pitched <a href="https://forums.swift.org/t/pitch-ability-to-declare-executable-targets-in-swiftpm-manifests-to-support-main/41968">an idea</a> to add ability to declare executable targets in SwiftPM manifests.</p>
<blockquote>
<p>The Swift Package Manager doesn’t currently provide a way for a package manifest to declare that a target is the main module of an executable. Instead, SwiftPM infers this by looking for a source file named <code class="language-plaintext highlighter-rouge">main.swift</code> (or <code class="language-plaintext highlighter-rouge">main.c</code> , <code class="language-plaintext highlighter-rouge">main.cpp</code> , etc) in the source directory of the target.
…
The most straightforward approach would be allow a target to be marked as executable in the manifest. This could take the form of either a parameter to the <code class="language-plaintext highlighter-rouge">target</code> type or a new target type. There is already an established pattern of using the type itself to denote the kind of target being declared (e.g. <code class="language-plaintext highlighter-rouge">testTarget</code> as a specialization of <code class="language-plaintext highlighter-rouge">target</code> ), so the most natural approach seems to be to add a new <code class="language-plaintext highlighter-rouge">executableTarget</code> type for this purpose.</p>
<p>Using a separate target type in the manifest would also support any future differences between the parameters for an executable target and a library target.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/drexin">Dario Rexin</a> informed about static linking on Linux in Swift 5.3.1.</p>
<blockquote>
<p>I am happy to announce that with the release of Swift 5.3.1 statically linking the Swift <code class="language-plaintext highlighter-rouge">stdlib</code> components is now fully supported on Linux. This includes linking against Dispatch and the different Foundation components. Additionally building self-contained binaries is now possible by manually adding a few linker flags.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/iabudiab">Iskandar Abudiab</a> announced <a href="https://github.com/swiftkube">Swiftkube</a> - Swift tooling for Kubernetes.</p>
<blockquote>
<p>Swift as a language is among the most pleasant to use and it’s seen many advancements in many areas, including the server-side. What’s been lacking, IMHO, is more work put into the whole cloud native landscape, especially Kubernetes.</p>
<p>I hope Swiftkube will contribute towards gapping this bridge.</p>
</blockquote>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> updated us about <a href="https://forums.swift.org/t/availability-checking-for-protocol-conformances/42066">availability checking for protocol conformances</a>.</p>
<blockquote>
<p>I just finished landing a set of changes which fix a hole in Swift’s availability checking model. While this was mostly intended for use by Apple, I feel that it is also worth documenting and communicating to the community since people do ship third-party frameworks that make use of OS availability.</p>
<p>As most of you are aware, Swift’s “availability” feature checks if referenced declarations are going to be available at runtime by comparing the OS version in an @available annotation with the “availability context” of the usage location, which is either the deployment target, an @available annotation on an outer declaration, or an if #available block</p>
</blockquote>
<p><a href="https://github.com/yim-lee/">Yim Lee</a> informed about <a href="https://github.com/apple/swift-evolution/blob/main/proposals/0291-package-collections.md">SE-0291</a>: <em>Package Collections</em> development.</p>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> updated about <a href="https://forums.swift.org/t/pitch-2-protocol-based-actor-isolation/42123">protocol-based actor isolation pitch</a>.</p>
<blockquote>
<p>Thank you for the discussion in the <a href="https://forums.swift.org/t/pitch-protocol-based-actor-isolation/41677/1">previous pitch thread</a>. I’ve learned a lot from your feedback and made several major revisions to the proposal, notably:</p>
<ul>
<li>Simplifying the <code class="language-plaintext highlighter-rouge">ActorSendable</code> requirement to being a marker protocol, eliminating the possibility of implicit deep copies.</li>
<li>Including a <code class="language-plaintext highlighter-rouge">ValueSemantic</code> marker protocol as part of the proposal (but I leave it to Dave and other experts to define exactly what that means).</li>
<li>Defining away the possibility of “expensive” synthesized cross-actor copies in the face of resilience boundaries and other advanced cases.</li>
</ul>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Maybe it’s time for a road trip to visit <a href="https://twitter.com/jckarter/status/1324453480317087744">Swift compilers</a>?</p>
<p><a href="https://twitter.com/simjp/status/1328729653440360450">Pop Quiz</a> by <a href="https://twitter.com/simjp">JP</a>.</p>
Issue #172
https://swiftweeklybrief.com/issue-172
2020-11-05T00:00:00-08:00
2020-11-05T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks have been very active. Swift core team shared an article explaining <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">Swift concurrency roadmap</a> and <a href="https://forums.swift.org/t/concurrency-actors-actor-isolation/41613">multiple</a> <a href="https://forums.swift.org/t/concurrency-interoperability-with-objective-c/41616">other</a> <a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">great</a> <a href="https://forums.swift.org/t/concurrency-asynchronous-functions/41619">resources</a>. I think it will be very exciting to see what is going to happen in near future.</p>
<p>There are awesome news from Swift on the Windows development side. The initial port of the Swift system has <a href="https://github.com/apple/swift-system/pull/6">merged</a>. It’s great to see Swift reaching new horizons and getting one step closer to total <a href="https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/">world domination</a>. It is a famous quote by <a href="https://twitter.com/clattner_llvm">Chris Lattner</a>.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://raycast.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_172" target="_blank">Goodbye Spotlight. Hello Raycast.</a></h4>
<p>Raycast brings the macOS Spotlight experience to your third-party services. Create issues in Jira, merge pull requests in GitHub, or join Zoom calls directly from your desktop. Extendable with scripts and built for macOS with 100% Swift inside.</p>
<p><small><a href="https://raycast.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_172" target="_blank">raycast.com</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> and <a href="https://twitter.com/v_pradeilles">Vincent Pradeilles</a> <a href="https://www.swiftbysundell.com/podcast/84/">talk about</a> Key paths, functions and closures.</p>
<p>In the latest episode of Swift Unwrapped, <a href="https://twitter.com/jesse_squires">Jesse</a>
and <a href="https://twitter.com/simjp">JP</a> talk <a href="https://spec.fm/podcasts/swift-unwrapped/EDeUfIq2">about
Swift Atomics</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/maxdesiatov/">Max Desiatov</a> <a href="https://twitter.com/maxdesiatov/status/1321103814976524288">tweeted</a> that <a href="swift.org">http://swift.org</a> website is not searchable, contains outdated information, and is not translated to any other language. He purposed that it should be open-source. You can head down to the <a href="https://bugs.swift.org/browse/SR-1317">issue</a> and vote there.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/bnbarham">Ben Barham</a> merged <a href="https://github.com/apple/swift/pull/34455">a pull request</a> that fixes missing declarations in the completions list due to their type being invalid.</p>
<p><a href="https://github.com/guitard0g">Josh Learn</a> created <a href="https://github.com/apple/swift/pull/34493">a pull request</a> that resolves <a href="https://bugs.swift.org/browse/SR-13639">SR-13639</a>: <em>Don’t diagnose local type declarations as unreachable</em>.</p>
<p><a href="https://github.com/Azoy">Alejandro Alonso</a> merged <a href="https://github.com/apple/swift/pull/28833">a pull request</a> that implements <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Comparable</code>, and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance for tuples.</p>
<p><a href="https://github.com/milseman">Michael Ilseman</a> merged <a href="https://github.com/apple/swift-system/pull/6">a pull request</a> that adds enough shims and tweaks the types sufficiently to allow building System on Windows.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md">SE-0289</a>: <em>Result builders</em> was <a href="https://forums.swift.org/t/accepted-se-0289-result-builders/41377">accepted</a>.</p>
<blockquote>
<p>This proposal describes result builders, a new feature which allows certain functions (specially-annotated, often via context) to implicitly build up a result value from a sequence of components.</p>
<p>In effect, this proposal allows the creation of a new class of embedded domain-specific languages in Swift by applying builder transformations to the statements of a function. The power of these builder transformations is intentionally limited so that the result preserves the dynamic semantics of the original code: the original statements of the function are still executed as normal, it’s just that values which would be ignored under normal semantics are in fact collected into the result. The use of an ad hoc protocol for the builder transformation leaves room for a wide variety of future extension, whether to support new kinds of statements or to customize the details of the transformation. A similar builder pattern was used successfully for string interpolation in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0228-fix-expressiblebystringinterpolation.md">SE-0228</a>.</p>
<p>Result builders have been a “hidden” feature since Swift 5.1, under the name “function builder”, and the implementation (and its capabilities) have evolved since then. They are used most famously by SwiftUI to declaratively describe user interfaces, but others have also experimented with <a href="https://swiftpack.co/package/akkyie/SyntaxBuilder">building Swift syntax trees</a>, <a href="https://www.dotconferences.com/2020/02/kaya-thomas-swift-techniques-for-testing">testing</a>, <a href="https://github.com/a2/swift-shortcuts">a Shortcuts DSL</a>, <a href="https://github.com/carson-katri/swift-css/blob/master/Sources/CSS/CSSBuilder.swift">a CSS DSL</a>, and <a href="https://forums.swift.org/t/declarative-package-description-for-swiftpm-using-function-builders/28699">an alternative SwiftPM manifest format</a>. There’s a GitHub repository dedicated to <a href="https://github.com/carson-katri/awesome-function-builders">awesome function builders</a> with more applications.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/swift-server/sswg/blob/main/proposals/0016-soto.md">SSWG-0016</a>: <em>Soto for AWS</em> is <a href="https://forums.swift.org/t/sswg-0016-soto-for-aws/41552">under a review</a>.</p>
<blockquote>
<p>Amazon Web Services (AWS) is the largest provider of cloud services. Many companies rely on the systems and automation they provide. These include storage, security, identity, messaging, databases, compute, machine learning and analytics to mention a few.</p>
<p>AWS provides SDKs to interact with their services using the languages Javascript, Go, Python, C#, PHP, C++, Java, Ruby but don’t provide a first-party, fully comprehensive SDK in Swift.</p>
<p>Soto provides a Swift NIO based interface to access all Amazon Web Services.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<h4 id="swift-concurrency-roadmap">Swift Concurrency Roadmap</h4>
<p><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> <a href="https://forums.swift.org/t/swift-concurrency-roadmap/41611">posted</a> the <a href="https://github.com/apple/swift/pull/34517">roadmap</a> about structured concurrency in Swift.</p>
<blockquote>
<p>The end state of these changes will:</p>
<ul>
<li>make asynchronous programming convenient and clear at the point of use,</li>
<li>provide a standard set of language tools and techniques that Swift developers can follow,</li>
<li>improve the performance of asynchronous code through better knowledge at compile time, and</li>
<li>eliminate data races and deadlocks in the same way Swift eliminates memory unsafety.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> and <a href="https://twitter.com/pathofshrines">John McCall</a> <a href="https://forums.swift.org/t/concurrency-actors-actor-isolation/41613">explained</a> about <a href="https://github.com/DougGregor/swift-evolution/blob/actors/proposals/nnnn-actors.md">Actors & actor isolation</a>.</p>
<blockquote>
<p>The <a href="https://en.wikipedia.org/wiki/Actor_model">actor model</a> involves entities called actors. Each actor can perform local computation based on its own state, send messages to other actors, and act on messages received from other actors. Actors run independently, and cannot access the state of other actors, making it a powerful abstraction for managing concurrency in language applications. The actor model has been implemented in a number of programming languages, such as Erlang and Pony, as well as various libraries like Akka (on the JVM) and Orleans (on the .NET CLR).</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://forums.swift.org/t/concurrency-interoperability-with-objective-c/41616">explained</a> how existing APIs from Objective-C would look like.</p>
<blockquote>
<p>Swift’s concurrency feature involves asynchronous functions and actors. While Objective-C does not have corresponding language features, asynchronous APIs are common in Objective-C, expressed manually through the use of completion handlers. This proposal provides bridging between Swift’s concurrency features (e.g., <code class="language-plaintext highlighter-rouge">async</code> functions) and the convention-based expression of asynchronous functions in Objective-C. It is intended to allow the wealth of existing asynchronous Objective-C APIs to be immediately usable with Swift’s concurrency model.</p>
</blockquote>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> <a href="https://forums.swift.org/t/concurrency-asynchronous-functions/41619">described</a> how <code class="language-plaintext highlighter-rouge">async</code> functions which can run on lightweight tasks will look like.</p>
<blockquote>
<p>Our approach borrows heavily from the well-received <code class="language-plaintext highlighter-rouge">async</code> / <code class="language-plaintext highlighter-rouge">await</code> features in many other languages. I’ve included a portion of the proposal below; the full text can be found <a href="https://github.com/DougGregor/swift-evolution/blob/async-await/proposals/nnnn-async-await.md">here</a>. This feature ties in closely with the proposals for <a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">structured concurrency</a> and <a href="https://forums.swift.org/t/concurrency-actors-actor-isolation/41613">actors</a>.</p>
</blockquote>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> <a href="https://forums.swift.org/t/concurrency-structured-concurrency/41622">skeched out</a> how do async tasks interact with each other. It is inspired by Trio and Kotlin.</p>
<blockquote>
<p>Any concurrency design has to provide some way of actually running code concurrently. We propose embracing the approach of structured concurrency, in which concurrent programs are organized into tasks and child tasks rather than simply a sea of formally-unrelated threads and jobs. Structured concurrency allows us to neatly address a large number of systemic problems with task management that would otherwise need a lot of ad hoc support.</p>
</blockquote>
<h4 id="other-topics">Other topics</h4>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> shared <a href="https://docs.google.com/document/d/1OMHZKWq2dego5mXQtWt1fm-yMca2qeOdCl8YlBG1uwg/edit#heading=h.g6mikums3i2o">a document</a> about protocol-based actor isolation.</p>
<blockquote>
<p>I got a chance to <a href="https://docs.google.com/document/d/1OMHZKWq2dego5mXQtWt1fm-yMca2qeOdCl8YlBG1uwg/edit#heading=h.g6mikums3i2o">write up some thoughts</a> on how to address one of the major challenges with the recent <a href="https://forums.swift.org/t/concurrency-actors-actor-isolation/41613/">actor model proposal</a>: how do we ensure that values transferred between actors do not introduce shared mutable state.</p>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> opened <a href="https://forums.swift.org/t/valuesemantic-protocol/41686">a thread</a> about <code class="language-plaintext highlighter-rouge">ValueSemantic</code> protocol.</p>
<p><a href="https://forums.swift.org/u/omax">Max Ovtsin</a> pitched <a href="https://forums.swift.org/t/pitch-2-opt-in-reflection-metadata/41696">a proposal</a> about opt-in reflection metadata.</p>
<blockquote>
<p>Reflection can be a useful thing to create convenient and concise APIs for libraries. This proposal seeks to improve the safety of such APIs and to tackle the binary size problem by introducing a mechanism of selectively keeping reflection metadata only for types that need it and dead strip it for all others. Developers will gain an opportunity to express a requirement to have reflection metadata in source-code.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/kirilltitov">Kirill Titov</a> started <a href="https://forums.swift.org/t/future-of-swift-nio-in-light-of-concurrency-roadmap/41633">a thread</a> about the future of Swift-NIO in light of Concurrency Roadmap.</p>
<blockquote>
<p>So what does it mean for us? Rest in peace <code class="language-plaintext highlighter-rouge">EventLoopFutures</code>? I realise that it’s just a roadmap and a series of pitches, and things might (will) change a lot, but it’s certainly the future, and it’s unlikely that Swift-NIO would want to ignore it.</p>
</blockquote>
<p><a href="https://twitter.com/maxdesiatov/">Max Desiatov</a> pitched <a href="https://forums.swift.org/t/pitch-support-specifying-wasm-features-in-package-manifests/41532">a proposal</a> that would support specifying Wasm features in package manifests.</p>
<blockquote>
<p>As a quick introduction, I need to mention that WebAssembly is a collection of multiple proposals that are at different implementation stages in WebAssembly hosts. The bare minimum is called WebAssembly MVP and is available in all major browsers. Other features such as atomics, SIMD, reference types and many more <a href="https://webassembly.org/roadmap/">are not as widely available</a> (with Safari lagging behind in most of these).</p>
<p>The SwiftWasm team would be happy to start experimenting with atomics, SIMD, and reference types when that is possible. Atomics is a big one, as it unblocks multi-threading support with big parts of core libraries that are currently unavailable in SwiftWasm. We could then make Dispatch and major parts of Foundation available in browsers.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/tomerd">tomerd</a> pitched <a href="https://forums.swift.org/t/package-feeds/41522">a proposal</a> that adds support for Package Feeds to SwiftPM.</p>
<blockquote>
<p>A package feed is a curated list of packages and associated metadata which makes it easier to discover an existing package for a particular use case. SwiftPM will allow users to subscribe to these feeds, search them via the swift package command-line interface, and will make their contents accessible to any clients of libSwiftPM. This proposal is focused on the shape of the command-line interface and the format of configuration data related to package feeds.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/roth">Samuel Roth</a> proposed <a href="https://forums.swift.org/t/swift-authentication/41489">a pitch</a> that introduces an Authentication package, which will provide lightweight yet opinionated abstractions enabling developers to build secure authentication systems in Swift.</p>
<blockquote>
<p>As adoption of Swift on the server continues to increase, and the server-side Swift ecosystem grows (e.g. with introduction of <a href="https://swift.org/blog/swift-service-discovery/">Swift Service Discovery</a>), various approaches to building authentication and authorization mechanisms are likely to pop up. Swift Authentication seeks to address the former challenge.</p>
<p>Swift Authentication aims to address sensitive use cases that could have profound security implications. An openly-available package with good documentation (and perhaps more importantly, recommendations) made available in the IDE (Xcode or otherwise) could make Swift an even more attractive solution for building services with authentication requirements.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/drexin">Dario Rexin</a> pitched <a href="https://forums.swift.org/t/codable-synthesis-for-enums-with-associated-values/41493">an idea</a> for codable synthesis for enums with associated values.</p>
<blockquote>
<p>Codable was introduced in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>.
with support for synthesizing Encodable and Decodable conformance for
class and struct types, that only contain values that also conform
to the respective protocols.</p>
<p>Currently auto-synthesis does not work for enums with associated values.
There have been discussions about it in the past, but the concrete structure
of the encoded values was never agreed upon. We believe that having a solution
for this is an important quality of life improvement.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/johnburkey">John Burkey</a> <a href="https://forums.swift.org/t/proposal-for-swift-actors-and-performance-concurrency-futures/41434">proposed</a> Swift Actors and performance concurrency futures.</p>
<blockquote>
<ol>
<li>
<p>Provide a course grained actor model first, which includes separate of concerns of actor functions, whose definitions live separately from Actors that register to receive those function calls async.</p>
</li>
<li>
<p>Provide a fine grained concurrency model allowing queue safe very high frequency lock free allocations, similar to a generational GC.</p>
</li>
<li>
<p>Provide a concurrency safe logging model. Concurrency safe logging isn’t just not crashing- its safe and performantly managing high frequency logging on n concurrent threads.</p>
</li>
</ol>
</blockquote>
<p><a href="https://forums.swift.org/u/rob">Robert MacEachern</a> started <a href="https://forums.swift.org/t/understanding-swifts-value-type-thread-safety/41406">a conversation</a> about Swift’s value type thread safety and <a href="https://forums.swift.org/u/John_McCall">John McCall</a> <a href="https://forums.swift.org/t/understanding-swifts-value-type-thread-safety/41406/10">told</a> that Swift team is making data races statically impossible as much as possible.</p>
<p><a href="https://forums.swift.org/u/svanimpe">Steven Van Impe</a> <a href="https://forums.swift.org/t/swift-setup-student-friendly-setup-instructions-for-platforms-editors-and-ides-that-support-swift/41381">shared</a> a Swift Setup - student-friendly setup instructions for platforms, editors, and IDEs that support Swift.</p>
<blockquote>
<p>This repository gathers student-friendly setup instructions for platforms, editors, and IDEs that support Swift. The goal of this repository is to support the adoption of Swift as a general purpose cross-platform programming language in (higher) education.</p>
<p>To kickstart the repository, I’ve written instructions for the platforms and editors I’m using in an upcoming programming course, notably <a href="https://github.com/pwsacademy/swift-setup/blob/main/editors/vscode-linux/README.md">Visual Studio Code</a> (with SourceKit-LSP and CodeLLDB) on Ubuntu.</p>
</blockquote>
<p><a href="https://twitter.com/bradleymackey">Bradley Mackey</a> pitched <a href="https://forums.swift.org/t/platform-aliases/41768">a proposal</a> to add platform aliases.</p>
<blockquote>
<p>The least disruptive and backwards compatible solution appears to be Platform Aliasing, which can reduce an annotation like this…</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@available(macOS 10.16, iOS 14.0, watchOS 7.0, tvOS 14.0, *)
</code></pre></div> </div>
<p>…to something as simple as this…</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>@available(apple 2020, *)
</code></pre></div> </div>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/AirspeedSwift/status/1319496328079044608">These Great British Bake Off challenges are getting tough.</a></p>
<p><a href="https://twitter.com/jckarter/status/1322339838691930112">RC or GM?</a></p>
Issue #171
https://swiftweeklybrief.com/issue-171
2020-10-22T00:00:00-07:00
2020-10-22T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks were somewhat slow in the Swift open source world but then Apple published yet another open-source library - <a href="https://github.com/apple/swift-service-discovery">Swift Service Discovery</a>. Apart from the announcement of the new iPhones we had some weird times with Xcode 12.1 and 12.2 beta 3 🤔.</p>
<p>To continue sending out this newsletter to your emails, we are looking for sponsors to cover the cost of the platform we are using. More info about that can be found <a href="https://swiftweeklybrief.com/sponsorship/">here</a>. Or you can reach out to me personally on Twitter <a href="https://twitter.com/fassko">@fassko</a>. Thanks! 🙏</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest episode of Swift Unwrapped, <a href="https://twitter.com/jesse_squires">Jesse</a>
and <a href="https://twitter.com/simjp">JP</a> talk <a href="https://spec.fm/podcasts/swift-unwrapped/1DMLbJg5">about
Implementing the Swift Runtime in Swift</a>, with <a href="https://twitter.com/UINT_MIN">Jordan Rose</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://github.com/yim-lee/">Yim Lee</a> wrote <a href="https://swift.org/blog/swift-service-discovery/">a blog post</a> to announce a new open-source project for the Swift Server ecosystem, <a href="https://github.com/apple/swift-service-discovery">Swift Service Discovery</a>.</p>
<p>The vapor team announced notable <a href="https://github.com/vapor/vapor/issues/2507">core team changes</a>.</p>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> tweeted a refresher about <a href="https://twitter.com/Catfish_Man/status/1318448928048623616">copy-on-write values in Swift</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/34246">a pull request</a> that removes 3 of our name lookup implementations in favor of the shiny new <code class="language-plaintext highlighter-rouge">ASTScope</code>, the 4th implementation to rule them all. Now, 1 is gone entirely and 1 is off by default. Also, this six-year old (!) feature request fell out easily. This fixes <a href="https://bugs.swift.org/browse/SR-10069">SR-10069</a>.</p>
<p><a href="https://github.com/zoecarver">Zoe Carver</a> opened <a href="https://github.com/apple/swift/pull/33053">a pull request</a> that adds rudimentary support for C++ template functions in Swift.</p>
<p><a href="https://github.com/keith">Keith Smiley</a> created <a href="https://github.com/apple/swift/pull/34227">a pull request</a> that adds a check validating the current Xcode version is supported for building. It also fixes <a href="https://bugs.swift.org/browse/SR-13497">SR-13497</a>.</p>
<p><a href="https://github.com/LucianoPAlmeida">Luciano Almeida</a> merged <a href="https://github.com/apple/swift/pull/34330">a pull request</a> fixes the crash on <code class="language-plaintext highlighter-rouge">simplifyFix</code> constraint for tuple mismatch and fixes <a href="https://bugs.swift.org/browse/SR-13732">SR-13732</a>.</p>
<p><a href="https://github.com/tbkka">tbkka</a> created <a href="https://github.com/apple/swift/pull/15474">a pull request</a> that replaces the current implementation of <code class="language-plaintext highlighter-rouge">description</code> and
<code class="language-plaintext highlighter-rouge">debugDescription</code> for the standard floating-point types with a new
formatting routine that provides both improved performance and
better results. It fixes multiple bugs - <a href="https://bugs.swift.org/browse/SR-106">SR-106</a>, <a href="https://bugs.swift.org/browse/SR-454">SR-454</a>, <a href="https://bugs.swift.org/browse/SR-491">SR-491</a>, <a href="https://bugs.swift.org/browse/SR-3131">SR-3131</a>.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/artemc">ArtemC</a> shared [an update] about <a href="https://github.com/apple/swift-driver">swift-driver</a> project.</p>
<blockquote>
<p>After its <a href="https://forums.swift.org/t/new-project-announcement-swift-compiler-driver-reimplementation-in-swift/29696">announcement</a> almost exactly a year ago, the <a href="https://github.com/apple/swift-driver">swift-driver</a> project is moving full-steam-ahead towards the goal of replacing its C++ predecessor. Recent weeks saw a large amount of activity on the swift-driver repository towards achieving that goal.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/staticvoidman">staticVoidMan</a> started <a href="https://forums.swift.org/t/padding-arrays/41041">a discussion</a> about proposal to pad <code class="language-plaintext highlighter-rouge">Arrays</code> till a certain minimum length.</p>
<blockquote>
<p>This will be useful when the array is of an arbitrary length but we need at least some minimum length to work with, so padding the array with default values is a conventional way to handle such a scenario.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>let arr = [10,20,30]
let res = arr.padding(repeating: 0, inLength: 7)
print(res) // -> [10,20,30,0,0,0,0]
</code></pre></div> </div>
</blockquote>
<p><a href="https://forums.swift.org/u/morten_bek_ditlevsen">Morten Bek Ditlevsen</a> asked <a href="https://forums.swift.org/t/requesting-help-with-stdlib-testing/41198">a question</a> how to test <code class="language-plaintext highlighter-rouge">stdlib</code>. <a href="https://forums.swift.org/t/requesting-help-with-stdlib-testing/41198/2">Lot</a> of <a href="https://forums.swift.org/t/requesting-help-with-stdlib-testing/41198/3">people</a> <a href="https://forums.swift.org/t/requesting-help-with-stdlib-testing/41198/6">replied</a> with information that can be helpful in future.</p>
<p><a href="https://forums.swift.org/u/jumhyn">Frederick Kellison-Linn</a> pitched <a href="https://forums.swift.org/t/placeholder-types/41329">a proposal</a> about placeholder types (formerly “partial type annotations”).</p>
<blockquote>
<p>When Swift’s type inference is unable to work out the type of a particular expression, it requires the programmer to provide the necessary type context explicitly. However, all mechanisms for doing this require the user to write out the entire type signature, even if only one portion of that type is actually needed by the compiler.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/partial-type-annotations/41239">Partial type annotations</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/EmilyKager/status/1313303791186268160">Imagine</a> doctors being like “side project checkkkkk 🥼😷👩⚕️”</p>
Issue #170
https://swiftweeklybrief.com/issue-170
2020-10-08T00:00:00-07:00
2020-10-08T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p><a href="https://basthomas.github.io/goodbye-swift-weekly">My last issue</a>. I have had
such a great time writing this newsletter with the help of some great friends,
and I can’t thank all of you enough.</p>
<p>I’m very excited for the future of the newsletter now that Kristaps is taking
it over, with me watching from the sidelines.</p>
<p>All the best,<br />
Bas</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/ilseman/">Michael Ilseman</a> shared that <a href="https://swift.org/blog/swift-system/">Swift System</a>, which provides idiomatic interfaces to system calls and low-level currency types, is now open source!</p>
<p><a href="https://twitter.com/lorentey/">Karoy Lorentey</a> introduced <a href="https://swift.org/blog/swift-atomics/">Swift Atomics</a>, a new open source package that enables direct use of low-level atomic operations in Swift code.</p>
<p><a href="https://twitter.com/k_katsumi/status/1313593242533806081">Kishikawa Katsumi</a> shared the Swift Abstract Syntax Tree (AST) explorer now <a href="https://swift-ast-explorer.com">runs on Swift 5.3</a>.</p>
<p><a href="https://twitter.com/nnnnnnnn/">Nate Cook</a> announced <a href="https://swift.org/blog/swift-algorithms/">Swift Algorithms</a>, a new open-source package of sequence and collection algorithms, along with their related types.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/34097">a pull request</a> adding support for function builders on stored struct properties.</p>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> merged <a href="https://github.com/apple/swift/pull/34109">a pull request</a> adding support for local property wrappers.</p>
<p><a href="https://twitter.com/ktosopl">Konrad Malawski</a> merged <a href="https://github.com/apple/swift-cluster-membership/pull/70">a pull request</a>, introducing metrics to the Scalable Weakly-consistent Infection-style Process Group Membership Protocol (SWIM) implementation.</p>
<p><a href="https://twitter.com/CodaFi_">Robert Widmann</a> merged <a href="https://github.com/apple/swift/pull/34196">a pull request</a> turning on Cross-Module Incremental builds.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/main/proposals/0289-result-builders.md">SE-0289</a>: <em>Result builders</em> is <a href="https://forums.swift.org/t/se-0289-review-2-result-builders/40585">under a second review</a>.</p>
<blockquote>
<p>There were a few concerns that were brought up, with one that clearly stood out: naming. Given this feedback, the core team decided to re-run the review to rename the attribute based on the suggestions that garnered traction during the review. Additional concerns that were brought up were around the documentation of the feature as well as concerns around tooling with things such as diagnostics. There has been work to address this feedback as well with improvements to the <a href="https://github.com/apple/swift-evolution/pull/1182">documentation</a> in the proposal and additional <a href="https://github.com/apple/swift/pull/33972">diagnostics</a> in the compiler.</p>
<p>There was some feedback over additional features such as enabling stateful builders and handling for the <code class="language-plaintext highlighter-rouge">Never</code> and <code class="language-plaintext highlighter-rouge">Void</code> types. These are interesting avenues to explore for future extension; however, the core team believes that they can be reasonably considered by later proposals.</p>
<p>This review is limited to:</p>
<ul>
<li>the name of the feature and its attribute and</li>
<li>arguments that one or more of the suggested extensions will be problematic to explore in the future</li>
</ul>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/ilias_karim">Ilias Karim</a> pitched <a href="https://forums.swift.org/t/proposal-sanity-check-assigning-a-case-statement-to-a-boolean/40584">a proposal</a> improving assigning of a <code class="language-plaintext highlighter-rouge">case</code> statement to a boolean.</p>
<blockquote>
<p>Given that <code class="language-plaintext highlighter-rouge">case</code> can appear in an <code class="language-plaintext highlighter-rouge">if</code> statement without variable assignment, it has me scratch my head a bit why it can’t be used to assign a boolean value.</p>
<p>In other words, seeing as this code works,</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">enum</span> <span class="kt">Enum</span> <span class="p">{</span>
<span class="k">case</span> <span class="n">aCase</span>
<span class="k">case</span> <span class="n">anotherCase</span>
<span class="p">}</span>
<span class="k">let</span> <span class="nv">value</span> <span class="o">=</span> <span class="kt">Enum</span><span class="o">.</span><span class="n">aCase</span>
<span class="k">if</span> <span class="k">case</span> <span class="o">.</span><span class="n">aCase</span> <span class="o">=</span> <span class="n">value</span> <span class="p">{</span>
<span class="nf">print</span><span class="p">(</span><span class="s">"a case"</span><span class="p">)</span>
<span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="nf">print</span><span class="p">(</span><span class="s">"another case"</span><span class="p">)</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>then it follows that this should as well,</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">let</span> <span class="nv">bool</span> <span class="o">=</span> <span class="p">(</span><span class="k">case</span> <span class="o">.</span><span class="n">acase</span> <span class="o">=</span> <span class="n">value</span><span class="p">)</span>
</code></pre></div></div>
<p><a href="https://github.com/filip-sakel">Filip Sakel</a>, <a href="https://twitter.com/AnthonyLatsis">Anthony Latsis</a> and <a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> pitched <a href="https://forums.swift.org/t/unlock-existential-types-for-all-protocols/40665">a proposal</a> to unlock existentials for all protocols.</p>
<blockquote>
<p>Swift currently offers the ability for protocols that meet certain criteria to be used as types. Trying to use an unsupported protocol as a type yields the error <code class="language-plaintext highlighter-rouge">[the protocol] can only be used as a generic constraint because it has 'Self' or associated type requirements</code>. This proposal aims to relax this artificial constraint imposed on such protocols.</p>
</blockquote>
<p><a href="https://twitter.com/reuschj">Justin Reusch</a> shared <a href="https://forums.swift.org/t/a-few-take-aways-from-the-rust-ecosystem/40771">some takeaways</a> from the Rust ecosystem.</p>
<blockquote>
<p>In short, this is a few take-aways from my experience with the Rust ecosystem that we could adopt to make Swift even better:</p>
<ul>
<li>A toolchain manager for Swift</li>
<li>A package registry</li>
<li>More “Swifty” testing</li>
<li>Generated documentation</li>
<li>An online playground</li>
<li>Command-line benchmarking</li>
<li>Make Swift more “self-contained” from Xcode</li>
<li>Reduce the size of the Swift toolchain (if possible)</li>
</ul>
<p>Note that this isn’t really a single proposal, but a number of discussion staters, each of which could be its own proposal.</p>
</blockquote>
<p><a href="https://twitter.com/khanlou">Soroush Khanlou</a> and <a href="https://twitter.com/tim_vermeulen">Tim Vermeulen</a> pitched <a href="https://forums.swift.org/t/sum-with-block/40785">a proposal</a> for a <code class="language-plaintext highlighter-rouge">sum</code> function accepting a closure.</p>
<blockquote>
<p>While Swift’s Sequence models brings a lot of niceties that we didn’t have access to in Objective-C, like map and filter, there are other useful operations on sequences that the standard library doesn’t support yet. One operation that is currently missing is summing numeric values on elements in a sequence.</p>
</blockquote>
<p><a href="https://twitter.com/hollyborla">Holly Borla</a> and <a href="https://github.com/filip-sakel">Filip Sakel</a> pitched <a href="https://forums.swift.org/t/pitch-2-extend-property-wrappers-to-function-and-closure-parameters/40959">a proposal</a> extend Property Wrappers to Function and Closure Parameters.</p>
<blockquote>
<p>Property Wrappers were <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md">introduced in Swift 5.1</a>, and have since become a popular feature abstracting away common accessor patterns for properties. Currently, applying a property wrapper is solely permitted on properties inside of a type context. However, with increasing adoption demand for extending <em>where</em> property wrappers can be applied has emerged. This proposal aims to extend property wrappers to function and closure parameters.</p>
</blockquote>
<p><a href="https://github.com/maxovtsin">Maxim Ovtsin</a> pitched <a href="https://forums.swift.org/t/proposal-opt-in-reflection-metadata/40981">a proposal</a> allowing to opt-in to reflection metadata.</p>
<blockquote>
<p>Reflection can be a useful thing to create convenient and concise APIs for libraries. This proposal seeks to improve the safety of such APIs and to tackle the binary size problem by introducing a mechanism to selectively enable reflection metadata only for types that need it and add a way to express a requirement of reflection metadata for APIs developers.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/vitamin">Jon Gilbert</a> pitched <a href="https://forums.swift.org/t/implement-alvarez-monteiros-typeprivate-possibly-with-one-or-two-extra-restrictions/40994">a proposal</a> to revisit and implement <code class="language-plaintext highlighter-rouge">typeprivate</code>.</p>
<blockquote>
<p>The idea is to add <code class="language-plaintext highlighter-rouge">typeprivate</code> so you can put extensions into separate files to improve code readability without having to resort to <code class="language-plaintext highlighter-rouge">internal</code>. (Currently any extensions that access private stored properties must all be in the file that declares the type, and <code class="language-plaintext highlighter-rouge">fileprivate</code> must be used. However this can lead to bloated code files.)</p>
<p>If the original <code class="language-plaintext highlighter-rouge">typeprivate</code> is seen as too “loose,” here are two extra restrictions that would make <code class="language-plaintext highlighter-rouge">typeprivate</code> unable to be stealthily abused.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>If the emotional support dog is around, you better <a href="https://twitter.com/jckarter/status/1309626612954968065">not make any typos</a>.</p>
Issue #169
https://swiftweeklybrief.com/issue-169
2020-09-24T00:00:00-07:00
2020-09-24T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<h3 id="an-update-on-the-swift-weekly-brief-from-bas">An update on the Swift Weekly Brief from Bas:</h3>
<p>After Jesse moved on to different project after issue #100, I’ve decided to move on to different projects now, too.
I’ll stick around for issue 170, but that’ll be my last. You can read <a href="https://basthomas.github.io/goodbye-swift-weekly">my blog post</a> for more details. It’s been an absolute pleasure contributing to and helping out with this project, working with Jesse and Kristaps, as well as all other <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/graphs/contributors">contributors</a> and <a href="../authors">authors</a>.</p>
<p>I took over the newsletter from Jesse as I wanted to keep this valuable research afloat — helping more than 10.000 subscribers and followers to stay up-to-date with what’s happening in the Swift.org and other Apple open source projects.</p>
<p>As Jesse said in issue 100, this still stands and I hope this project will continue through contributions from the community:</p>
<blockquote>
<p>Gladly Kristaps will be taking over and will remain as the main contributor for Swift Weekly Brief. More contributors however are welcome. If you are interested, please get in touch!</p>
</blockquote>
<p>All the best,
Bas</p>
<hr />
<p>In other news…</p>
<p>The last two weeks were full of surprises and new stuff. Xcode 12 was officially <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-12-release-notes">released</a> along with <a href="https://swift.org/blog/swift-5-3-released/">Swift 5.3</a> as well as Swift <a href="https://hub.docker.com/_/swift">docker images</a>. The Swift repository <a href="https://forums.swift.org/t/updating-branch-names/40412">moved</a> to having a <code class="language-plaintext highlighter-rouge">main</code> branch as its default.</p>
<p>It did not stop there and as a surprise <a href="https://swift.org/blog/swift-on-windows/">Swift on the Windows</a> landed.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13573">SR-13573</a> [SwiftSyntax] Fix Spelling of <code class="language-plaintext highlighter-rouge">CustomReflecatbleTests.swift</code></li>
<li><a href="https://bugs.swift.org/browse/SR-13572">SR-13572</a> [Standard Library] investigate removal of <code class="language-plaintext highlighter-rouge">visualc</code> module</li>
<li><a href="https://bugs.swift.org/browse/SR-13571">SR-13571</a> [Standard Library] build release and debug variants of <code class="language-plaintext highlighter-rouge">swiftrt.obj</code>, <code class="language-plaintext highlighter-rouge">swiftCore</code></li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest episode of Swift Unwrapped, <a href="https://twitter.com/jesse_squires">Jesse</a>
and <a href="https://twitter.com/simjp">JP</a> talk <a href="https://spec.fm/podcasts/swift-unwrapped/DasaMAiV">about
Swift 5.3</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> started <a href="https://belkadan.com/blog/2020/08/Swift-Runtime-Heap-Objects/">a blog series</a> about the Swift runtime. You can give your feedback in this <a href="https://forums.swift.org/t/blog-series-the-swift-runtime/40296">forum thread</a>.</p>
<p><a href="https://twitter.com/maxdesiatov">Max Desiatov</a> wrote <a href="https://desiatov.com/swift-webassembly-2020/">a blog post</a> about the state of Swift for WebAssembly in 2020 (and earlier).</p>
<p><a href="https://tryolabs.com/">Tryolabs</a> shared <a href="https://www.youtube.com/watch?v=WxFPrypPBpU">a video</a> - deep dive into Swift for Tensorflow.</p>
<p><a href="https://twitter.com/compnerd/">Saleem Abdulrasool</a> wrote <a href="https://swift.org/blog/swift-on-windows/">a blog post</a> introducing Swift on Windows.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/33998">a pull request</a> that introduces the <code class="language-plaintext highlighter-rouge">@actorIndependent</code> attribute.</p>
<p><a href="https://twitter.com/lorentey">Karoy Lorentey</a> opened <a href="https://github.com/apple/swift-se-0282-experimental/pull/1">a pull request</a> that implements atomic strong references, which were a fun way to prove the versatility of the atomics API. Incidentally, they may also become a convenient default solution for memory reclamation in concurrent Swift data structures.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/33972">a pull request</a> that extends diagnostics and code completion to help guide developers toward implementing function builders.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0288-binaryinteger-ispower.md">SE-0288</a>: <em>Adding isPower(of:) to BinaryInteger</em> was <a href="https://forums.swift.org/t/accepted-se-0288-adding-ispower-of-to-binaryinteger/40325">accepted</a>.</p>
<blockquote>
<p>Checking some mathematical properties of integers (e.g. parity, divisibility, etc.) is widely used in scientific and engineering applications. Swift brings a lot of convenience when performing such checks, thanks to the relevant methods (e.g. <code class="language-plaintext highlighter-rouge">isMultiple(of:)</code>) provided by the standard library. However there are still some other cases not yet supported. One of those useful checks that are currently missing is to tell if an integer is power of another, of which the implementation is non-trivial. Apart from inconvenience, user-implemented code can bring inefficiency, poor readability, and even incorrectness. To address this problem, this proposal would like to add a public API <code class="language-plaintext highlighter-rouge">isPower(of:)</code>, as an extension method, to the <code class="language-plaintext highlighter-rouge">BinaryInteger</code> protocol.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> discussed <a href="https://forums.swift.org/t/clarify-behavior-of-se-0268-with-a-mutating-getter/40324">how to clarify</a> the behavior of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0268-didset-semantics.md">SE-0268</a> with a mutating getter.</p>
<blockquote>
<p>Namely, if a property wrapper has a mutating getter but a non-mutating setter, and the <code class="language-plaintext highlighter-rouge">didSet</code> body refers to <code class="language-plaintext highlighter-rouge">oldValue</code>, the synthesized setter has to be mutating as well, since it calls the getter to load <code class="language-plaintext highlighter-rouge">oldValue</code>. However in the current implementation, if the <code class="language-plaintext highlighter-rouge">didSet</code> body does not refer to <code class="language-plaintext highlighter-rouge">oldValue</code>, the setter is made non-mutating.</p>
</blockquote>
<p><a href="https://twitter.com/airspeedswift">Ben Cohen</a> addressed <a href="https://forums.swift.org/t/addressing-unimplemented-evolution-proposals/40322">an issue</a> with unimplemented evolution proposals.</p>
<blockquote>
<p>The core team has recently been discussing of a number of proposals that have been accepted but not implemented. You can see a list of these proposals on the <a href="https://apple.github.io/swift-evolution/#?search=Accepted">evolution dashboard</a>.</p>
<p>The core team feels that it’s important to avoid a situation where evolution proposals remain accepted but unimplemented for long periods of time. The main cause of this was eliminated through the requirement that proposals come with an implementation prior to review. Some unimplemented proposals pre-date this rule. Another cause can be proposals that are implemented, but the implementation is not quite ready for production use. Finally, several proposals are mostly implemented, except for some small portion that proved problematic or was missed.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/1oo7">Jonathan G</a> started <a href="https://forums.swift.org/t/update-swift-org-api-guidelines-regarding-get-in-function-names/40294/3">a thread</a> about updating Swift.org API guidelines regarding <strong>get</strong> in function names.</p>
<blockquote>
<p>I think this current situation is a direct consequence of the fact that our Swift API guidelines do not explicitly say not to use <strong>get</strong> for functions that return a value.</p>
</blockquote>
<blockquote>
<p>So my pitch is that we should update the Swift.org API design guidelines with the same basic guidelines about the use of <strong>get</strong> in method names as was found in the Cocoa guidelines</p>
</blockquote>
<p><a href="https://forums.swift.org/u/lily_ballard">Lily Ballard</a> wrote <a href="https://forums.swift.org/t/se-0268-refine-didset-semantics-and-unexpected-interaction-with-exclusive-memory-access/40364">a post</a> explaining an issue with Xcode 12 having unexpected consequences of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0268-didset-semantics.md">SE-0268</a>: new <em>simple</em> <code class="language-plaintext highlighter-rouge">_modify</code> semantics. In short, code that previously ran just fine will now fails at runtime with a simultaneous access error.</p>
<blockquote>
<p>The issue lies in interactions with optional chaining and an assignment expression that references the property. In particular, with the non-simple version, the synthesized <code class="language-plaintext highlighter-rouge">_modify</code> coroutine yields a reference to a stack-allocated copy of the value, and therefore does not hold memory access on the property during the yield. But in the new version, it holds <code class="language-plaintext highlighter-rouge">[modify] [dynamic]</code> access during the yield. Without optional chaining this is generally fine, as the right-hand side of the assignment is evaluated before the _modify is invoked, but with optional chaining it has to defer evaluating the right-hand side until it’s verified that the property’s value is nonnull.</p>
</blockquote>
<p>The <a href="https://swift.org/server/">Swift Server Work Group</a> held two meetings and shared notes:</p>
<ul>
<li><a href="https://forums.swift.org/t/august-19th-2020/40347">August 19th, 2020</a></li>
<li><a href="https://forums.swift.org/t/sept-2nd-2020/40382">Sept 2nd, 2020</a></li>
</ul>
<p><a href="https://twitter.com/compnerd/">Saleem Abdulrasool</a> started <a href="https://forums.swift.org/t/enabling-static-linking-on-windows/40509">a thread</a> discussing about enabling static linking on Windows.</p>
<blockquote>
<p>Windows has definitely come a far way from when it started. However, one feature that still is not available on Windows is static linking. Everything currently requires dynamic linking, which is a bit unfortunate. Although, technically, the Microsoft linker can resolve the imported symbol, it comes at a cost (binary size and runtime overheads, and unnecessary warnings). It would be wonderful to get this issue resolved. Even then, it results in over-exposure of the interfaces, which is another source of issues. However, going the other way has even bigger problems, and given that dynamic linkage is generally preferable, it is what I focused on initially.</p>
</blockquote>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> started [a discussion] about clarifying scoping behavior with local functions.</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/EmilyKager/status/1306653151332720640">Boolshit</a></p>
<p><a href="https://twitter.com/dgregor79/status/1306834844609966080">Singing while working</a></p>
Issue #168
https://swiftweeklybrief.com/issue-168
2020-09-10T00:00:00-07:00
2020-09-10T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks were pretty quiet, but I think it is about to change. I assume we will see a lot going on before the official Apple platform releases. Stay tuned!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13490">SR-13490</a> [Compiler] <code class="language-plaintext highlighter-rouge">compareImports()</code> in <code class="language-plaintext highlighter-rouge">ModuleInterfacePrinting.cpp</code> looks buggy</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> announced the <a href="https://swift.org/blog/swift-cluster-membership/">Swift Cluster Membership</a> - a library that aims to help Swift grow in a new space of server applications: clustered multi-node distributed systems.</p>
<p>Google published <a href="https://github.com/google/swiftlogfirecloud">SwiftLogFireCloud Firebase Extension</a> - a library that can be used as an implementation of Apple’s SwiftLog interface that captures console logs from iOS and, in the future, macOS apps and pushes them to Firebase Cloud Storage as flat files for later review.</p>
<p><a href="https://twitter.com/steipete">Peter Steinberger</a> wrote <a href="https://steipete.com/posts/logging-in-swift/">an article</a> explaining logging in Swift.</p>
<p>Apple posted <a href="https://developer.apple.com/news/?id=3bwfq45y">an article</a> about what’s new in CryptoKit. Great to see that they mention <a href="https://www.dotconferences.com/2020/02/cory-benfield-cryptography-in-swift">a talk</a> from the community organized conference <a href="https://www.dotswift.io/">dotSwift</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/varungandhi-apple">Varun Gandhi</a> merged <a href="https://github.com/apple/swift/pull/33786">a pull request</a> that adds first a pull request guide and getting started guide.</p>
<p><a href="https://github.com/compnerd">Saleem Abdulrasool</a> merged <a href="https://github.com/apple/swift/pull/33770">a pull request</a> that fixes <a href="https://bugs.swift.org/browse/SR-13449">SR-13449</a>: <em>Wrong method call when binary is built with optimizations</em>.</p>
<p><a href="https://github.com/owenv">Owen Voorhees</a> merged <a href="https://github.com/apple/swift/pull/29735">a pull request</a> that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0284-multiple-variadic-parameters.md">SE-0284</a>: <em>Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers</em>.</p>
<p><a href="https://github.com/meg-gupta">Meghana Gupta</a> merged <a href="https://github.com/apple/swift/pull/33722">a pull request</a> that fixes <code class="language-plaintext highlighter-rouge">KnownSafety</code> optimization bugs in <code class="language-plaintext highlighter-rouge">ARCSequenceOpts</code>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0289-function-builders.md">SE-0289</a>: <em>Function builders</em> is <a href="https://forums.swift.org/t/se-0289-function-builders/39889">under review</a>.</p>
<blockquote>
<p>This proposal describes function builders, a new feature which allows certain functions (specially-annotated, often via context) to implicitly build up a value from a sequence of components.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/hassanedesouky">Hassan ElDesouky</a> posted <a href="https://forums.swift.org/t/localization-of-compiler-diagnostic-messages/36412/41">a recap</a> of the Google Summer of Code (GSoC).</p>
<p><a href="https://forums.swift.org/u/artemc">ArtemC</a> gave an update on <a href="https://forums.swift.org/t/explicit-module-builds-the-new-swift-driver-and-swiftpm/36990/17">progress on Explicit Module Builds</a> he, <a href="https://forums.swift.org/u/xi_ge">Xi_Ge</a>, and <a href="https://twitter.com/dgregor79">Douglas_Gregor</a> have been making.</p>
<blockquote>
<p>SwiftPM can now self-host using Explicit Module Builds. The package manager itself is a reasonably complex Swift package, and building it exercises most of the new machinery across the involved components. This was an important milestone for getting the basics of the new compilation flow functional.</p>
</blockquote>
<p><a href="https://twitter.com/rockbruno_">Bruno Rocha</a> pitched <a href="https://forums.swift.org/t/support-negative-availability-literals/39946">a proposal</a> about negative version checks.</p>
<blockquote>
<p>Negative availability checks are important when an API is completely different across versions. In the case of iOS apps that support Scenes, you need a negative availability check in your AppDelegate to account for the fact that UIWindows should be loaded elsewhere in iOS 13+.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/ray_fix">Ray Fix</a> started <a href="https://forums.swift.org/t/throw-on-nil/39970">a discussion</a> about throwing on <code class="language-plaintext highlighter-rouge">nil</code>.</p>
<blockquote>
<p>I find myself wanting to define an operation that converts failable initializers to throwing ones. When I have a throwing initializer contains multiple failing initializers, I think it improves the clarity and readability.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/bitjammer">Ashley Garland</a> asked for <a href="https://forums.swift.org/t/diagnostic-for-undocumented-public-declarations/39980">feedback</a> on emitting a diagnostic when a public declaration does not have a documentation comment.</p>
<p><a href="https://forums.swift.org/u/gregtitus">Greg Titus</a> pitched <a href="https://forums.swift.org/t/standard-library-behavior-change-for-lazymapcollection-prefix-to-act-as-a-sequence/39954">a proposal</a> that would make <code class="language-plaintext highlighter-rouge">LazyMapCollections</code> use the <code class="language-plaintext highlighter-rouge">Sequence</code> behavior for prefix calls, rather than the <code class="language-plaintext highlighter-rouge">Collection</code> behavior.</p>
<p><a href="https://forums.swift.org/u/john_mccall">John McCall</a> started <a href="https://forums.swift.org/t/sil-representations-for-async-functions/40021">a discussion</a> on how to represent <code class="language-plaintext highlighter-rouge">async/await</code> in SIL.</p>
<p><a href="https://forums.swift.org/u/alessioburatti">Alessio Buratti</a> asked <a href="https://forums.swift.org/t/question-about-usable-from-inline-in-swiftnio/40095">a question</a> of why <code class="language-plaintext highlighter-rouge">@usableFromInline</code> is preferred to <code class="language-plaintext highlighter-rouge">private</code>.</p>
<blockquote>
<p>This is a great question! To answer it thoroughly we need to take a digression into the Swift optimiser and optimisation boundaries, but the TL;DR is that <code class="language-plaintext highlighter-rouge">@usableFromInline</code> is required to make substantial chunks of NIO perform better.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/dannys42">Danny Sung</a> posted <a href="https://forums.swift.org/t/community-1st-steps-github-org-transition/40114">news</a> about the Kitura migration to a GitHub organization.</p>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> asked <a href="https://forums.swift.org/t/guarantee-in-memory-tuple-layout-or-dont/40122">a question</a>: Are non-homogeneous tuples guaranteed to use the in-order, rounding-up layout that frozen structs on Apple platforms use?</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/AirspeedSwift/status/1302296452798885888">Swifty Good vibes</a>.</p>
Issue #167
https://swiftweeklybrief.com/issue-167
2020-08-27T00:00:00-07:00
2020-08-27T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Here’s a fresh update on everything going on in Swift in open source. Like
every other week, really! It continues to be a pleasure being able to write and
share this newsletter with you, keeping a digestable overview of changes.</p>
<p>Enjoy the brief!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13255">SR-13255</a> [swift-driver]
Darwin-specific argument validation</li>
<li><a href="https://bugs.swift.org/browse/SR-13385">SR-13385</a> [Compiler] Improved
diagnostics when using instance methods before initialization</li>
<li><a href="https://bugs.swift.org/browse/SR-13388">SR-13388</a> [Compiler] Add Fix-Its to
“override” mismatch</li>
<li><a href="https://bugs.swift.org/browse/SR-13445">SR-13445</a> [Compiler] Replace uses of
the word “accessor” in diagnostics with user-facing terminology</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/stephentyrone/status/952682853309009921">Steve Canon</a>
shared <a href="https://forums.swift.org/t/0-0-7-release-notes/39680">update notes</a> for
Swift Numerics 0.0.7.</p>
<p><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> wrote <a href="https://twitter.com/AirspeedSwift/status/1294292068412473347">some thoughts</a>
on deprecating <code class="language-plaintext highlighter-rouge">AnyCollection</code>, allowing for performance optimizations going
forward.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/mikeash">Mike Ash</a> merged <a href="https://github.com/apple/swift/pull/33487">a pull request</a>
reimplementing protocol conformance caching, improving its performance.</p>
<blockquote>
<p>[..] checks should be 10-100x faster once cached</p>
</blockquote>
<p>🏎!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0287-implicit-member-chains.md">SE-0287</a>: <em>Extend implicit member syntax to cover chains of member references</em> was <a href="https://forums.swift.org/t/accepted-se-0287-extend-implicit-member-syntax-to-cover-chains-of-member-references/39714">accepted</a>.</p>
<blockquote>
<p>The feedback was overwhelmingly positive. Accordingly, SE-0287 is accepted.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0288-binaryinteger-ispower.md">SE-0288</a>: <em>Adding <code class="language-plaintext highlighter-rouge">isPower(of:)</code> to <code class="language-plaintext highlighter-rouge">BinaryInteger</code></em> is <a href="https://forums.swift.org/t/se-0288-adding-ispower-of-to-binaryinteger/39736">under review</a>.</p>
<blockquote>
<p>Checking some mathematical properties of integers (e.g. parity, divisibility, etc.) is widely used in scientific and engineering applications. Swift brings a lot of convenience when performing such checks, thanks to the relevant methods (e.g. <code class="language-plaintext highlighter-rouge">isMultiple(of:)</code>) provided by the standard library. However there are still some other cases not yet supported. One of those useful checks that are currently missing is to tell if an integer is power of another, of which the implementation is non-trivial. Apart from inconvenience, user-implemented code can bring inefficiency, poor readability, and even incorrectness. To address this problem, this proposal would like to add a public API <code class="language-plaintext highlighter-rouge">isPower(of:)</code>, as an extension method, to the <code class="language-plaintext highlighter-rouge">BinaryInteger</code> protocol.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> wrote <a href="https://forums.swift.org/t/pitch-2-function-builders/39410">a second proposal pitch</a> for function
builders.</p>
<blockquote>
<p>It has been a long time since the <a href="https://forums.swift.org/t/function-builders/25167">first function builders pitch</a> last year. Since then, we’ve completely <a href="https://forums.swift.org/t/function-builders-implementation-progress/32981">transformed the implementation</a> to get the support for language constructs like local <code class="language-plaintext highlighter-rouge">let</code> bindings, <code class="language-plaintext highlighter-rouge">if let</code>, <code class="language-plaintext highlighter-rouge">switch</code>, and <code class="language-plaintext highlighter-rouge">if #available</code> that we wanted, as well as implementing a new semantic model that makes efficient type checking possible.</p>
<p>Last year’s pitch thread involved a lot of potential expansions to the idea of function builders—things like virtualizing execution, or programmatically inspecting the AST—to broaden their applicability into other domains. None of those have made any visible progress. On the other hand, people have built a number of cool DSLs on top of the experimental function builders implementation, so we feel pretty good that we have a well-rounded feature that makes Swift more expressive. The ad hoc nature of the interaction between the language and function builder types allows us to treat the system we have as the basis, which can be further extended when those ideas come to fruition.</p>
<p>To that end, here is a <a href="https://github.com/DougGregor/swift-evolution/blob/function-builders/proposals/XXXX-function-builders.md">revised proposal</a> for function builders.</p>
</blockquote>
<p><a href="https://twitter.com/CTMacUser">Daryle Walker</a> brought up <a href="https://forums.swift.org/t/bump-on-anysequence-anycollection-conversion/39366">a question</a>
surrounding <code class="language-plaintext highlighter-rouge">AnySequence</code> / <code class="language-plaintext highlighter-rouge">AnyCollection</code> conversion.</p>
<blockquote>
<p>I’m working on something involving <code class="language-plaintext highlighter-rouge">AnySequence</code>. I saw <code class="language-plaintext highlighter-rouge">AnyCollection</code> and its bi-directional and random-access counterparts while reading Apple’s docs. I noticed that the collection versions can all cross convert (unconditionally when going towards a base, fail-able when going away from a base), but the conversion set doesn’t include <code class="language-plaintext highlighter-rouge">AnySequence</code>. Any reason why? In the past few years since the older post, has any new Swift features changed the landscape? Does ABI stability mess anything up?</p>
</blockquote>
<p><a href="https://forums.swift.org/u/peteradams-a">Peter Adams</a> shared <a href="https://forums.swift.org/t/august-5th-2020/39546">meeting notes</a> for the Swift on the Server
workgroup August 5 meeting.</p>
<p><a href="https://github.com/jcampbell05">James Campbell</a> brought up <a href="https://forums.swift.org/t/switch-and-avaliable/39528">a compiler improvement</a> for enum
cases with <code class="language-plaintext highlighter-rouge">@available</code> markers.</p>
<blockquote>
<p>Given the following enum:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">enum</span> <span class="kt">Labels</span><span class="p">:</span> <span class="kt">String</span> <span class="p">{</span>
<span class="k">case</span> <span class="n">foo</span>
<span class="k">case</span> <span class="n">bar</span>
<span class="k">case</span> <span class="n">baz</span>
<span class="kd">@available</span><span class="p">(</span><span class="n">iOS</span> <span class="mi">14</span><span class="p">,</span> <span class="o">*</span><span class="p">)</span>
<span class="k">case</span> <span class="n">notAvailableYet</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>With the following code:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">@avaliable</span><span class="p">(</span><span class="n">iOS14</span><span class="p">,</span> <span class="o">*</span><span class="p">)</span>
<span class="kd">func</span> <span class="nf">foo</span><span class="p">()</span> <span class="p">{</span>
<span class="p">}</span>
<span class="k">switch</span> <span class="n">label</span> <span class="p">{</span>
<span class="k">case</span> <span class="o">.</span><span class="nv">notAvailableYet</span><span class="p">:</span>
<span class="nf">foo</span><span class="p">()</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>The compiler will force you to wrap the call-site for foo() with a availability check even that case is already for an enum which is marked as only being available for the same iOS version.</p>
<p>It would be great if the compile could automatically synthesise this availability check as part of the case statement so it won’t execute that case (If <code class="language-plaintext highlighter-rouge">rawValue</code> was used to dynamically select that enum then perhaps there could be a runtimes error)</p>
</blockquote>
<p>Karl pitched <a href="https://forums.swift.org/t/swift-dynamic-loading-api/39495">a proposal</a> for a Swift dynamic loading API.</p>
<blockquote>
<p>I’ve been wondering if there’s any appetite for a Swift <a href="https://en.wikipedia.org/wiki/Dynamic_loading">dynamic loading</a> API. Basically a Swiftier version of <code class="language-plaintext highlighter-rouge">dlopen</code> and <code class="language-plaintext highlighter-rouge">dlsym</code>, maybe making use of reflection metadata to support more kinds of queries on loaded modules. There is precedent for it: Java has its own <a href="https://docs.oracle.com/javase/10/docs/api/java/lang/ClassLoader.html"><code class="language-plaintext highlighter-rouge">ClassLoader</code></a> API and Go also supports <a href="https://golang.org/pkg/plugin/">plugins</a>.</p>
<p>This could allow for richer interfaces than are currently practical using C interop and <code class="language-plaintext highlighter-rouge">dlsym</code>.</p>
</blockquote>
<p><a href="https://twitter.com/minuscorp">Jorge Revuelta</a> pitched <a href="https://forums.swift.org/t/typed-throws/39660">a proposal</a>
for “typed throws”.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">throws</code> in Swift is missing the possibility to use it with specific error types. On the contrary <a href="https://developer.apple.com/documentation/swift/result"><code class="language-plaintext highlighter-rouge">Result</code></a> and <a href="https://developer.apple.com/documentation/combine/future"><code class="language-plaintext highlighter-rouge">Future</code></a> support specific error types. This is inconsistent without reason. The proposal is about introducing the possibility to support specific error types with <code class="language-plaintext highlighter-rouge">throws</code>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/absoftware">Ariel Bogdziewicz</a> pitched <a href="https://forums.swift.org/t/make-protocols-conforming-to-protocols-as-only-struct-enum-class-types-can-conform-to-protocols-now/39696">a proposal</a> to allow protocols to conform to other protocols.</p>
<blockquote>
<p>My custom container implemented as</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">let</span> <span class="nv">listeners</span> <span class="o">=</span> <span class="kt">Listeners</span><span class="o"><</span><span class="kt">MyListener</span><span class="o">></span><span class="p">()</span>
</code></pre></div></div>
<blockquote>
<p>raises an issue:</p>
</blockquote>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>Value of protocol type 'MyListener' cannot conform to 'ListenerProtocol'; only struct/enum/class types can conform to protocols
</code></pre></div></div>
<blockquote>
<p>It would be nice to make it working for protocols.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/dgregor79/status/1296132733899399169">The <del>Corgi</del> Core Team</a>. 🐶</p>
Issue #166
https://swiftweeklybrief.com/issue-166
2020-08-13T00:00:00-07:00
2020-08-13T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Summer is already in its second half and seems that the Swift community has gained some steam before the official Xcode releases.</p>
<p>Additionally, the people working on Swift on the server have great news about AWS Lambda and Kitura is now a community project!</p>
<p>I think this is a calm before the (autumn) storm. We will have more awesome news in the coming weeks.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest episode of Swift Unwrapped, <a href="https://twitter.com/jesse_squires">Jesse</a>
and <a href="https://twitter.com/simjp">JP</a> talk <a href="https://spec.fm/podcasts/swift-unwrapped/aC5JVWoo">about
package registries and indexes</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://forums.swift.org/u/drexin">Dario Rexin</a> shared that Swift 5.2.5 for Linux <a href="https://forums.swift.org/t/swift-5-2-5-for-linux/39188">has been released</a> and downloads are available on <a href="https://swift.org/download/#swift-525">swift.org</a>.</p>
<p>An <a href="https://www.youtube.com/watch?v=QeG9bdkc3Lk">interview</a> with <a href="https://twitter.com/clattner_llvm">Chris Lattner</a> on the Possibility of Machine Learning-Enabled Compilers.</p>
<p><a href="https://twitter.com/fabianfett">Fabian Fett</a> wrote <a href="https://fabianfett.de/swift-on-aws-lambda-creating-your-first-http-endpoint">a blog post</a> explaining how to create your first HTTP endpoint with Swift on AWS Lambda.</p>
<p><a href="https://twitter.com/mattt">Mattt</a> shared that <a href="https://github.com/SwiftDocOrg/swift-doc/releases/tag/1.0.0-beta.4">swift-doc 1.0.0-beta.4</a> is now available, with several visual and functional bug fixes.</p>
<blockquote>
<p>The next release promises to be the biggest yet, with plans to support DocSet output, along with raw data formats like JSON, RDF, and SQLite. I’m excited to get that out to you all to try out in the next week or two.</p>
</blockquote>
<p><a href="https://twitter.com/tiborbodecs">Tibor Bödecs</a> shared <a href="https://theswiftdev.com/getting-started-with-feather-cms/">a blog post</a> on Feather CMS. A modern Swift-based Content Management System powered by Vapor 4.</p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> tweeted about <a href="https://twitter.com/olebegemann/status/1290673766046011393">how to get up and running with Swift WebAssembly</a>, from writing a simple program to running it in the browser.</p>
<p><a href="https://twitter.com/_HarshilShah">Harshil Shah</a> wrote <a href="https://harshil.net/blog/swift-sequence-collection-array">a blog post</a> explaining Swift’s collection types.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> wrote <a href="https://swiftbysundell.com/articles/deep-dive-into-swift-function-builders/">an article</a> explaining Swift’s function builders.</p>
<p><a href="https://forums.swift.org/u/dannys42">Danny Sung</a> announced <a href="https://forums.swift.org/t/kitura-is-now-a-community-project/39199">Kitura is now a community project</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/YOCKOW_jp">Knock YOCKOW</a> merged <a href="https://github.com/apple/swift/pull/28639">a pull request</a> that fixes SR-10689: <em>Fix bugs of <code class="language-plaintext highlighter-rouge">DataProtocol</code>’s <code class="language-plaintext highlighter-rouge">firstRange(of:in:)</code>/<code class="language-plaintext highlighter-rouge">lastRange(of:in:)</code></em>.</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/33232">a pull request</a> that handles static let variables for String constant folding.</p>
<p><a href="https://github.com/atrick">Andrew Trick</a> merged <a href="https://github.com/apple/swift/pull/33017">a pull request</a> that adds <code class="language-plaintext highlighter-rouge">AccessedStorage::Tail</code> access kind and removes more exclusivity checks.</p>
<p><a href="https://github.com/stephentyrone">Stephen Canon</a> opened <a href="https://github.com/apple/swift/pull/33378">a pull request</a> that adds checks that the endpoints of partial ranges are not-<code class="language-plaintext highlighter-rouge">NaN</code>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/swift-server/sswg/blob/master/proposals/0015-swift-service-lifecycle.md">SSWG-0015</a>: <em>Swift Service Lifecycle</em> is <a href="https://forums.swift.org/t/sswg-0015-swift-service-lifecycle/39157">under review</a>.</p>
<blockquote>
<p>Most services have startup and shutdown workflow-logic which is often sensitive to failure and hard to get right. Startup sequences include actions like initializing thread pools, running data migrations, warming up caches, and other forms of state initialization before taking traffic or accepting events. Shutdown sequences include freeing up resources that hold on to file descriptors or other system resources that may leak if not cleared correctly.</p>
<p>Today, server applications and frameworks must find ways to address the need on their own, which could be error prone. To make things safer and easier, Service Lifecycle codifies this common need in a safe, reusable and framework-agnostic way. It is designed to be integrated with any server framework or directly in a server application’s main.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/matthewcheok">Matthew Cheok</a> pitched <a href="https://forums.swift.org/t/organizing-stored-properties-in-extensions/38902">a proposal</a> on stored properties in extensions.</p>
<blockquote>
<p>A very common pattern for organizing methods is using extensions within the module a type is declared in, in order to group methods semantically or for some other reason. These methods behave as if they are declared within the initial declaration itself and UIKit also uses this system of organization in its (generated) Swift interfaces. However, we can’t do this today with properties because all stored properties need to be declared within the initial declaration.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/richard-clements">Richard Clements</a> pitched <a href="https://forums.swift.org/t/deferred-property-wrappers/38931">a proposal</a> about deferred property wrappers.</p>
<blockquote>
<p>I wanted to make a pitch for a deferred style of property wrapper, that will work with lazy properties only. The purpose is that you would be able to use another (non lazy) property as a dependency for the property wrapper.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/lovee">Elvis Shi</a> pitched <a href="https://forums.swift.org/t/sort-by-min-by-max-by-with-keypaths/38976">a proposal</a> to add <code class="language-plaintext highlighter-rouge">sort(by:)</code> , <code class="language-plaintext highlighter-rouge">min(by:)</code> and <code class="language-plaintext highlighter-rouge">max(by:)</code> with keyPaths.</p>
<blockquote>
<p>[..] now we’ve got the new KeyPath feature, but we still don’t have a convenient method to sort a sequence, or get the max / min element by its elements’ properties</p>
</blockquote>
<p><a href="https://forums.swift.org/u/varland">Todd Varland</a> shared the Swift Server Work Group <a href="https://forums.swift.org/t/july-8th-2020/39092">July 8th, 2020</a> meeting notes, and <a href="https://forums.swift.org/u/peteradams-a">Peter Adams</a> shared the <a href="https://forums.swift.org/t/july-29th-2020/39107">July 29th, 2020</a> meeting notes.</p>
<p><a href="https://twitter.com/lorentey">Karoy Lorentey</a> pitched <a href="https://forums.swift.org/t/ironing-out-managedbuffer-api-wrinkles/39072">a proposal</a> on how to iron out the <code class="language-plaintext highlighter-rouge">ManagedBuffer</code> API wrinkles.</p>
<blockquote>
<p>As uncovered in <a href="https://github.com/apple/swift/pull/31686">PR #31686</a>, the API of <code class="language-plaintext highlighter-rouge">ManagedBuffer</code> (and it’s less-liked sibling <code class="language-plaintext highlighter-rouge">ManagedBufferPointer</code>) implicitly assume that it’s possible to easily retrieve the size of a dynamically allocated chunk of memory. Platforms often allow this through functions like <code class="language-plaintext highlighter-rouge">malloc_size</code>, <code class="language-plaintext highlighter-rouge">malloc_usable_size</code> or <code class="language-plaintext highlighter-rouge">_msize</code> — but it turns out not all of them do. In particular, OpenBSD evidently doesn’t support this.</p>
<p>This makes these stdlib APIs suboptimal — on OpenBSD, the implementation would need to bend over backwards store the allocated capacity within the class instance, even though it is practically always duplicated in <code class="language-plaintext highlighter-rouge">Header</code>. The extra storage would waste memory and complicate element access in every <code class="language-plaintext highlighter-rouge">ManagedBuffer</code> instance, even in the (hopefully) vast majority of cases where <code class="language-plaintext highlighter-rouge">ManagedBuffer.capacity</code> is never called outside of the closure passed to the <code class="language-plaintext highlighter-rouge">create</code> method.</p>
<p>I believe the stdlib’s APIs shouldn’t be needlessly difficult to implement on particular platforms. <code class="language-plaintext highlighter-rouge">ManagedBuffer</code>’s implicit requirement for a working <code class="language-plaintext highlighter-rouge">malloc_size</code> seems unreasonable.</p>
<p>This seems like as good an excuse as any to start discussing a revision of these APIs.</p>
</blockquote>
<p><a href="https://github.com/maustinstar">Michael Verges</a> pitched <a href="https://forums.swift.org/t/package-manager-executable-only-dependencies/39070">a proposal</a> that executable-only dependencies would allow packages to be imported only for use in the package’s development environment.</p>
<blockquote>
<p>CLI tools distributed through Swift Packages, such as linters or documentation generators, are currently imported as dependencies. Although these dependencies may only exist to use as an executable during development, the dependencies are shipped with the package. End-users of a package do not need to inherit development tools from the package.</p>
<p>This can encourage package developers to use more developer tools without frustrating end-users with unused dependencies.</p>
</blockquote>
<p><a href="https://twitter.com/tanner0101">Tanner Nelson</a> pitched <a href="https://forums.swift.org/t/generic-connection-pool/39161">a proposal</a> to implement a Generic Connection Pool.</p>
<blockquote>
<p>Connection pooling is a critical component for many server-side applications. I would attempt to summarize connection pooling here, but honestly <a href="https://en.wikipedia.org/wiki/Connection_pool">Wikipedia’s page</a> does a better job:</p>
<blockquote>
<p>In software engineering, a connection pool is a cache of database connections maintained so that the connections can be reused when future requests to the database are required. Connection pools are used to enhance the performance of executing commands on a database.</p>
</blockquote>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jeanqasaur/status/1290883041418649600">Taylor Swift as classic programming textbooks</a>.</p>
<p>Sometimes debugging can be quite <a href="https://twitter.com/aalonso128/status/1293418352023613440">“fun”</a>.</p>
Issue #165
https://swiftweeklybrief.com/issue-165
2020-07-30T00:00:00-07:00
2020-07-30T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>If you haven’t heard about it yet, we’ve been seeing a start to <code class="language-plaintext highlighter-rouge">async</code> /
<code class="language-plaintext highlighter-rouge">await</code> in Swift these past two weeks. While this will take a <em>lot</em> more time
before we can expect to see this land in Swift, it is an exciting thing to see.
🏎</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> discusses <a href="https://www.swiftbysundell.com/podcast/78">what’s new in Swift
5.3</a> with <a href="https://twitter.com/simjp">JP Simard</a>.</p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13237">SR-13237</a> [Compiler] Remove
<code class="language-plaintext highlighter-rouge">ModuleDecl::isClangModule()</code></li>
<li><a href="https://bugs.swift.org/browse/SR-13245">SR-13245</a> [Compiler] Refactor
construction of <code class="language-plaintext highlighter-rouge">ModuleDecl::ImportFilter</code>s to use new initializer list
constructor</li>
<li><a href="https://bugs.swift.org/browse/SR-13246">SR-13246</a> [Compiler] Refactor manual
size calculations to use <code class="language-plaintext highlighter-rouge">totalSizeToAlloc</code></li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/k__mahar">Kaitlin Mahar</a>, <a href="https://github.com/tachyonics">Simon Pilkington</a>,
and Todd Varland join the <a href="https://forums.swift.org/t/july-29th-2020-special-update/38869">Swift Server Workgroup</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/33147">a pull request</a>
that adds <code class="language-plaintext highlighter-rouge">async</code> to the Swift type system.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> opened <a href="https://github.com/apple/swift/pull/33196">a pull request</a>
stubbing out an experimental concurrency support library.</p>
<p><a href="https://twitter.com/benlangmuir">Ben Langmuir</a> merged <a href="https://github.com/apple/sourcekit-lsp/pull/298">a pull request</a>
that contains a big speedup for code-completion in SourceKit-LSP.</p>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> merged <a href="https://github.com/apple/swift-argument-parser/pull/123">a pull request</a>,
allowing for autocompletion in the Swift argument parser.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0286-forward-scan-trailing-closures.md">SE-0286</a>: <em>Forward-scan matching for trailing closures</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0286-forward-scan-for-trailing-closures/38836">accepted with modifications</a>.</p>
<blockquote>
<p>Initial feedback on the review was generally positive on the concept, but
several reviewers were troubled by the potential for source incompatibilities.
The proposal author investigated options for maintaining compatibility better,
and when they seemed to work out, the core team elected to amend the proposal
during review. The community then expressed strong support for the revised
proposal, and the feeling among reviewers was that there was no need for a
second review. The core team discussed this and agreed. Accordingly, the
revised proposal is accepted with modifications.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0285-ease-pound-file-transition.md">SE-0285</a>: <em>Ease the transition to concise magic file strings</em> was <a href="https://forums.swift.org/t/accepted-se-0285-ease-the-transition-to-concise-magic-file-strings/38516">accepted</a>.</p>
<blockquote>
<p>The feedback was generally positive, and to address the concern around which
variants of <code class="language-plaintext highlighter-rouge">#file</code> library authors should use the proposal was modified to
include <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0285-ease-pound-file-transition.md#swift-api-design-guidelines-amendment">Swift API Design Guidelines amendment</a>
encouraging library authors to prefer <code class="language-plaintext highlighter-rouge">#fileID</code> over alternatives.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0284-multiple-variadic-parameters.md">SE-0284</a>: <em>Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers</em> was <a href="https://forums.swift.org/t/accepted-se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38567">accepted</a>.</p>
<blockquote>
<p>Some reviewers indicated that they would prefer to format code in certain
ways to aid with legibility, but the functionality itself was well received.
The core team noted that this was an oversight in the original implementation
and should have been permitted in the original implementation.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0286-forward-scan-trailing-closures.md">SE-0286</a>: <em>Forward-scan matching for trailing closures</em> is <a href="https://forums.swift.org/t/se-0286-forward-scan-for-trailing-closures/38529">under review</a>.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md">SE-0279 “Multiple Trailing Closures”</a>
threaded the needle between getting the syntax we wanted for multiple trailing
closures without breaking source compatibility. One aspect of that compromise
was to extend (rather than replace) the existing rule for matching a trailing
closure to a parameter by scanning <em>backward</em> from the end of the parameter
list.</p>
<p>However, the backward-scan matching rule makes it hard to write good API that
uses trailing closures, especially multiple trailing closures. This proposal
replaces the backward scan with a forward scan wherever possible, which is
simpler, more in line with normal argument matching in a call, and works better
for APIs that support trailing closures (whether single or multiple) and
default arguments. This change introduces a <em>minor source break</em> for code
involving multiple, defaulted closure parameters, but that source break is
staged over multiple Swift versions.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Karl pitched <a href="https://forums.swift.org/t/shared-substrings/38547">a proposal</a>
for Shared Substrings.</p>
<blockquote>
<p>Shared Substrings give us a way to interpret buffers of bytes as unicode
text, without allocating new storage exclusively owned by a <code class="language-plaintext highlighter-rouge">String</code> object.
It would, for example, allow developers to receive data from a file or network
connection as an <code class="language-plaintext highlighter-rouge">Array<UInt8></code> or Foundation <code class="language-plaintext highlighter-rouge">Data</code> object, and parse that
data as text without copying it. Additionally, it gives developers of
structured text objects (like URLs) greater control over how they organise
their storage.</p>
</blockquote>
<p><a href="https://twitter.com/mattt">Mattt</a> pitched <a href="https://forums.swift.org/t/package-manager-source-archive-dependencies/38626">a proposal</a>
to support non-binary source dependencies in the Swift Package Manager.</p>
<blockquote>
<p>Swift Package Manager added support for binary dependencies with <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0272-swiftpm-binary-dependencies.md">SE-0272</a>.
This proposal extends that functionality to support non-binary source
dependencies as well.</p>
<p>Swift Package Manager requires a source dependency to be hosted in a Git
repository with a package manifest located in its root. This can cause
problems for projects with a different directory structure or that use a
version control system other than Git.</p>
</blockquote>
<p><a href="https://twitter.com/_HarshilShah">Harshil Shah</a> pitched <a href="https://forums.swift.org/t/lazy-filter-subscripts/38743">a proposal</a>
for Lazy Filter Subscripts.</p>
<blockquote>
<p>In playing around with the standard library’s <code class="language-plaintext highlighter-rouge">Sequence</code> types, I noticed an
unexpected behaviour.</p>
<p>The current implementation of <code class="language-plaintext highlighter-rouge">LazyFilterCollection</code> uses the indices of the
base collection as its own, and also forwards any subscripts directly to the
base collection.</p>
<p>This means that it is possible to retrieve values via subscripting that
shouldn’t exist in the filtered collection:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">let</span> <span class="nv">evenDigits</span> <span class="o">=</span> <span class="kt">Array</span><span class="p">(</span><span class="mi">0</span> <span class="o">..<</span> <span class="mi">10</span><span class="p">)</span><span class="o">.</span><span class="kd">lazy</span><span class="o">.</span><span class="n">filter</span> <span class="p">{</span> <span class="nv">$0</span><span class="o">.</span><span class="nf">isMultiple</span><span class="p">(</span><span class="nv">of</span><span class="p">:</span> <span class="mi">2</span><span class="p">)</span> <span class="p">}</span>
<span class="nf">print</span><span class="p">(</span><span class="n">evenDigits</span><span class="p">[</span><span class="mi">3</span><span class="p">])</span> <span class="c1">// prints 3</span>
</code></pre></div></div>
<blockquote>
<p>And it also means that indices which don’t exist in the filtered collection
can be subscripted:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">let</span> <span class="nv">evenDigits</span> <span class="o">=</span> <span class="kt">Array</span><span class="p">(</span><span class="mi">0</span> <span class="o">..<</span> <span class="mi">10</span><span class="p">)</span><span class="o">.</span><span class="kd">lazy</span><span class="o">.</span><span class="n">filter</span> <span class="p">{</span> <span class="nv">$0</span><span class="o">.</span><span class="nf">isMultiple</span><span class="p">(</span><span class="nv">of</span><span class="p">:</span> <span class="mi">2</span><span class="p">)</span> <span class="p">}</span>
<span class="nf">print</span><span class="p">(</span><span class="n">evenDigits</span><span class="p">[</span><span class="mi">5</span><span class="p">])</span> <span class="c1">// prints 5</span>
<span class="nf">print</span><span class="p">(</span><span class="kt">Array</span><span class="p">(</span><span class="n">eventDigits</span><span class="p">[</span><span class="mi">5</span><span class="o">...</span><span class="p">]))</span> <span class="c1">// prints [6, 8]</span>
</code></pre></div></div>
<blockquote>
<p>This behaviour isn’t currently documented.</p>
</blockquote>
<p><a href="https://twitter.com/reuschj">Justin Reusch</a> pitched <a href="https://forums.swift.org/t/memoization-of-swift-properties/38783">a proposal</a>
to allow Memoization of Swift properties.</p>
<blockquote>
<p>Swift has a focus on being fast and efficient. To this goal, the memoization
of computed properties would help to speed up some Swift programs relying on
computed values (especially expensive ones) by only re-calculating the results
when one of the properties they depend on has changed.</p>
<p>Anyone familiar with React and React hooks will know one of the most useful
hooks is <a href="https://reactjs.org/docs/hooks-reference.html#usememo">React’s <code class="language-plaintext highlighter-rouge">useMemo</code></a>,
which provides this exact functionality for rendering UIs. While memoization
would be broadly applicable to any Swift program, it may be especially helpful
for use in SwiftUI, where preventing unnecessary re-renders can help optimize
app performance.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Swift <a href="https://twitter.com/clattner_llvm/status/1284156940747042817">is more than 10 years old, now</a>!</p>
Issue #164
https://swiftweeklybrief.com/issue-164
2020-07-16T00:00:00-07:00
2020-07-16T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Another two weeks have passed, so here’s another “Weekly” Brief. There’s lots
of energy within the community at the moment, it seems — as there’s a lot going
on.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://engineering.linecorp.com/en/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_164" target="_blank">LINE loves Swift!</a></h4>
<p>LINE is the leading mobile messaging platform in Japan and boasts one of the largest Swift codebases in Asia. In addition to supporting Swift versions from day 1, we strongly value semantics, protocols, and strongly typed systems. Many of our members are also active in the OSS community and support both local and global meetups and peer labs. Come join us and see what Swift can do in the real world.</p>
<p><small><a href="https://engineering.linecorp.com/en/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_164" target="_blank">engineering.linecorp.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-13119">SR-13119</a> [Compiler] Confusing
diagnostic when checking conformance for IUO of generic parameter</li>
<li><a href="https://bugs.swift.org/browse/SR-13092">SR-13092</a> [Parser] <code class="language-plaintext highlighter-rouge">operator $</code>
produces two contradictory error messages</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> discusses <a href="https://www.swiftbysundell.com/podcast/76/">what’s been going on
with SwiftUI</a> with <a href="https://twitter.com/joshshaffer">Josh Shaffer</a>
and <a href="https://twitter.com/elizablock">Eliza Block</a> from Apple.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tomerdoron/">Tom Doron</a> announced <a href="https://swift.org/blog/swift-service-lifecycle/">Swift Service Lifecycle</a>,
a new open source project for the Swift server ecosystem. It is a Swift package
designed to help server applications, also known as services, manage their
startup and shutdown sequences.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/mishaldshah">Mishal Shah</a> merged <a href="https://github.com/apple/swift/pull/32705">a pull request</a>
that adds Apple Silicon support to the Swift continuous integration.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0284-multiple-variadic-parameters.md">SE-0284</a>: <em>Allow Multiple Variadic Parameters in Functions, Subscripts, and Initializers</em> is <a href="https://forums.swift.org/t/se-0284-allow-multiple-variadic-parameters-in-functions-subscripts-and-initializers/38225">under review</a>.</p>
<blockquote>
<p>Currently, variadic parameters in Swift are subject to two main restrictions:</p>
<ul>
<li>Only one variadic parameter is allowed per parameter list</li>
<li>If present, the parameter which follows a variadic parameter must be labeled</li>
</ul>
<p>This proposal seeks to remove the first restriction while leaving the second
in place, allowing a function, subscript, or initializer to have multiple
variadic parameters so long as every parameter which follows a variadic one
has a label.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0285-ease-pound-file-transition.md">SE-0285</a>: <em>Ease the transition to concise magic file strings</em> is <a href="https://forums.swift.org/t/se-0285-ease-the-transition-to-concise-magic-file-strings/38234">under review</a>.</p>
<blockquote>
<p>In <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274</a>,
the core team accepted a proposal to change the behavior of <code class="language-plaintext highlighter-rouge">#file</code>. This
proposal modifies that plan to transition into new behavior more gradually,
treating it as a source break requiring a new language version mode to fully
adopt.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/stephentyrone">Steve Cannon</a> shared the <a href="https://forums.swift.org/t/0-0-6-release-notes/38146">release notes</a>
for Swift Numerics 0.0.6.</p>
<p><a href="https://twitter.com/theloniousMonad">Nicholas Maccharoli</a> pitched <a href="https://forums.swift.org/t/revisiting-se-0177-adding-clamped-to/38332">a proposal</a>
to revist <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0177-add-clamped-to-method.md">SE-0177</a>: <code class="language-plaintext highlighter-rouge">clamped(to:)</code>.</p>
<blockquote>
<p>It has been a while since SE-0177 was sent back for revision (three years?)
and it might be worth it to start a new thread here about what to do with
SE-0177.</p>
<p>At the moment I have one pull request for the Swift Evolution repository and
another pull request adding <code class="language-plaintext highlighter-rouge">clamped</code> as an extension on <code class="language-plaintext highlighter-rouge">Comparable</code> to the
standard library.</p>
<p>I would love to start this discussion with everyone about what to do next
until
SE-0177 is complete.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79/status/1279292206017200128">Doug Gregor</a> pitched
<a href="https://forums.swift.org/t/pitch-2-forward-scan-matching-for-trailing-closures/38491">a proposal</a>
for forward scan matching for trailing closures.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md">SE-0279 “Multiple Trailing Closures”</a>
threaded the needle between getting the syntax we wanted for multiple trailing
closures without breaking source compatibility. One aspect of that compromise
was to extend (rather than replace) the existing rule for matching a trailing
closure to a parameter by scanning backward from the end of the parameter list.</p>
<p>I propose that we replace the backward scan used by the trailing closure
matching rules with a forward scan, which is simpler and works better for APIs
that support trailing closures (whether single or multiple) as well as default
arguments. This is a source-breaking change that affects a small amount of
code: I propose that we take the first (smallest) part of this source break
immediately, to be finished by a slightly larger source break in Swift 6.</p>
</blockquote>
<blockquote>
<p>To get a feel for the new behavior, it really helps to write some code against
it. I <a href="https://github.com/apple/swift/pull/32891">implemented this proposal</a>
in the Swift compiler, and have built both a <a href="https://ci.swift.org/job/swift-PR-toolchain-Linux/389//artifact/branch-master/swift-PR-32891-389-ubuntu16.04.tar.gz">Linux</a>
and a <a href="https://ci.swift.org/job/swift-PR-toolchain-osx/558//artifact/branch-master/swift-PR-32891-558-osx.tar.gz">macOS</a>
toolchain that support it. <a href="https://swift.org/download/#using-downloads">Using this toolchain</a>,
you can experiment with the new behavior. Please try it out!</p>
</blockquote>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> pitched <a href="https://forums.swift.org/t/missing-super-call-warning/38177">a proposal</a>
to add a missing <code class="language-plaintext highlighter-rouge">super</code> call warning.</p>
<blockquote>
<p>Introduce a new attribute to warn when an overridden function does not call
the <code class="language-plaintext highlighter-rouge">super</code> method in its body.</p>
<p>It is quite common to override a method in order to add additional
functionality to it, rather than to completely replace it.</p>
<p>At present, there is no way to communicate this need other than adding it to
the documentation and even experienced developers sometimes overlook this
small detail and later run into various issues at runtime.</p>
<p>In Objective-C, one can annotate a superclass method with the <a href="http://clang.llvm.org/docs/AttributeReference.html#objc-requires-super"><code class="language-plaintext highlighter-rouge">objc_requires_super</code></a>
attribute and the compiler emits a warning when an overridden method is missing
a call to the <code class="language-plaintext highlighter-rouge">super</code> method in its body.</p>
<p>However, there is no such attribute in Swift.</p>
</blockquote>
<p><a href="https://twitter.com/ericasadun">Erica Sadun</a> pitched <a href="https://forums.swift.org/t/proposing-to-expand-available-to-introduce-discouraged/38197">a proposal</a>
to expand <code class="language-plaintext highlighter-rouge">available</code> to introduce <code class="language-plaintext highlighter-rouge">discouraged</code>.</p>
<blockquote>
<p>Swift’s <code class="language-plaintext highlighter-rouge">available</code> attribute documents characteristics of a declaration’s
lifecycle. The attribute specifies when a declaration became available on a
given platform, and if it’s been deprecated, obsoleted, or renamed. We feel
there’s room to further nuance <code class="language-plaintext highlighter-rouge">available</code>. This proposal expands <code class="language-plaintext highlighter-rouge">available</code>
to introduce <code class="language-plaintext highlighter-rouge">discouraged</code>, making declarations harder to accidentally use.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/chrisbia/summary">chrisbia</a> pitched <a href="https://forums.swift.org/t/enabling-safe-non-optional-circular-referencing-with-shared-reference-counts/38200">a proposal</a>
to enable safe, non-optional, circular referencing with shared reference counts.</p>
<blockquote>
<p>I don’t often come across a data modeling problem where circular referencing
appears to be a good solution. In general I find that arguments that attempt to
justify circular references appear contrived (<code class="language-plaintext highlighter-rouge">Apartment <-> Person</code>), and
because of that lacking any true real world applicability. That said, circular
referencing isn’t always an attempt at a data modeling solution, more often
than not I find it’s an attempt at an encapsulation solution.</p>
<p>Often when defining complex models code files can become large and in an
effort to make the repository more digestible functionality and properties are
encapsulated into smaller bite-sized classes. The problem arises when some of
those bite-sized classes require access to data within the original scope.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/andrew_arnopoulos/summary">Andrew Arnopoulos</a> pitched <a href="https://forums.swift.org/t/proposal-allow-property-wrappers-with-multiple-arguments-to-defer-initialization-when-wrappedvalue-is-not-specified/38319">a proposal</a>
to allow property wrappers with multiple arguments to defer initialization when
a <code class="language-plaintext highlighter-rouge">wrappedValue</code> is not specified.</p>
<blockquote>
<p>Swift’s Property Wrappers allow for wrappers without arguments to defer
specifying the wrappedValue until the initialization of the containing type.
This proposal adds this feature to Property Wrappers that have multiple
arguments by extending the current initializer synthesization.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/dannys42/summary">Danny Sung</a> pitched <a href="https://forums.swift.org/t/invert-guard-let-scoping/38401">a proposal</a>
to invert <code class="language-plaintext highlighter-rouge">guard let</code> scoping.</p>
<blockquote>
<p>I’m proposing the introduction of an inverted scope for the <code class="language-plaintext highlighter-rouge">guard let</code>
pattern. The problem occurs most commonly when propagating errors to completion
handlers.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/kyleve/status/1280001602984660992"><del>Kids</del> scholars these days…</a></p>
Issue #163
https://swiftweeklybrief.com/issue-163
2020-07-02T00:00:00-07:00
2020-07-02T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>This year’s WWDC was a blast. Despite what is currently happening in the world
I think Apple created a small “development holiday” for all of us. I think a
new online conference reached far more folks around the world than ever before.
We got completely revamped <a href="https://developer.apple.com/forums/">developer forums</a>,
as well as many community-organized side events that were not tied to any
physical location, which is great.</p>
<p>This year we got great new things, especially in SwiftUI, that are driven by
new cool additions to the Swift language. And much more.
Now we have a full summer to explore new stuff and get ready for new Apple
releases and slowly for Apple’s own built silicon.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://engineering.linecorp.com/en/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_163" target="_blank">LINE loves Swift!</a></h4>
<p>LINE is the leading mobile messaging platform in Japan and boasts one of the largest Swift codebases in Asia. In addition to supporting Swift versions from day 1, we strongly value semantics, protocols, and strongly typed systems. Many of our members are also active in the OSS community and support both local and global meetups and peer labs. Come join us and see what Swift can do in the real world.</p>
<p><small><a href="https://engineering.linecorp.com/en/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_163" target="_blank">engineering.linecorp.com</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest episode of Swift Unwrapped, <a href="https://twitter.com/jesse_squires">Jesse</a>
and <a href="https://twitter.com/simjp">JP</a> talk <a href="https://spec.fm/podcasts/swift-unwrapped/fxMk4ipF">about</a>
tuples.</p>
<p>In <a href="https://www.swiftbysundell.com/podcast/75/">episode 75</a> of the Swift by
Sundell podcast, <a href="https://twitter.com/daveverwer">Dave Verwer</a> and
<a href="https://twitter.com/_sa_s">Sven A. Schmidt</a> join <a href="https://twitter.com/johnsundell">John</a>
to talk about their newly launched <a href="https://swiftpackageindex.com/">Swift Package Index</a>,
and what the overall state of Swift’s package ecosystem is. Also dependency
management, composing libraries, deploying server-side Swift in production,
and much more are discussed.</p>
<h3 id="news-and-community">News and community</h3>
<p>In this year’s WWDC 2020 Apple had two main sections of videos about the Swift
language and relevant topics:</p>
<ul>
<li><a href="https://developer.apple.com/news/?id=4nh602ih">Swift in Xcode 12</a></li>
<li><a href="https://developer.apple.com/news/?id=tjv7v7k1">Swift deep dive</a></li>
</ul>
<p>In addition to that, <a href="https://twitter.com/tomerdoron">Tom Doron</a> presented <a href="https://developer.apple.com/videos/play/wwdc2020/10644/">how
to use Swift on AWS Lambda with Xcode</a>.</p>
<p><a href="https://twitter.com/mousiechika">Amy Tsai</a> shared awesome <a href="https://twitter.com/mousiechika/status/1275547535206166531">sketch session notes</a>
for the <a href="https://developer.apple.com/videos/play/wwdc2020/10170/">Whats New In Swift</a>
session.</p>
<p>A great project by <a href="https://twitter.com/zntfdr">Federico Zanatello</a>: <a href="https://www.wwdcnotes.com/">WWDC Notes</a></p>
<ul>
<li>The TL;DW for Apple’s WWDC videos. You can read session notes written by the
community.</li>
</ul>
<p>Apple released Xcode 12 and here are the <a href="https://developer.apple.com/documentation/xcode-release-notes/xcode-12-beta-release-notes#Swift">release notes</a>
of what has changed in Swift.</p>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> shared that the Swift Crypto 1.1.0
RC1 is <a href="https://github.com/apple/swift-crypto/releases/tag/1.1.0-rc.1">available</a>.
It brings the new CryptoKit APIs from Apple’s WWDC20 platforms to all other
Swift platforms.</p>
<p>The first release candidate of Swift for <a href="https://github.com/tensorflow/swift/blob/master/Installation.md#release-candidates">TensorFlow v.0.10.0 is out</a>.</p>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> wrote <a href="https://swiftrocks.com/benefits-of-throwing-functions-try-swift-underrated-feature">a blog post</a>
about the benefits of using throwing functions.</p>
<p><a href="https://twitter.com/slashmodev">Moritz Lang</a> created <a href="https://github.com/slashmo/awesome-swift-nio">a repository</a>
listing all things SwiftNIO.</p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> wrote <a href="https://oleb.net/2020/as/">a blog post</a>
explaining <code class="language-plaintext highlighter-rouge">as</code>, <code class="language-plaintext highlighter-rouge">as?</code>, and <code class="language-plaintext highlighter-rouge">as!</code>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/32488">a pull request</a>
that fixes a bug in generic signature minimization. It <a href="https://twitter.com/slava_pestov/status/1274914547728515072">turned out</a>
that the fix didn’t require a big redesign of the <code class="language-plaintext highlighter-rouge">GenericSignatureBuilder</code>
after all. It’s just a five line addition of a new <code class="language-plaintext highlighter-rouge">'if'</code> statement.</p>
<p><a href="https://github.com/gottesmm">Michael Gottesman</a> merged <a href="https://github.com/apple/swift/pull/32627">a pull request</a>
that adds an option that causes the generic specializer to validate newly
specialized functions earlier when there is more information that can be put
into a pretty stack trace.</p>
<p><a href="https://twitter.com/stephencelis/">Stephen Celis</a> merged <a href="https://github.com/apple/swift/pull/32451">a pull request</a>
that improves performance of <code class="language-plaintext highlighter-rouge">Collection.removeFirst(_:) where Self == SubSequence</code>.
You can read more about it <a href="https://twitter.com/stephencelis/status/1278347623359971328">here</a>.</p>
<p><a href="https://github.com/LucianoPAlmeida">Luciano Almeida</a> merged <a href="https://github.com/apple/swift/pull/32376">a pull request</a>
that resolves <a href="https://bugs.swift.org/browse/SR-5688">SR-5688</a>: <em>Unhelpful
diagnostic when missing a ? in a KeyPath expression</em>.</p>
<p><a href="https://github.com/shahmishal">Mishal Shah</a> merged <a href="https://github.com/apple/swift/pull/32502">a pull request</a> to update master branch for Xcode 12 beta.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://forums.swift.org/t/se-0282-review-2-interoperability-with-the-c-atomic-operations-library/37360/12">SE-0282</a>: <em>Interoperability with the C Atomic Operations Library</em> was <a href="https://forums.swift.org/t/accepted-se-0282-interoperability-with-the-c-atomic-operations-library/38050">accepted</a>.</p>
<blockquote>
<p>This proposal does not specify whether/how dependency chains arising from the
C/C++ <code class="language-plaintext highlighter-rouge">memory_order_consume</code> memory ordering work in Swift. The consume ordering
as specified in the C/C++ standards is not implemented in any C/C++ compiler,
and we join the current version of the C++ standard in encouraging Swift
programmers not to use it. We expect to tackle the problem of efficient
traversal of concurrent data structures in future proposals. Meanwhile, Swift
programmers can start building useful concurrency constructs using relaxed,
acquire/release, and sequentially consistent memory orderings imported from C.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/ericasadun">Erica Sadun</a> pitched <a href="https://forums.swift.org/t/returning-to-an-old-hobbyhorse-migrating-higher-order-function-names-to-comply-with-api-guidelines/37728">a proposal</a>
to migrate higher order function names to comply with API guidelines.</p>
<blockquote>
<p>Swift’s higher order functions mostly predate the API guidelines and are
based on terms of art. The community debated about this in the past and the
“Term of Art” hammer won at that time. Perhaps we can reconsider now that Swift
is entering its comfortable middle age reflective period as a missed
opportunity.</p>
<p>It would be simple to alias <code class="language-plaintext highlighter-rouge">map</code>, <code class="language-plaintext highlighter-rouge">filter</code>, etc with API compliant names
(<code class="language-plaintext highlighter-rouge">apped</code>, <code class="language-plaintext highlighter-rouge">mapping</code>, <code class="language-plaintext highlighter-rouge">filtered</code>, <code class="language-plaintext highlighter-rouge">filtering</code>), slow-walk-deprecate the former
with the gentlest touch, and move towards a more consistent dev-facing
vocabulary by replacing the terms in the SPL docs and devdoc tutorials (with
footnotes or sidebars) to establish a new standard long before removing the old.</p>
<p>Breaking changes have a high bar so it would take such a slow and cautious
approach to migrate the community towards these changes. Backwards
compatibility would need to be maintained for a longer period of time than
usual. I’m curious as to what people think.</p>
</blockquote>
<p><a href="https://twitter.com/ericasadun">Erica Sadun</a> pitched <a href="https://forums.swift.org/t/extend-swiftpm-packagedescription-to-introduce-metadata/37722">a proposal</a>
to extend SwiftPM <code class="language-plaintext highlighter-rouge">PackageDescription</code> to introduce metadata.</p>
<blockquote>
<p>A Swift Package defines the sources and dependencies for successful
compilation. The <a href="https://docs.swift.org/package-manager/"><code class="language-plaintext highlighter-rouge">PackageDescription</code></a>
specifies items like the supported Swift version, linker settings, and so forth.</p>
<p>What it does not do is offer metadata. You won’t find email for the active
project manager, a list of major authors, descriptive tags, an abstract or
discussion of the package, a link to documentation, deprecation information or
links to superceding packages upon deprecation.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> starthed <a href="https://forums.swift.org/t/revisiting-the-source-compatibility-impact-of-se-0274-concise-magic-file-names/37720">a conversation</a>
about revisiting the source compatibility impact of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274</a>:
Concise magic file names.</p>
<blockquote>
<p>In light of the discussion of <a href="https://forums.swift.org/t/principles-for-trailing-closure-evolution-proposals/37265">principles for (trailing closure) evolution
proposals</a>
and based on feedback we’ve received from the <a href="https://swift.org/download/#snapshots">Swift 5.3 development snapshots</a>,
I’d like to revisit <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274: Concise magic file names</a>.
In particular, I feel like SE-0247 has violated the “Source Compatibility”
principle more than is necessary, and that we should consider revising the
proposal.</p>
<p>SE-0247 includes an additive change (<code class="language-plaintext highlighter-rouge">#filePath</code> literal to provide the full
path to the file), but then introduces three changes that affect existing
sources:</p>
<ol>
<li><code class="language-plaintext highlighter-rouge">#file</code> literals have a different form that does not include the full path
name. Therefore, the spelling <code class="language-plaintext highlighter-rouge">#file</code> has changed meaning.</li>
<li>The compiler provides a warning when a wrapper around a
<code class="language-plaintext highlighter-rouge">#filePath</code>-defaulting function passes it <code class="language-plaintext highlighter-rouge">#file</code> instead, or vice versa.</li>
<li>Standard library functions like <code class="language-plaintext highlighter-rouge">precondition</code> currently use <code class="language-plaintext highlighter-rouge">#file</code>, and
therefore have had their behavior changed to no longer produce the full path
name by default.</li>
</ol>
</blockquote>
<p><a href="https://forums.swift.org/u/tomerd">Tom Doron</a> shared <a href="https://forums.swift.org/t/june-10th-2020/37863">meeting notes</a>
for the Swift on the Server Workgroup June 10th, 2020 meeting.</p>
<p><a href="https://twitter.com/jumhyn">Frederick Kellison-Linn</a> shared <a href="https://forums.swift.org/t/compound-variable-names/37963">a proposal</a>
that introduces a syntax for defining function-typed variables which have
compound names.</p>
<blockquote>
<p>This proposal introduces a syntax for defining funciton-typed variables which
have compound names (i.e., names with argument labels). This allows the call
sites of such variables to achieve the same clarity that is achieveable with
<code class="language-plaintext highlighter-rouge">func</code> declarations.</p>
</blockquote>
<p><a href="https://twitter.com/freak4pc">Shai Mishali</a> pitched <a href="https://forums.swift.org/t/introduce-anonymouskeypath/38080">a proposal</a>
to introduce <code class="language-plaintext highlighter-rouge">AnonymousKeyPath</code>.</p>
<blockquote>
<p>In many challenges of API Designs, you want your consumer to provide a way to
get/set a specific concrete type.</p>
<p>Today, a consumer can express this idea by a Key Path, a wonderful concept in
Swift. My consumer can tell me:</p>
<ul>
<li>This is how you can get a String from MyObject (KeyPath)</li>
<li>This is how you can mutate a String on MyObject (WritableKeyPath)</li>
</ul>
<p>Commonly, though, you want to ask a consumer a different set of questions:</p>
<ul>
<li>Give me a way to retrieve a String on an arbitrary object</li>
<li>Give me a way to mutate a String on an arbitrary object</li>
</ul>
<p>While not caring what is the Root of that String, as long as you fulfil the
concrete requirement.</p>
<p>Unfortunately, as of today there’s no way to express a Key Path which isn’t
bound to a specific concrete Root.</p>
</blockquote>
<p><a href="https://twitter.com/mattt">Mattt</a> gave <a href="https://forums.swift.org/t/swift-package-registry-service-security/38088">an update</a>
on <a href="https://forums.swift.org/t/swift-package-registry-service/37219">a pitch</a>
for a Swift package registry service.</p>
<blockquote>
<p>A primary goal of the proposed registry service is to provide strong
guarantees that the package you downloaded is authentic. One approach is built
on trust: If you assume that a registry always sends you exactly what you ask
for, you only need to verify the sender (though it wouldn’t hurt to verify the
contents anyway).</p>
<p>Modern information security relies on <a href="https://en.wikipedia.org/wiki/Public-key_cryptography">public-key cryptography</a>
to verify claims of identity. Broadly speaking, there are two approaches to
certificate trust:</p>
<ul>
<li>A centralized, <em>hierarchical</em> <a href="https://en.wikipedia.org/wiki/Public_key_infrastructure">public-key infrastructure (PKI)</a>
scheme, in which <a href="https://en.wikipedia.org/wiki/Certificate_authority">certificate authorities (CAs)</a>
issue <a href="https://en.wikipedia.org/wiki/Public_key_certificate">certificates</a>
that prove the ownership of public keys. This is the approach taken by TLS,
which is used by HTTPS.</li>
<li>A decentralized, distributed <a href="https://en.wikipedia.org/wiki/Web_of_trust">“web of trust”</a>
whereby individuals vouch for the identity of one another by signing each
others’ keys directly. This is the approach taken by PGP.</li>
</ul>
<p>The original proposal relies on both TLS and PGP for security; TLS to verify
the identity of the registry’s domain (e.g. github.com) and PGP to verify the
registry as the creator of the package archive. My thinking was that this “belt
and suspenders” approach would offer more security than relying on one alone.
Instead, this turned out to be more of a “weak link in the chain”.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Finally, we <a href="https://twitter.com/Valzevul/status/1275164878056103936">have</a>
Nyan Cat in Swift. 🏳️🌈</p>
<p><a href="https://twitter.com/jckarter/status/1275423569552400384">Acronyms, acronyms everywhere…</a></p>
Issue #162
https://swiftweeklybrief.com/issue-162
2020-06-18T00:00:00-07:00
2020-06-18T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>WWDC is now very, very near. Only a little bit more than a weekend before things
kick off. Very exciting!</p>
<p>Also — a note regarding this issue’s sponsor. This was so unexpected — but so,
so very kind. His point is spot on. Putting together Swift Weekly Brief time
and time again is something <a href="https://basthomas.github.io/curating-swift-weekly">I’m very happy to do</a>,
and it is a real pleasure to be able to support the Swift community this way.</p>
<p>But it isn’t always glamorous, so don’t <a href="https://www.youtube.com/watch?v=ePuOrCbIW-o">take things for granted</a>.</p>
<p>Thank you, Paul! ❤️</p>
<p>Enjoy WWDC everyone, and looking forward to a hopefully jam-packed issue in two
weeks!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://hackingwithswift.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_162" target="_blank">Support the things you love</a></h4>
<p>Hello! My name is Paul and I run Hacking with Swift. I’m not going to use this spot to tell you to check out my books, but instead I’m sponsoring this issue because I appreciate the work that Bas and Kristaps do and I want to support them. Support the things you love, folks, otherwise they might just go away ❤️</p>
<p><small><a href="https://hackingwithswift.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_162" target="_blank">hackingwithswift.com</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/daveverwer">Dave Verwer</a> and <a href="https://twitter.com/_sa_s">Sven A. Schmidt</a> announced
<a href="https://swiftpackageindex.com/">the Swift Package Index</a>, “the place to find
Swift packages”.</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> put together <a href="https://github.com/twostraws/wwdc">a repository</a>
with an overview of everything that is being organized around WWDC in our
community.</p>
<p><a href="https://twitter.com/k__mahar">Kaitlin Mahar</a> announced the release of <a href="https://www.mongodb.com/blog/post/announcing-release-official-swift-driver">the MongoDB Swift driver v1.0</a>! 🥳</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov <a href="https://twitter.com/slava_pestov/status/1271259363693527041">wrote</a>
a thread about <a href="https://twitter.com/CodaFi_">Robert Widmann</a>’s work on
improving incremental builds.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/swift-server/sswg/blob/master/proposals/0013-swift-aws-lambda-runtime.md">SSWG-0013</a>: <em>Swift AWS Lambda Runtime</em> is <a href="https://forums.swift.org/t/sswg-0013-swift-aws-lambda-runtime/37466">under review</a>.</p>
<blockquote>
<p>Many modern systems have client components like iOS, macOS or watchOS
applications as well as server components that those clients interact with.
Serverless functions are often the easiest and most efficient way for client
application developers to extend their applications into the cloud.</p>
<p>Serverless functions are increasingly becoming a popular choice for running
event-driven or otherwise ad-hoc compute tasks in the cloud. They power mission
critical microservices and data intensive workloads. In many cases, serverless
functions allow developers to more easily scale and control compute costs given
their on-demand nature.</p>
<p>When using serverless functions, attention must be given to resource
utilization as it directly impacts the costs of the system. This is where Swift
shines! With its low memory footprint, deterministic performance, and quick
start time, Swift is a fantastic match for the serverless functions
architecture.</p>
<p>Combine this with Swift’s developer friendliness, expressiveness, and
emphasis on safety, and we have a solution that is great for developers at all
skill levels, scalable, and cost effective.</p>
</blockquote>
<p><a href="https://github.com/swift-server/sswg/blob/master/proposals/0014-swift-backtrace.md">SSWG-0014</a>: <em>Swift Backtrace</em> is <a href="https://forums.swift.org/t/sswg-0014-swift-backtrace/37602">under review</a>.</p>
<blockquote>
<p>Printing backtraces when applications crash is a critical component in
diagnostics of real-world production issues on the Server.</p>
<p>When applications crash on the Server, it is desired for the crash
information to be captured and printed along side the application logs so that
log aggregation tools (e.g. Splunk) could include the crash information and
used for alerting and further analysis offline.</p>
<p>At this point of time, Swift does not print crash backtraces when compiled
in release mode on Linux. This means that Swift server applications can crash
silently making the operation of such applications difficult.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/guyb/summary">Guy Brooker</a> pitched <a href="https://forums.swift.org/t/static-thread-safety/37542">a proposal</a>
for static thread safety.</p>
<blockquote>
<p>One of the <a href="https://swift.org/about/">principal goals of Swift</a> is “to make
writing and maintaining correct programs easier for the developer”. Swift has
gone a long way to eliminate many common errors found in other programming
languages through static type checking, ensuring safe memory access. The free
for all in C where anything and everything was possible by casting pointers to
different data types is thankfully over.</p>
<p>Most modern non-trivial Swift applications require some form of concurrency,
asynchronously retrieving information over a network, firing timers , updating
UI or handling notifications, however Swift does not provide concurrency
primitives today. Accessing variables concurrently in Swift is inherently
dangerous, and is a very easy mistake to make. The Swift language provides no
safety for a developer of concurrent code, leaving them in a similar position
as the C programmer of yesteryear, permitting frequent programming errors to
go un-flagged.</p>
<p>This proposal sets out some small language changes which would allow the
compiler to spot basic concurrent programming errors. To be clear, the title
of this proposal “Static thread safety” is intended to mean compile time thread
safety checks. It does not add concurrency primitives, nor provide any
automatic concurrency or thread safety. It simply allows developers to write
safer code.</p>
</blockquote>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> shared <a href="https://forums.swift.org/t/running-many-operations-concurrently-but-in-batches/37518">some thoughts</a>
on running many operations concurrently, but in batches.</p>
<blockquote>
<p>So here’s some more example code for a question that I’ve been asked
repeatedly: How can I run a large number of operations whilst limiting this to
<code class="language-plaintext highlighter-rouge">N</code> running at the same time. You may want to do that if you have to do many
HTTP requests to a website but you don’t want to overload the website and say
do only 10 at the same time.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/quinceymorris/summary">Quincey Morris</a> pitched <a href="https://forums.swift.org/t/await-async-part-deux/37491/30">another proposal</a>
for <code class="language-plaintext highlighter-rouge">async</code> / <code class="language-plaintext highlighter-rouge">await</code>.</p>
<blockquote>
<p>As far as I’m concerned, the goal here is to add Swift language features to
provide a path-of-execution serialization operator, along with a genuine notion
of an asynchronous function.</p>
<p>Beyond that: there is a further discussion which we haven’t even started
having yet. There are other asynchronous patterns we might like to provide for.
How about, for example, an await operator that operates on “groups” of
asynchronous functions (aka concurrency or dispatch groups)? How about an
algebra of futures or promises that can be used within the implementations of
asynchronous functions to provide more sophisticated usage patterns?</p>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> pitched <a href="https://forums.swift.org/t/a-way-to-check-for-unique-storage-in-standard-library-collections/37595">a proposal</a>
for a way to check for unique storage in standard library collections.</p>
<blockquote>
<p>Consider:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">struct</span> <span class="kt">Vector</span><span class="o"><</span><span class="kt">T</span><span class="o">></span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">scalars</span><span class="p">:</span> <span class="p">[</span><span class="kt">T</span><span class="p">]</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="o">+=</span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="k">inout</span> <span class="kt">Vector</span><span class="p">,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">Vector</span><span class="p">)</span> <span class="p">{</span>
<span class="k">for</span> <span class="n">i</span> <span class="k">in</span> <span class="n">lhs</span><span class="o">.</span><span class="n">scalars</span><span class="o">.</span><span class="n">indices</span> <span class="p">{</span> <span class="n">lhs</span><span class="o">.</span><span class="n">scalars</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+=</span> <span class="n">rhs</span><span class="o">.</span><span class="n">scalars</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>This implementation is suboptimal in the case where lhs.scalars shares its
storage with another array, because it first copies the scalars in lhs into new
storage and then writes over them, accumulating elements from rhs into it. What
we really want to be able to do is:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">struct</span> <span class="kt">Vector</span><span class="o"><</span><span class="kt">T</span><span class="o">></span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">scalars</span><span class="p">:</span> <span class="p">[</span><span class="kt">T</span><span class="p">]</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="o">+=</span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="k">inout</span> <span class="kt">Vector</span><span class="p">,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">Vector</span><span class="p">)</span> <span class="p">{</span>
<span class="k">if</span> <span class="nf">hasUniquelyReferencedStorage</span><span class="p">(</span><span class="o">&</span><span class="n">lhs</span><span class="o">.</span><span class="n">scalars</span><span class="p">)</span> <span class="p">{</span>
<span class="k">for</span> <span class="n">i</span> <span class="k">in</span> <span class="n">lhs</span><span class="o">.</span><span class="n">scalars</span><span class="o">.</span><span class="n">indices</span> <span class="p">{</span> <span class="n">lhs</span><span class="o">.</span><span class="n">scalars</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="o">+=</span> <span class="n">rhs</span><span class="o">.</span><span class="n">scalars</span><span class="p">[</span><span class="n">i</span><span class="p">]</span> <span class="p">}</span>
<span class="p">}</span>
<span class="k">else</span> <span class="p">{</span>
<span class="n">lhs</span> <span class="o">=</span> <span class="n">lhs</span> <span class="o">+</span> <span class="n">rhs</span> <span class="c1">// build new storage once and replace old storage with it</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>Currently the only known way to do the check for unique storage is a horrible
hack that probably violates the memory model.</p>
<p>Ideally, we would have a way to ask generically whether all the references in
any given type were uniquely-referenced, but as a start, it would be extremely
useful just to be able to ask that question about arrays, sets, and
dictionaries. My pitch to you is that we expose
<code class="language-plaintext highlighter-rouge">unsafeHasUniquelyReferencedStorage</code> in the standard library.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Remember <a href="https://twitter.com/gregheo/status/1273471050664177664">Mac OS X</a>?
Those were the days. 🦁</p>
Issue #161
https://swiftweeklybrief.com/issue-161
2020-06-11T00:00:00-07:00
2020-06-11T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>The <a href="/issue-160">previous issue</a> has a more extensive introduction, so for this one
I’ll keep it short. WWDC is coming up really soon — I’m very much looking
forward to it and seeing/meeting people online. Come say hi if possible :-)</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> wrote <a href="https://swift.org/blog/aws-lambda-runtime/">a blog post and announced</a>
Swift AWS Lambda Runtime, designed to help Swift developers build serverless
functions for the Amazon Web Services Lambda platform.</p>
<p><a href="https://twitter.com/fabianfett">Fabian Fett</a> wrote <a href="https://fabianfett.de/getting-started-with-swift-aws-lambda-runtime">a blog post</a>
on getting started with Swift on AWS Lambda.</p>
<p><a href="https://twitter.com/daniel_dunbar">Daniel Dunbar</a> announced <a href="https://forums.swift.org/t/llbuild2/36896">llbuild2</a>,
an experimental, Swift native, fully async, NIO futures-based low level build
system. Started as the <code class="language-plaintext highlighter-rouge">cevobuild</code> experiment in <code class="language-plaintext highlighter-rouge">llbuild</code>, it aims to continue
that exploration.</p>
<p><a href="https://twitter.com/AirspeedSwift/status/1264664397504372736">Ben Cohen</a> played
around <a href="https://twitter.com/AirspeedSwift/status/1264664397504372736">with <code class="language-plaintext highlighter-rouge">Collection</code></a>,
implementing an <code class="language-plaintext highlighter-rouge">EitherCollection</code> that is a whopping 774x faster than
<code class="language-plaintext highlighter-rouge">AnyCollection</code>.</p>
<p><a href="https://twitter.com/jasdev">Jasdev Singh</a> posted <a href="https://www.youtube.com/watch?v=35rgnqsXtag">a video</a>
on “Deriving <code class="language-plaintext highlighter-rouge">Publisher</code> from Swift’s <code class="language-plaintext highlighter-rouge">Sequence</code> protocol”.</p>
<p><a href="https://twitter.com/johannesweiss/status/1193220999535382528">Johannes Weiss</a> wrote <a href="https://forums.swift.org/t/loops-with-futures/37216">about “Looping” over Futures</a>:</p>
<blockquote>
<p>We’ve got a “rule of three” so when we get asked the same question three
times, we need to do something to document it and today was at least the third
time I personally got asked the “looping over futures” question.</p>
</blockquote>
<p>I love this rule.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> opened <a href="https://github.com/apple/swift/pull/32223">a pull request</a>
for multi-statement closure type inference. The supported statements are
currently limited, but will improve over time. 🏎</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0282-atomics.md">SE-0282</a>: <em>Interoperability with the C Atomic Operations Library ⚛︎</em> is <a href="https://forums.swift.org/t/se-0282-review-2-interoperability-with-the-c-atomic-operations-library/37360">under a second review</a>.</p>
<blockquote>
<p>This proposal adopts a C/C++-style weak concurrency memory model in Swift,
describing how Swift code interoperates with concurrency primitives imported
from C.</p>
<p>This enables intrepid library authors to start building concurrency constructs
in (mostly) pure Swift.</p>
</blockquote>
<p>This proposal includes <a href="https://github.com/apple/swift-se-0282-experimental">a proof-of-concept package</a>
demonstrating the use of atomics from C to provide a low-level atomic API to
Swift.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/mattt">Mattt</a> pitched <a href="https://forums.swift.org/t/swift-package-registry-service/37219">a proposal</a>
for a Swift package registry service.</p>
<blockquote>
<p>Swift Package Manager downloads dependencies using Git. Our proposal defines
a standard web service interface that it can use to also download dependencies
from package registries.</p>
<p>Today, a package dependency is specified by a URL for a Git repository. When
a project is built for the first time, Swift Package Manager clones the
repository for each dependency and attempts to resolve the version requirements
with the available tags.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/patricktheprogrammer/summary">Patrick Weigel</a> pitched <a href="https://forums.swift.org/t/replace-the-reference-types-weak-and-unowned-with-nonstrong/36740">a proposal</a>
to replace the reference types <code class="language-plaintext highlighter-rouge">weak</code> and <code class="language-plaintext highlighter-rouge">unowned</code> with <code class="language-plaintext highlighter-rouge">nonstrong</code>.</p>
<blockquote>
<p>In Swift it is possible to create strong reference cycles between class
instances. Strong reference cycles are bad as they create potentially crashing
memory leaks (unused memory that is not made available to the app). Swift
provides two ways to resolve strong reference cycles: weak references and
unowned references. Swift requires the coder to determine which type (<code class="language-plaintext highlighter-rouge">weak</code> or
<code class="language-plaintext highlighter-rouge">unowned</code>) to use, when in many instances the coder simply wants the type to be
not strong.</p>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams/status/1215792568039927808">Dave Abrahams</a> pitched <a href="https://forums.swift.org/t/pitch-non-public-conformances-implementing-public-api/37159">a proposal</a>
to allow non-public conformances to implement public API.</p>
<blockquote>
<p>In Swift, protocol extensions provide a beautiful way to share API
implementations across value types. For example, an extension on the
<code class="language-plaintext highlighter-rouge">Equatable</code> protocol provides a public implementation of the <code class="language-plaintext highlighter-rouge">!=</code> operator to
all public conforming types. The power of this feature is limited, however,
because the conformance can never be less visible than APIs provided by
extensions depending on that conformance.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/shabalin/summary">Denys Shabalin</a> pitched <a href="https://forums.swift.org/t/automatic-requirement-satisfaction-in-plain-swift/37158">a proposal</a>
for Automatic Requirement Satisfaction in plain Swift.</p>
<blockquote>
<p>Swift can automatically generate code to satisfy the requirements of special
protocols such as <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Hashable</code> and <code class="language-plaintext highlighter-rouge">Codable</code>. For example, any
<code class="language-plaintext highlighter-rouge">struct</code> whose stored properties conform to Equatable can itself conform simply
by declaring it so, without explicitly implementing <code class="language-plaintext highlighter-rouge">Equatable</code>’s requirement
for a <code class="language-plaintext highlighter-rouge">static func ==(Self, Self) -> Bool</code>:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">struct</span> <span class="kt">Point</span><span class="p">:</span> <span class="kt">Equatable</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">x</span><span class="p">:</span> <span class="kt">Float</span>
<span class="k">var</span> <span class="nv">y</span><span class="p">:</span> <span class="kt">Float</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>The implementation of <code class="language-plaintext highlighter-rouge">==</code> for <code class="language-plaintext highlighter-rouge">Point</code> is synthesized by the compiler behind
the scenes.</p>
<p>This functionality is extremely convenient, but it is currently limited to
the few protocols for which the compiler defines automatic requirement
satisfaction. We would like to lift this restriction and allow for arbitrary
libraries to vend protocols and automatic conformances.</p>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams/status/1215792568039927808">Dave Abrahams</a> pitched <a href="https://forums.swift.org/t/an-implementation-model-for-rational-protocol-conformance-behavior/37171">a proposal</a>
for an Implementation Model for Rational Protocol Conformance Behavior.</p>
<blockquote>
<p>When Swift implementers are faced with questions about the intended
programming model for generics, they commonly respond with a focus on how
generics are implemented, which, as the latter discussion shows, is not always
compatible with the intended semantics. Furthermore, it makes a poor foundation
for user (and especially my) understanding.</p>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> shared <a href="https://forums.swift.org/t/may-13th-2020/36929">the Swift on the Server, May 13th work group updates</a>.</p>
<h3 id="finally">Finally</h3>
<p>No link in this issue. You are awesome. Stay safe out there. ❤️</p>
Issue #160
https://swiftweeklybrief.com/issue-160
2020-05-21T00:00:00-07:00
2020-05-21T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>And so, another two weeks have passed. For me, time seems to pass so quickly and
yet at the same time, slowly.</p>
<p>We’re now about a month away from WWDC20 “taking off” — what that means exactly
is still a surprise, but I’m very much looking forward to it.</p>
<p>Also, today’s issue coincides with Global Accessibility Awareness Day (GAAD).
It’s a topic very dear to me. There are some <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues?q=is%3Aissue+is%3Aopen+label%3Aaccessibility">tasks on this website’s
repository</a>
that aim to make the site more accessible. Any help on those would mean the
world to me.</p>
<p>After all, I took over the curation of this newsletter from Jesse because I
wanted to keep sharing what’s happening in Swift open source with all those
others benefiting from it.</p>
<p>There are also still <a href="https://swiftweeklybrief.com/sponsorship/">sponsorship opportunities</a>
for the newsletter, and I would greatly appreciate it if you could share that
with those who might be interested in helping with the newsletter in that way.
It allows us to keep delivering it to your inbox every other Thursday!</p>
<p>Anyway… there’s also news!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p>Swift 5.3 <a href="https://forums.swift.org/t/whats-new-in-swift-5-3/36508">is going to be released soon</a>,
and Larry provided a great overview of what’s included.</p>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> wrote <a href="https://www.timc.dev/posts/future-of-server-side-swift">an article</a>
discussing the future of server-side Swift.</p>
<p><a href="https://twitter.com/vvendra">Vinicius Vendramini</a> announced <a href="https://vinivendra.github.io/Gryphon/">Gryphon</a>,
a Swift to Kotlin translator — a project he’s been working on for the past three
(!) years.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/mikeash">Mike Ash</a> opened <a href="https://github.com/apple/swift/pull/31468">a pull request</a>
that adds a utility that can attach to a running Swift process and inspect/debug
the runtime’s behavior.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift-package-manager/pull/2736">a pull request</a>
allowing the Swift Package Manager to optionally use the new swift-driver,
making it much easier to try it out for your own projects.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0283-tuples-are-equatable-comparable-hashable.md">SE-0283</a>: <em>Tuples Conform to <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Comparable</code>, and <code class="language-plaintext highlighter-rouge">Hashable</code></em> was <a href="https://forums.swift.org/t/accepted-se-0283-tuples-conform-to-equatable-comparable-and-hashable/36658">accepted</a>.</p>
<blockquote>
<p>Almost all the feedback we received was positive, and the Core Team is
convinced that this is a great incremental step forward. Some excellent points
on possible concern over future tech debt in the compiler and runtime were
brought up, but the Core Team believes that it is manageable and that this
proposal helps push Swift forward in a positive direction.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/namolnad/summary">Dan Loman</a> pitched <a href="https://forums.swift.org/t/adding-firstas-to-sequence/36665">a proposal</a>
to add <code class="language-plaintext highlighter-rouge">firstAs()</code> to <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
<blockquote>
<p>I often find it necessary (and I imagine this is somewhat common) to find and
cast the first matching element of a sequence. There are of course a few
techniques that could be used to do this. For example:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="n">sequence</span><span class="o">.</span><span class="n">filter</span> <span class="p">{</span> <span class="nv">$0</span> <span class="k">is</span> <span class="kt">MyType</span> <span class="p">}</span><span class="o">.</span><span class="n">first</span> <span class="k">as?</span> <span class="kt">MyType</span>
<span class="n">sequence</span><span class="o">.</span><span class="n">compactMap</span> <span class="p">{</span> <span class="nv">$0</span> <span class="k">as?</span> <span class="kt">MyType</span> <span class="p">}</span><span class="o">.</span><span class="n">first</span>
<span class="n">sequence</span><span class="o">.</span><span class="n">first</span> <span class="p">{</span> <span class="nv">$0</span> <span class="k">is</span> <span class="kt">MyLongTypeName</span> <span class="p">}</span> <span class="k">as?</span> <span class="kt">MyLongTypeName</span>
<span class="k">if</span> <span class="k">let</span> <span class="nv">element</span> <span class="o">=</span> <span class="n">sequence</span><span class="o">.</span><span class="nf">first</span><span class="p">(</span><span class="nv">where</span><span class="p">:</span> <span class="p">{</span> <span class="nv">$0</span> <span class="k">is</span> <span class="kt">MyLongTypeName</span> <span class="p">})</span> <span class="k">as?</span> <span class="kt">MyLongTypeName</span> <span class="p">{</span>
<span class="c1">// do something</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>The last option should leave us with the fewest iterations and is the option
I’ve chosen to implement as a simple helper in a number of my projects.</p>
<p>This can allow for very compact, straightforward, and efficient calls to find
the first element you’re looking for:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c1">// explicit type</span>
<span class="k">if</span> <span class="k">let</span> <span class="nv">element</span> <span class="o">=</span> <span class="n">sequence</span><span class="o">.</span><span class="nf">firstAs</span><span class="p">(</span><span class="kt">MyType</span><span class="o">.</span><span class="k">self</span><span class="p">)</span> <span class="p">{</span>
<span class="c1">// do something</span>
<span class="p">}</span>
<span class="c1">// inferred type</span>
<span class="k">if</span> <span class="k">let</span> <span class="nv">element</span><span class="p">:</span> <span class="kt">MyLongTypeName</span> <span class="o">=</span> <span class="n">sequence</span><span class="o">.</span><span class="nf">firstAs</span><span class="p">()</span> <span class="p">{</span>
<span class="c1">// do something</span>
<span class="p">}</span>
<span class="c1">// inferred type</span>
<span class="k">let</span> <span class="nv">label</span><span class="p">:</span> <span class="kt">UILabel</span><span class="p">?</span>
<span class="k">switch</span> <span class="n">searchArea</span> <span class="p">{</span>
<span class="k">case</span> <span class="o">.</span><span class="nv">subviews</span><span class="p">:</span>
<span class="n">label</span> <span class="o">=</span> <span class="n">subviews</span><span class="o">.</span><span class="nf">firstAs</span><span class="p">()</span>
<span class="k">case</span> <span class="o">.</span><span class="nv">arrangedSubviews</span><span class="p">:</span>
<span class="n">label</span> <span class="o">=</span> <span class="n">stackView</span><span class="o">.</span><span class="n">arrangedSubviews</span><span class="o">.</span><span class="nf">firstAs</span><span class="p">()</span>
<span class="p">}</span>
</code></pre></div></div>
<p><a href="https://forums.swift.org/u/kumarc/summary">Kumar C</a> pitched <a href="https://forums.swift.org/t/use-instead-of-curly-braces-for-single-expression-bodied-property-getters-subscripted-getters-and-functions/36676">a proposal</a>
to use <code class="language-plaintext highlighter-rouge">-></code> instead of curly braces for single expression bodied property
getters, subscripted getters and functions.</p>
<blockquote>
<p>As of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md">SE-0255</a>
developers can omit the return keyword for single-expression bodied getters for
properties, subscripts and single expression bodies functions. This is a nice
improvement to the language. Here’s an even more improved version of the same
proposal.</p>
<p><strong>Existing Syntax for Properties</strong></p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">var</span> <span class="nv">location</span><span class="p">:</span> <span class="kt">Location</span> <span class="p">{</span> <span class="o">.</span><span class="nf">init</span><span class="p">(</span><span class="nv">latitude</span><span class="p">:</span> <span class="n">lat</span><span class="p">,</span> <span class="nv">longitude</span><span class="p">:</span> <span class="n">long</span><span class="p">)</span> <span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p><strong>Proposed Change</strong></p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">var</span> <span class="nv">location</span><span class="p">:</span> <span class="kt">Location</span> <span class="o">-></span> <span class="o">.</span><span class="nf">init</span><span class="p">(</span><span class="nv">latitude</span><span class="p">:</span> <span class="n">lat</span><span class="p">,</span> <span class="nv">longitude</span><span class="p">:</span> <span class="n">long</span><span class="p">)</span>
</code></pre></div></div>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a> pitched <a href="https://forums.swift.org/t/pitch-2-cross-import-overlays/36710">a follow-up proposal</a>
to cross-importing overlays.</p>
<blockquote>
<blockquote>
<p>Cross-import overlays allow Swift to automatically import additional
“overlay” modules based on the combination of imports in a particular source
file. They allow one library or framework to seamlessly offer tailored APIs for
interoperating with another, without imposing additional dependencies or code
on clients who don’t need it.</p>
</blockquote>
<p>This feature has now been implemented and is in master and 5.3 nightly
compilers, hidden behind the <code class="language-plaintext highlighter-rouge">-Xfrontend -enable-cross-import-overlays</code> flag.
The proposal has been rewritten and reflects the implementation in the
nightlies.</p>
</blockquote>
<p><a href="https://twitter.com/0xTim">Tim Condon</a> pitched <a href="https://forums.swift.org/t/pitch-enable-test-discovery-by-default/36619">a proposal</a>
to enable test discovery on Linux by default.</p>
<blockquote>
<p>Swift 5.1 <a href="https://forums.swift.org/t/test-discovery-on-linux/26203">introduced</a>
Test Discovery on Linux adding an <code class="language-plaintext highlighter-rouge">--enable-test-discovery</code> flag you could pass
to <code class="language-plaintext highlighter-rouge">swift test</code> so it would automatically pick up tests on Linux to run, without
having to manually specifying them, which is prone to problems.</p>
<p>Since this has been in use for several months now without major issues, I
propose we enable the flag by default. This simplifies testing on Linux, stops
<a href="https://forums.swift.org/t/make-test-discovery-on-by-default/30321">build errors</a>
when building on Linux without a <code class="language-plaintext highlighter-rouge">LinuxMain.swift</code> present and no flag, and
generally makes life a bit easier, especially for newcomers.</p>
</blockquote>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> pitched <a href="https://forums.swift.org/t/rfc-policies-for-swift-platform-development/36257">a proposal</a>
to add policies for Swift platform development.</p>
<blockquote>
<p>In order to create a stable ecosystem for Swift, it is important that we
maintain a single coherent ecosystem across platforms. Whenever technical
feasible, the project should aim to provide the same interfaces, behaviours,
and capabilities on every platform. For example, the compiler and build system
should support both static and dynamic linking of libraries on all platforms.</p>
</blockquote>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> brought up <a href="https://forums.swift.org/t/se-0279-and-variadic-parameters/36410">required changes</a>
to his proposal on multiple variadic parameters in functions.</p>
<blockquote>
<p>I’m currently looking into whether my proposal for <a href="https://github.com/apple/swift-evolution/pull/1125">multiple variadic
parameters in functions</a>
will need any updates now that <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md">SE-0279</a>
is accepted. While experimenting with the implementation on <code class="language-plaintext highlighter-rouge">master</code>, I noticed
the following is not allowed:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">bar</span><span class="p">:</span> <span class="p">()</span> <span class="o">-></span> <span class="p">(),</span> <span class="nv">baz</span><span class="p">:</span> <span class="p">()</span> <span class="o">-></span> <span class="p">()</span><span class="o">...</span><span class="p">,</span> <span class="nv">qux</span><span class="p">:</span> <span class="p">()</span> <span class="o">-></span> <span class="p">())</span> <span class="p">{}</span>
<span class="n">foo</span> <span class="p">{}</span> <span class="nv">baz</span><span class="p">:</span> <span class="p">{}</span> <span class="nv">_</span><span class="p">:</span> <span class="p">{}</span> <span class="nv">_</span><span class="p">:</span> <span class="p">{}</span> <span class="nv">qux</span><span class="p">:</span> <span class="p">{}</span> <span class="c1">// error: extra arguments at positions #4, #3, #3, #4 in call</span>
</code></pre></div></div>
<blockquote>
<p>I assume this is mostly a consequence of the backwards scan argument matching
rule, but is it the intended behavior (the error message indicates it may just
be a bug)? The proposal text doesn’t mention varargs. I think choosing to allow
it or disallow it would both be reasonable, but it would be nice to specify the
intended behavior a little more clearly.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Finding <a href="https://twitter.com/jnadeau/status/1258881304268963845">closure</a>. <code class="language-plaintext highlighter-rouge">{ _ in }</code></p>
Issue #159
https://swiftweeklybrief.com/issue-159
2020-05-07T00:00:00-07:00
2020-05-07T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks started quite slow, but now it seems that things are starting to heat up. Apple has released more information about <a href="https://developer.apple.com/wwdc20/">WWDC 2020</a>, announcing it will take off on June 22.</p>
<p>Also, Google Summer of Code 2020 students have been <a href="https://forums.swift.org/t/announcing-our-google-summer-of-code-2020-students/36147">announced</a>. They will be working on important and exciting projects for Swift over the summer, being mentored by the people at Apple!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://swiftbysundell.com/podcast/71/">episode 71</a> of the Swift by Sundell podcast, <a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> joins <a href="https://twitter.com/johnsundell">John Sundell</a> to talk about Protocol-Oriented Programming and how to make the most out of the Swift Standard Library. Also, discussions on Swift’s overall design, why it puts such a strong emphasis on value types and protocols, and how it’s been influenced by other languages.</p>
<h3 id="news-and-community">News and community</h3>
<p>An <a href="https://swift.org/blog/additional-linux-distros/">announcement</a> has been made about even more Linux platforms officially supporting Swift.</p>
<p>Development is open for <a href="https://forums.swift.org/t/development-open-for-swift-5-2-4-for-linux/36231">Swift 5.2.4 for Linux</a>, with a planned release at the end of May 2020.</p>
<p><a href="https://twitter.com/c10um0">Kenta Kubo</a> tweeted <a href="https://twitter.com/c10um0/status/1255537044853362688">how to use a SwiftPM package on Swift Playgrounds on iPad</a> by using Working Copy and Textastic.</p>
<p><a href="https://forums.swift.org/u/drexin/summary">Dario Rexin</a> announced <a href="https://forums.swift.org/t/swift-5-2-3-for-linux/35991">Swift 5.2.3 for Linux</a>.</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> shared tweeted <a href="https://twitter.com/twostraws/status/1255875829541875714">some of the features</a> coming in Swift 5.3.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/31393">a pull request</a> that ripped out the old dependency graph implementation.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> merged <a href="https://github.com/apple/swift/pull/30994">a pull request</a> that fixes <code class="language-plaintext highlighter-rouge">_modify</code> for wrapped properties with observers. It got some <a href="https://twitter.com/steipete/status/1255751675853377537">community</a> members very <a href="https://twitter.com/twostraws/status/1255602271720742912">excited</a>. :)</p>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> created <a href="https://github.com/apple/swift-nio/pull/1499">a pull request</a> that allows completely single-threaded NIO programs.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/31543">a pull request</a> that extends function builders with support for <code class="language-plaintext highlighter-rouge">for..in</code> loops.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> opened <a href="https://github.com/apple/swift/pull/31187">a pull request</a> that removes the integrated REPL. Read more on the forum <a href="forums.swift.org/t/rfc-removing-the-integrated-repl/35441">discussion</a>.</p>
<blockquote>
<p>The integrated REPL has been deprecated in favor of the LLDB REPL for a while, and the implementation had accumulated some amount of technical debt throughout the code base. Since most people don’t use it and are not even aware that it exists, we can remove it.</p>
</blockquote>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md">SE-0279</a>: <em>Multiple Trailing Closures</em> was <a href="https://forums.swift.org/t/se-0279-multiple-trailing-closures-amended/35435/197">accepted in its second review</a>.</p>
<blockquote>
<p>The amended proposal was received more positively. Several reviewers who had opposed the original proposal were now unreservedly in favor. Others supported the new proposal overall but expressed a preference for also allowing an argument label on the first closure.</p>
<p>However, many reviewers continued to oppose the amended proposal. Some reviewers expressed their dislike of trailing closures overall, or disputed the need to allow multiple trailing closures. The core team continues to believe, as we stated at the start of the second review, that the underlying motivation for the proposal is sound and changes here are merited. Other reviewers disliked the specifics of the change or felt that it was not tenable without allowing an argument label on the first closure or without substantial changes to the model for type-checking calls with trailing closures.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0282-atomics.md">SE-0282</a> has been <a href="https://forums.swift.org/t/se-0282-low-level-atomic-operations/35382/69">returned for revision</a>.</p>
<blockquote>
<p>During the review, support was nearly unanimous for the memory model the proposal establishes, bringing Swift in line with the model standardized by C. The core team concurs with the review discussion on this subject, and would like to see a revised proposal that focuses on specifying the memory model. Guaranteeing a C-compatible memory model allows developers that currently wrap atomic primitives written in C and import them into Swift to rely on this continuing to work. This would also provide stable ground for building atomics packages outside of the standard library for experimentation and use by early adopters. The Swift project itself plans to develop one of these packages</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0283-tuples-are-equatable-comparable-hashable.md">SE-0283</a>: <em>Tuples Conform to <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Comparable</code>, and <code class="language-plaintext highlighter-rouge">Hashable</code></em> is <a href="https://forums.swift.org/t/se-0283-tuples-conform-to-equatable-comparable-and-hashable/36140">under review</a>.</p>
<blockquote>
<p>Introduce <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Comparable</code>, and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance for all tuples whose elements are themselves <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Comparable</code>, and <code class="language-plaintext highlighter-rouge">Hashable</code>.</p>
<p>Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favor of structures that they can them conform protocols to. The shift from tuples to structures have made tuples almost feel like a second class type in the language because of them not being able to do simple operations that should just work.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/migueldeicaza">Miguel de Icaza</a> pitched <a href="https://forums.swift.org/t/swift-package-installation/35728">a proposal</a> on Swift package installation.</p>
<blockquote>
<p>It would be desirable to simplify the use of executables that have been compiled with swift build and installing the binary, payloads and other requirements into either a global location usable by all users on the system, or make it available only to the current user.</p>
<p>This would simplify the distribution and usage of Swift-authored tools, as instructions for installing the software would be as simple as directing the user to type swift tool install.</p>
</blockquote>
<p><a href="https://twitter.com/jshier">Jon Shier</a> started <a href="https://forums.swift.org/t/newtype-for-swift/35859">a discussion</a> about <code class="language-plaintext highlighter-rouge">newtype</code>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">newtype</code> has <a href="https://forums.swift.org/t/newtype-without-automatic-protocol-forwarding/16110/31">come up again</a> and since I don’t have a specific pitch I thought I’d start some discussion outside of the older thread. Before diving into specific syntax or implementation details I think it would be good to gather ideas about what people want out of such a feature and what they feel is most important.</p>
</blockquote>
<p><a href="https://twitter.com/lukasaoz">Cory Benfield</a> pitched <a href="https://forums.swift.org/t/extensible-enumerations-for-non-resilient-libraries/35900">a proposal</a> to enable non-resilient Swift libraries to provide “extensible” enums.</p>
<blockquote>
<p>This proposal adds an attribute to allow Swift enumerations to opt-in to an extensible behaviour. This reconciles a feature mismatch between resilient and non-resilient dialects of Swift, and makes Swift enumerations vastly more useful in the public API of non-resilient Swift libraries.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/DevAndArtist">Adrian Meister</a> ask about <a href="https://forums.swift.org/t/breaking-changes-in-swift-6/35928">what kind of breaking changes</a> are considered/allowed in Swift 6.</p>
<blockquote>
<blockquote>
<p>There could also be an opportunity for us to eliminate the language dialect here in Swift 6, and make it so that the next breaking change of the language always defaults enums to non-frozen behavior in all modules.</p>
</blockquote>
<p>I read these kind of things very frequent in the last couple weeks. That makes me wonder, what kind of breaking changes are considered/allowed in Swift 6? There are a couple other things that come to my mind that would require a breaking change to be really fixed / work.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/DavidGoldman">David Goldman</a> pitched <a href="https://forums.swift.org/t/sourcekit-lsp-file-status-ux/35947">a proposal</a> to add some indication of file status to SourceKit-LSP.</p>
<blockquote>
<ol>
<li>Give the user an idea of what they should expect - is the build system initializing? Does the
build system recognize the file? Is (pre)building still required before full functionality can
occur?
<ul>
<li>This will increased perceived reliability as long as these statuses are accurate and clear</li>
<li>SourceKit-LSP can also change behavior based on these states, e.g. potentially hold back
diagnostics if the build system still needs to prebuild.</li>
</ul>
</li>
<li>Make the clangd/sourcekitd loading state clear. This helps isolate build system vs. compiler
issues and lets the user know the compiler is working (even if we can’t provide progress estimates)</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/k__mahar">Kaitlin Mahar</a> pitched <a href="https://forums.swift.org/t/feedback-mongodb-swift-driver/35989">a proposal</a> to create a MongoDB Swift driver.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">mongo-swift-driver</code> is a client library for using MongoDB from Swift. Its module <code class="language-plaintext highlighter-rouge">MongoSwift</code> provides a SwiftNIO-based asynchronous API for interacting with the database. The core type, <code class="language-plaintext highlighter-rouge">MongoClient</code>, maintains a pool of connections to servers in a MongoDB deployment and provides an interface for querying, inserting, and updating data in the deployment. In addition, the client handles authentication, TLS, topology monitoring, and automatically retrying failed commands. The driver also contains a <a href="https://docs.mongodb.com/manual/reference/bson-types/">BSON</a> implementation allowing users to create and manipulate MongoDB documents and to convert between documents and native Swift types.</p>
</blockquote>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> pitched <a href="https://forums.swift.org/t/pitch-make-never-the-bottom-type/36013">a proposal</a> making <code class="language-plaintext highlighter-rouge">Never</code> a true bottom type in Swift.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md">SE-0102</a> introduced the <code class="language-plaintext highlighter-rouge">Never</code> type, an enum with no cases, as a way of conveying to both the compiler and user that a function cannot return by normal means. Instead, a <code class="language-plaintext highlighter-rouge">Never</code>-returning function might throw an error, trap, or simply never terminate. Over time, the type’s uses have expanded to model other “impossible” situations. For example, thanks to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0215-conform-never-to-hashable-and-equatable.md">SE-0215</a>, which conformed Never to Error, one can construct a <code class="language-plaintext highlighter-rouge">Result<String, Never></code> which is guaranteed to represent a success state</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched <a href="https://forums.swift.org/t/fix-inconsistency-for-sequence-max/36063">a proposal</a> that modifies the behavior of the <code class="language-plaintext highlighter-rouge">Sequence.max</code> algorithms to match the free <code class="language-plaintext highlighter-rouge">max(...)</code> functions in cases where there is more than one “maximum” element.</p>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-12113">SR-12113</a> asks that we codify the behavior of the <code class="language-plaintext highlighter-rouge">min</code> and <code class="language-plaintext highlighter-rouge">max</code> methods on sequences into a guarantee in the documentation. Unfortunately, the current behavior of the max methods is inconsistent with other places in the standard library that identify the maximum of two or more inputs, when there is more than one “maximum” value.</p>
<p>Specifically, the sequence method returns the first of several maximum elements in the sequence, while the other APIs (the max free functions and the <code class="language-plaintext highlighter-rouge">FloatingPoint.maximum</code> static methods) return the last of the maximum values. In general, this difference behavior isn’t noticeable, but for class instances it’s observable through instance identity, and when using the predicate-based method can be observed through whatever properties aren’t included.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/tcldr">tcldr</a> pitched <a href="https://forums.swift.org/t/convenience-member-on-result-when-when-success-is-void/36134">a proposal</a> about a tiny refinement to the Standard Library to provide a convenience member on <code class="language-plaintext highlighter-rouge">Result</code> when <code class="language-plaintext highlighter-rouge">Success</code> is <code class="language-plaintext highlighter-rouge">Void</code>.</p>
<blockquote>
<p>Result types with a success type of Void are commonly used when no further information about the result of the operation are required – other than to know it was successful. In these cases, it is necessary to return a Result via <code class="language-plaintext highlighter-rouge">Result.success(())</code>.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<ul>
<li>
<p>A cool project by [Krzysztof Siejkowski] - <a href="https://swiftpoetry.com/">a collection of poems</a> written in Swift.</p>
</li>
<li>
<p>Swift on a <a href="https://twitter.com/tkremenek/status/1256039832754634753">shot glass</a>… that must have a story behind it?</p>
</li>
</ul>
Issue #158
https://swiftweeklybrief.com/issue-158
2020-04-23T00:00:00-07:00
2020-04-23T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It still feels strange to me that every time I start writing this introduction,
I think about the two weeks that have just flown by. It makes me appreciate
how valuable time can be, and makes it feel worth it to provide all of you with
an overview of what’s been happening in the “world of Swift”.</p>
<p>I also want to give another massive <em>thank you</em> to <a href="https://twitter.com/fassko">Kristaps</a>,
whose contributions are what make it possible for me to continue writing these
issues.</p>
<p>I’d like to encourage you to stand still and reach out to or thank someone that
has been helping you — speaking from my experience, it really makes a
difference.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-12648">SR-12648</a> [Standard Library]
<code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code>’s <code class="language-plaintext highlighter-rouge">filter</code> uses an intermediate array</li>
<li><a href="https://bugs.swift.org/browse/SR-12605">SR-12605</a> [Compiler]
<code class="language-plaintext highlighter-rouge">#sourceLocation</code> doesn’t allow underscores in line numbers</li>
<li><a href="https://bugs.swift.org/browse/SR-12585">SR-12585</a> [Project Infrastructure]
Teach update-checkout to <code class="language-plaintext highlighter-rouge">fetch</code> before <code class="language-plaintext highlighter-rouge">checkout</code></li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/mattt">Mattt</a> announced <a href="https://github.com/SwiftDocOrg/DocTest">DocTest</a>,
an experimental tool for testing Swift example code in documentation. During
my brief foray in the land of Python, this is something I loved a lot about the
language. Mattt indicates Python’s <code class="language-plaintext highlighter-rouge">doctest</code> indeed inspired this work, too.</p>
<p>Xcode 11.4.1 <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_11_4_1_release_notes">was released</a>,
including a fix for a compiler crash and removed an incorrectly emitted error
for Swift packages.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0281-main-attribute.md">SE-0281</a>: <em><code class="language-plaintext highlighter-rouge">@main</code>: Type-Based Program Entry Points</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0281-main-type-based-program-entry-points/35400">accepted with modifications</a>.</p>
<blockquote>
<p>The feedback was generally positive and the proposal has been accepted with
one minor revision: the <code class="language-plaintext highlighter-rouge">main()</code> signature will be throwing.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0282-atomics.md">SE-0282</a>: <em>Low-Level Atomic Operations</em> is <a href="https://forums.swift.org/t/se-0282-low-level-atomic-operations/35382">under review</a>.</p>
<blockquote>
<p>This proposal adds a limited set of low-level atomic operations to the
Standard Library, including native spellings for C++-style memory orderings.
Our goal is to enable intrepid library authors to start building synchronization
constructs directly in Swift.</p>
<p>In Swift today, application developers use dispatch queues and Foundation’s
<code class="language-plaintext highlighter-rouge">NSLocking</code> protocol to synchronize access to mutable state across concurrent
threads of execution.</p>
<p>However, for Swift to be successful as a systems programming language, it
needs to also provide low-level primitives that can be used to implement such
synchronization constructs (and many more!) directly within Swift.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md">SE-0279</a>: <em>Multiple Trailing Closures</em> is <a href="https://forums.swift.org/t/se-0279-multiple-trailing-closures-amended/35435">under a second review</a>.</p>
<blockquote>
<p>This is the second review, with a modified proposal. The core team has
considered the feedback from the first review and believes that:</p>
<ul>
<li>the underlying motivation for the proposal <em>does</em> merit a change to the
language to better accommodate multiple trailing closures;</li>
<li>the concerns around the original proposed syntax warranted a rethink of the
proposed solution.</li>
</ul>
<p>The proposal authors have a revised proposal that aims to address some of
those concerns.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/daniel_dunbar">Daniel Dunbar</a> shared his <a href="https://forums.swift.org/t/my-swiftpm-wishlist-aka-proposal-proposals/35292">SwiftPM wishlist</a>:</p>
<blockquote>
<p>[..] one thing that occurred to me is that it might not be very clear to the
community what are concrete examples of things kinds of enhancement proposals
that are good candidates.</p>
<p>Also, while I barely contribute to SwiftPM anymore, we make very heavy use of
SwiftPM in the work our team currently does, so I have a lot of opinions from
managing large & complex graphs of SwiftPM projects.</p>
<p>With that in mind, here is my own personal “wishlist” of SwiftPM enhancements
that are also <em>unblocked</em> from my perspective, in the sense that if someone
wanted to show up with a proposal and an implementation, the project would be
eager to work towards accepting them.</p>
</blockquote>
<p>See <a href="https://forums.swift.org/t/my-swiftpm-wishlist-aka-proposal-proposals/35292">the full post</a>
for a list of “proposal proposals”.</p>
<p><a href="https://twitter.com/pthariensflame">Alexander Ronald Altman</a> pitched <a href="https://forums.swift.org/t/declaration-like-argument-blocks/35336">a proposal</a>
to add declaration-like argument blocks.</p>
<blockquote>
<p>There have been a fair number of proposals for making multiple closure
arguments to a function look nicer and be more readable—most recently <a href="https://forums.swift.org/t/se-0279-multiple-trailing-closures/34255">SE-279</a>.
These have all come up against ergonomic issues and lack of community consensus
because they assume something close to the trailing closure syntax is what’s
needed. I’d like to propose a very different approach, inspired directly by <a href="https://ceylon-lang.org/documentation/1.3/reference/expression/named-argument-list/">a
hitherto unique feature of the language Ceylon</a>,
and which counterintuitively makes a complicated call site easier to read by
increasing its length and verbosity (but also its expressiveness and
formattability). I call these <strong>Declaration-Like Argument Blocks</strong>, and the
intuitive idea is to make a complicated call site look a lot like a class or
struct declaration.</p>
</blockquote>
<p><a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> shared <a href="https://forums.swift.org/t/solving-the-mutating-slice-cow-problem/35297">an update</a>
on solving the mutating slice Copy on Write problem.</p>
<blockquote>
<p><a href="https://bugs.swift.org/browse/SR-12524">SR-12524</a> describes a problem we’ve
had since the earliest days of Swift. For years there has been talk of solving
it with language features, and in fact we got one of the necessary features in
coroutine accessors. I think I can now demonstrate it’s the only feature we
needed, and I’ll propose we incorporate this capability into the standard
library.</p>
</blockquote>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> shared <a href="https://forums.swift.org/t/sketching-out-more-efficient-variadics/35346">some thoughts</a>
and sketched out more efficient variadics.</p>
<blockquote>
<ol>
<li>Variadics and array literals both default to allocating Arrays, which
usually means a heap allocation.</li>
<li>The compiler can already stack-promote Arrays <em>if</em> it can prove that there
are no outstanding references to the Array instance.</li>
<li>But it’s hard to do that through a non-inlinable function call.</li>
<li>We can sidestep that problem today by using <code class="language-plaintext highlighter-rouge">UnsafeBufferPointer</code>.</li>
<li>When move-only types come along, we’re <em>close</em> to being able to make a
safe <code class="language-plaintext highlighter-rouge">BorrowedBuffer</code> type. (Which we’ll very likely want anyway, for other
purposes.)</li>
<li>If we then come up with a syntax to allow types other than <code class="language-plaintext highlighter-rouge">Array</code> to be
used for variadic parameters, we get safe stack-allocated variadics out of it.
(I don’t much care what the syntax is at the moment.)</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> pitched <a href="https://forums.swift.org/t/renaming-trailing-closure-functions-in-the-standard-library/35454">a proposal</a>
to rename trailing closure functions in the standard library.</p>
<blockquote>
<p>A review of the standard library should be undertaken on all high-order
functions to determine whether their argument label is important, and if so,
recommend adding a second method with the argument label hoisted into the
basename. This would be source breaking, but justified under the “active harm”
exception, since the readability of methods such as <code class="language-plaintext highlighter-rouge">drop(while:)</code> is currently
severely impaired by dropping the argument label. The original method should be
deprecated over time (probably when we next introduce a new language variant).</p>
<p>Note, not all argument labels are necessary for readability, and would have
been better left out altogether. These should be left alone rather than changed
for consistency, since the bar for source breakage is high.</p>
</blockquote>
<p><a href="https://twitter.com/inthehands">Paul Cantrell</a> pitched <a href="https://forums.swift.org/t/allow-key-paths-to-reference-unapplied-instance-methods/35582">a proposal</a>
to allow key paths to reference unapplied instance methods.</p>
<blockquote>
<p>The <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md">original key path proposal</a>
expressly limited key paths to be able to reference only properties and
subscripts:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">\</span><span class="kt">Person</span><span class="o">.</span><span class="n">name</span> <span class="c1">// KeyPath<Person, String></span>
<span class="p">\</span><span class="kt">Person</span><span class="o">.</span><span class="n">pets</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span> <span class="c1">// KeyPath<Person, Pet></span>
</code></pre></div></div>
<blockquote>
<p>This proposal adds the ability for key paths to reference instance methods,
optionally specifying argument names:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">\</span><span class="kt">Person</span><span class="o">.</span><span class="n">sing</span> <span class="c1">// KeyPath<Person, () -> Sound></span>
<span class="p">\</span><span class="kt">Person</span><span class="o">.</span><span class="nf">sing</span><span class="p">(</span><span class="nv">melody</span><span class="p">:</span><span class="nv">lyrics</span><span class="p">:)</span> <span class="c1">// KeyPath<Person, (Melody, String) -> Sound></span>
</code></pre></div></div>
<blockquote>
<p>Note that these key paths do not provide argument values; they reference
<em>unapplied</em> methods, and the value they give is a function, not the the value
that results from calling the method.</p>
<p>Adding this capability not only removes an inconsistency in Swift, but also
solves practical problems involving <code class="language-plaintext highlighter-rouge">map</code>/<code class="language-plaintext highlighter-rouge">filter</code> operations, proxying with
key path member lookup, and passing weak method references that do not retain
their receiver.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Joe Groff <a href="https://twitter.com/jckarter/status/1249098635813376003">never fails to a maïs</a> 🌽</p>
Issue #157
https://swiftweeklybrief.com/issue-157
2020-04-09T00:00:00-07:00
2020-04-09T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>This issue, I’ll keep this short and sweet. I hope you’re all staying healthy
and at home.</p>
<p>Enjoy the issue!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-12460">SR-12460</a> [Compiler] Declaring an
operator inside an extension without a name crashes the compiler</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://atp.fm/episodes/371">episode 371 of the Accidental Tech Podcast</a>
(ATP), <a href="http://www.marco.org/">Marco Arment</a>,
<a href="http://www.caseyliss.com/">Casey Liss</a>,
<a href="http://hypercritical.co/">John Siracusa</a>, and
<a href="http://www.nondot.org/sabre/">Chris Lattner</a> discuss TensorFlow, Multi-Level
Intermediate Representation, Swift’s future and more.</p>
<p>In <a href="https://www.swiftcommunitypodcast.org/episodes/8">episode 8 of the Swift Community Podcast</a>,
<a href="https://twitter.com/KateCastellano">Kate Castellano</a>,
<a href="https://twitter.com/twostraws">Paul Hudson</a>,
<a href="https://twitter.com/clattner_llvm">Chris Lattner</a>, and
<a href="https://twitter.com/basthomas">Bas Broek</a> discuss
<a href="https://www.swiftforgood.com/">Swift for Good</a>, a book on Swift with 100% of
all revenue going to charity.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared that Apple <a href="https://twitter.com/tkremenek/status/1243235856791429122">is sponsoring
PLDI this year</a> — the
Programming Language Design and Implementation conference. As Ted said:</p>
<blockquote>
<p>Swift has drawn inspiration from many programming languages and those of us
working on Swift are proud to be part of the broader programming language
community.</p>
</blockquote>
<p><a href="https://twitter.com/mattt">Mattt</a> wrote <a href="https://nshipster.com/swift-log/">an article</a>
on <code class="language-plaintext highlighter-rouge">swift-log</code>, a community-driven, open-source standard for logging in Swift,
backed by Apple.</p>
<p>Furthermore, Mattt <a href="https://github.com/SwiftDocOrg/swift-doc">announced</a>
<code class="language-plaintext highlighter-rouge">swift-doc</code>, generating documentation for Swift projects.</p>
<p><a href="https://twitter.com/jasdev">Jasdev Singh</a> wrote <a href="https://jasdev.me/fusion-primer">an article</a>
talking about the “fusion” term he struggled to build intuition around until he
read through Combine’s documentation.</p>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> announced <a href="https://forums.swift.org/t/windows-nio/35003">SwiftNIO is now
running on Windows</a>!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> merged <a href="https://github.com/apple/swift/pull/27776">a pull request</a>
which implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md">SE-0276</a>: <em>Multi-Pattern Catch Clauses</em>. Awesome!</p>
<p><a href="https://twitter.com/CodaFi_">Robert Widmann</a> merged <a href="https://github.com/apple/swift/pull/30723">a pull request</a>
with a new approach for recording incremental build dependencies using the
request evaluator, paving the way for faster builds in the future. 🏎</p>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> merged <a href="https://github.com/apple/swift/pull/26632">a pull request</a>
implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0268-didset-semantics.md">SE-0268</a>: <em>Refine <code class="language-plaintext highlighter-rouge">didSet</code> Semantics</em>, as well as <a href="https://github.com/apple/swift/pull/28916">a pull request</a> implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0280-enum-cases-as-protocol-witnesses.md">SE-280</a>: <em>Enum cases as protocol witnesses</em>.</p>
<p><a href="https://twitter.com/stephentyrone">Stephen Canon</a> merged <a href="https://github.com/apple/swift/pull/30130">a pull request</a>
implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0277-float16.md">SE-0277</a>: <em><code class="language-plaintext highlighter-rouge">Float16</code></em>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0280-enum-cases-as-protocol-witnesses.md">SE-0280</a>: <em>Enum cases as protocol witnesses</em> was <a href="https://forums.swift.org/t/accepted-se-0280-enum-cases-as-protocol-witnesses/34850">accepted</a>.</p>
<blockquote>
<p>Almost all of the feedback we received was in favor of making this change,
and the Core Team is convinced that this closes an unnecessary semantic gap
between enums and other types.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0281-main-attribute.md">SE-0281</a>: <em><code class="language-plaintext highlighter-rouge">@main</code>: Type-Based Program Entry Points</em> is <a href="https://forums.swift.org/t/se-0281-main-type-based-program-entry-points/34948">under review</a>.</p>
<blockquote>
<p>A Swift language feature for designating a type as the entry point for
beginning program execution. Instead of writing top-level code, users can use
the <code class="language-plaintext highlighter-rouge">@main</code> attribute on a single type. Libraries and frameworks can then
provide custom entry-point behavior through protocols or class inheritance.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/DaveAbrahams">Dave Abrahams</a> pitched <a href="https://forums.swift.org/t/a-better-data-pretty-printer/34914">a proposal</a>
to introduce a better data pretty-printer.</p>
<blockquote>
<p>With this post, I hope to open a discussion of the design requirements for a
library, similar to Python’s <a href="https://docs.python.org/3.4/library/pprint.html">pprint</a>,
that could eventually be incorporated into the standard library and inform the
design of many parts of the Swift ecosystem.</p>
<p>There are many contexts—from educational/research tools like Playgrounds and
<a href="https://colab.research.google.com/notebook#create=true&language=swift">Colab Notebooks</a>
to industrial programming activities like debugging and logging, in which it’s
important to be able to easily visualize/understand Swift data structures. For
consumption by actual humans, though, Swift’s facilities for formatting data
leave a <em>lot</em> to be desired.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/vitamin">Jon Gilbert</a> pitched <a href="https://forums.swift.org/t/property-initialization-using-a-keypath-within-an-init-method/35034">a proposal</a>
for Property initialization using a KeyPath within an <code class="language-plaintext highlighter-rouge">init</code> method.</p>
<blockquote>
<p>Given:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">struct</span> <span class="kt">Foo</span> <span class="p">{</span>
<span class="k">let</span> <span class="nv">bar</span><span class="p">:</span> <span class="kt">Int</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>In an <code class="language-plaintext highlighter-rouge">init</code> method, you can do:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nf">init</span><span class="p">()</span> <span class="p">{</span>
<span class="k">self</span><span class="o">.</span><span class="n">bar</span> <span class="o">=</span> <span class="mi">42</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>However, unfortunately, you cannot do:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nf">init</span><span class="p">()</span> <span class="p">{</span>
<span class="k">self</span><span class="p">[</span><span class="nv">keyPath</span><span class="p">:</span> <span class="p">\</span><span class="o">.</span><span class="n">bar</span><span class="p">]</span> <span class="o">=</span> <span class="mi">42</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>This error is thrown: “<code class="language-plaintext highlighter-rouge">self</code> used before all stored properties are
initialized.”</p>
<p>This seems like a compiler bug, or at least, a counter-intuitive aspect of
keypaths. If a property setter works on <code class="language-plaintext highlighter-rouge">self</code> before its properties are
initialized, then a <code class="language-plaintext highlighter-rouge">keyPath</code> subscript should also work.</p>
</blockquote>
<p><a href="https://twitter.com/yoshiboarder">Shawn Baek</a> pitched <a href="https://forums.swift.org/t/table-style-print-for-2d-array-dictionary-and-tuples/35121">a proposal</a>
for table style printing for two dimensional Arrays, Dictionaries, and tuples.</p>
<blockquote>
<p>The standard library <code class="language-plaintext highlighter-rouge">print</code> doesn’t support table-style output. So it is
hard to check the data in the 2D array.</p>
<p>Here is my suggestion.</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nf">print</span><span class="p">(</span>
<span class="nv">table</span><span class="p">:</span> <span class="p">[</span><span class="s">"Good"</span><span class="p">,</span> <span class="s">"Very Good"</span><span class="p">,</span> <span class="s">"Happy"</span><span class="p">,</span> <span class="s">"Cool!"</span><span class="p">],</span>
<span class="nv">header</span><span class="p">:</span> <span class="p">[</span><span class="s">"Wed"</span><span class="p">,</span> <span class="s">"Thu"</span><span class="p">,</span> <span class="s">"Fri"</span><span class="p">,</span> <span class="s">"Sat"</span><span class="p">]</span>
<span class="p">)</span>
</code></pre></div></div>
<blockquote>
<p>Output:</p>
</blockquote>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>+----+---------+-----+-----+
|Wed |Thu |Fri |Sat |
+----+---------+-----+-----+
|Good|Very Good|Happy|Cool!|
+----+---------+-----+-----+
</code></pre></div></div>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/dgregor79/status/1245935942973583366">Late at work</a>,
cleaning <a href="https://twitter.com/dgregor79/status/1245936440371867648">the cat’s litter box</a>.</p>
Issue #156
https://swiftweeklybrief.com/issue-156
2020-03-26T00:00:00-07:00
2020-03-26T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<div class="alert alert-success" role="alert">
<h3>A note from Bas on the <a class="alert-link" href="https://github.com/JohnSundell/IndieSupportWeeks">#IndieSupportWeeks</a></h3>
<p>While some of you might have heard about the #IndieSupportWeeks, many of you might not have.</p>
<p>It's an effort aimed at helping indie developers within the Apple Developer Community who have been financially impacted by the current global COVID-19 pandemic.</p>
<p>Curating this newsletter, it was an obvious decision to take part in this effort, and to highlight some indie apps in this issue. Do check them out, as well as <a class="alert-link" href="https://github.com/JohnSundell/IndieSupportWeeks">all other awesome apps</a> on the list.</p>
<p>If you decide to check out any of the apps — or to buy them — please also share it with the world using the #IndieSupportWeeks hashtag!</p>
<p>On behalf of all indie developers, thank you for the support!</p>
</div>
<p>Apple announced that WWDC 2020 will be an online-only event, and many of us are learning how to work remotely from our homes while we cope with the on-going health crisis. I hope everyone is staying safe.</p>
<p>Meanwhile, Swift 5.2 has been officially released with Xcode 11.4. So take a break from the news and spend some time updating your projects!</p>
<!--excerpt-->
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://www.swiftbysundell.com/podcast/69/">episode 69</a> of the Swift by Sundell podcast, <a href="https://twitter.com/hollyborla">Holly Borla</a> and <a href="https://twitter.com/gracekendall26">Grace Kendall</a>, both software engineers at Apple, join <a href="https://twitter.com/johnsundell">John Sundell</a> to take a deep dive into the Swift Playgrounds app and Swift 5.2’s new diagnostics engine.</p>
<div class="alert alert-warning sponsor">
<h4>Indie Support Weeks <a href="https://github.com/JohnSundell/IndieSupportWeeks">#IndieSupportWeeks</a></h4>
<h4><a href="https://outercorner.com/secrets/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_156" target="_blank">Secrets — Your Friendly Password Manager</a></h4>
<p>Just this year over 60M accounts have been exposed due to service breaches. Reusing passwords greatly increases your risk of getting hacked. Take some time during this lockdown to make sure you’re using strong and unique password on all the services you use, and securely store them in a password manager such as Secrets. Stay safe IRL and online!</p>
<p><small><a href="https://outercorner.com/secrets/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_156" target="_blank">outercorner.com/secrets</a> or download directly <a href="https://itunes.apple.com/app/secrets/id973049011" target="_blank">on the App Store</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p>Apple <a href="https://developer.apple.com/wwdc20/">announced</a> WWDC 2020 will be a completely online experience this year.</p>
<p>Apple <a href="https://swift.org/blog/swift-5-2-released/">released</a> Swift 5.2 and <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_11_4_release_notes">announced</a> Xcode 11.4.</p>
<p><a href="https://github.com/najacque/">Nicole Jacque</a> wrote <a href="https://swift.org/blog/5-3-release-process/">a blog post</a> about Swift 5.3 release process.</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> wrote <a href="https://www.hackingwithswift.com/articles/212/whats-new-in-swift-5-2">an article</a> explaining what’s new in Swift 5.2.</p>
<p><a href="https://twitter.com/zntfdr">Federico Zanetello</a> wrote two articles, one about <a href="https://www.fivestars.blog/code/a-look-into-argument-parser.html">the new ArgumentParser</a>, and another about <a href="https://www.fivestars.blog/code/executables-progress.html">Swift Executables Progress State</a>.
He also created a <a href="https://speakerdeck.com/zntfdr/whats-new-in-swift-5-dot-2">presentation</a> about new features in Swift 5.2.</p>
<p>A great <a href="https://drive.google.com/file/d/1gI6Zk2jS0-MNkckYBnRFNtVCHoGKHWct/view">talk</a> was shared about Swift for TensorFlow which would normally have been given at TF Dev Summit.</p>
<p>The Ray Wenderlich folks wrote a great <a href="https://www.raywenderlich.com/8016626-swiftnio-tutorial-practical-guide-for-asynchronous-problems">tutorial</a> on how to get started with SwiftNIO.</p>
<p><a href="https://twitter.com/rockbruno_">Bruno Rocha</a> wrote <a href="https://swiftrocks.com/useful-global-swift-functions.html">an article</a> about useful global Swift functions.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/28698">a pull request</a> that fixes unapplied references to protocol methods, which was one of the oldest and most highly duped bugs ever. 😱</p>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/30627">a pull request</a> created by <a href="https://github.com/LucianoPAlmeida">Luciano Almeida</a> that resolves <a href="https://bugs.swift.org/browse/SR-12382">SR-12382</a> and improves the diagnostic for type mismatches in pointer conversion to double optionals.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/30537">a pull request</a> that fixes handling of <code class="language-plaintext highlighter-rouge">@autoclosure</code> in <code class="language-plaintext highlighter-rouge">init(wrappedValue:)</code>.</p>
<p><a href="https://github.com/LucianoPAlmeida">Luciano Almeida</a> merged <a href="https://github.com/apple/swift/pull/30440">a pull request</a> that fixes <a href="https://bugs.swift.org/browse/SR-11540">SR-11540</a> by just disfavoring overloads to closures with anonymous var that are function types with more than one argument that matches arguments of function types without arguments.</p>
<div class="alert alert-warning sponsor">
<h4>Indie Support Weeks <a href="https://github.com/JohnSundell/IndieSupportWeeks">#IndieSupportWeeks</a></h4>
<h4><a href="https://usetimeless.app?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_156" target="_blank">Stay focused with Timeless</a></h4>
<p>Timeless is a subtle clock replacement. It helps you feel less anxious about the time and more focused on how you should be spending it. Try Timeless today.</p>
<p><small><a href="https://usetimeless.app?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_156" target="_blank">usetimeless.app</a> or download directly <a href="https://apps.apple.com/us/app/timeless/id1502382249" target="_blank">on the App Store</a></small></p>
</div>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/kitaisreal">Maksim Kita</a> pitched <a href="https://forums.swift.org/t/circular-buffer/34534">a proposal</a> to introduce a <code class="language-plaintext highlighter-rouge">Circular Buffer</code>.</p>
<blockquote>
<p>Introduce the <code class="language-plaintext highlighter-rouge">CircularBuffer</code> collection type conforming to the <code class="language-plaintext highlighter-rouge">RandomAccessCollection</code>,
<code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code> and <code class="language-plaintext highlighter-rouge">MutableCollection</code> protocols. With random element
access and support for constant back and forth element insertion and deletion.</p>
<p>Swift currently does not have collection with both element random access
and constant O(1) elements back and front insertion and deletion. A good
usage examples for such collection are queue, deque, fixed length buffers.
Such abstractions cannot effectively be build on Array because of O(n) first element deletion.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/aamir-nazir">Aamir Nazir</a> opened <a href="https://forums.swift.org/t/counting-occurrences-of-a-substring-in-a-string/34541/5">a discussion</a> about counting occurrences of a substring in a string.</p>
<blockquote>
<p>Given the fact that Swift String class doesn’t has any method for counting occurrences of a substring in a string. i.e
Counting occurrences of <code class="language-plaintext highlighter-rouge">"Swift"</code> in <code class="language-plaintext highlighter-rouge">"Hello Swift Swift"</code> => 2</p>
<p>There are many alternatives available for counting occurrences of substring but I think it would be more intuitive if we add support of counting occurrences of a substring in a string.</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched <a href="https://forums.swift.org/t/main-type-based-program-execution/34624">an idea</a> to add a new attribute that you can use to designate a type that provides the entry point for a Swift program.</p>
<blockquote>
<p>This is a generalization of the <code class="language-plaintext highlighter-rouge">@UIApplicationMain</code> and <code class="language-plaintext highlighter-rouge">@NSApplicationMain</code> attributes that have been in Swift from the beginning, making that specialized behavior available to any library or framework.</p>
<p>The Swift compiler will recognize a type annotated with the <code class="language-plaintext highlighter-rouge">@main</code> attribute as providing the entry point for a program. Types marked with <code class="language-plaintext highlighter-rouge">@main</code> have a single implicit requirement: declaring a static <code class="language-plaintext highlighter-rouge">main()</code> method.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/tomerd">Tom Doron</a> shared <a href="https://forums.swift.org/t/march-4th-2020/34617">meeting notes</a> for the Swift on the Server Workgroup March 4th, 2020 meeting.</p>
<p><a href="https://twitter.com/lorentey">Karoy Lorentey</a> pitched <a href="https://forums.swift.org/t/low-level-atomic-operations/34683">an idea</a> about Low-Level Atomic Operations.</p>
<blockquote>
<p>Here is a pitch for adding a limited set of low-level atomic operations to the Standard Library, including native spellings for C++-style acquire-release memory orderings. Our goal is to enable intrepid library authors to start building synchronization constructs directly in Swift.</p>
<p>This means we must start talking about how these things will work in Swift – in other words, we need to start working on a concurrency memory model. Given that Swift already interoperates with the C/C++ memory model, it seems like a good idea to use that as a starting point.</p>
</blockquote>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/new-swift-installer-for-windows/34692">an update on</a> the new Swift Installer for Windows.</p>
<p><a href="https://forums.swift.org/u/cal">Cal Stephens</a> started <a href="https://forums.swift.org/t/codingkeypath-add-support-for-encoding-and-decoding-nested-objects-with-dot-notation/34710">a discussion</a> about how to add a new <code class="language-plaintext highlighter-rouge">CodingKeyPath</code> type that allows consumers to key into nested objects using dot notation.</p>
<blockquote>
<p>Today, encoding and decoding Codable objects using the compiler’s synthesized implementation requires that your object graph has a one-to-one mapping to the object graph of the target payload. This decreases the control that authors have over their <code class="language-plaintext highlighter-rouge">Codable</code> models.</p>
<p>I propose that we add a new <code class="language-plaintext highlighter-rouge">CodingKeyPath</code> type that allows consumers to key into nested objects using <a href="https://developer.apple.com/documentation/objectivec/nsobject/1416468-value">dot notation</a>.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/HassanElDesouky">Hassan ElDesouky</a> started <a href="https://forums.swift.org/t/contribution-starter-guide/34747">a discussion</a> about creating a Swift contribution starter guide. Previously, he <a href="https://forums.swift.org/t/important-talks-and-articles-for-first-time-swift-contributors/34537">gathered</a> materials of important talks and articles for first time contributors.</p>
<p><a href="https://twitter.com/tanner0101">Tanner Nelson</a> shared the news <a href="https://forums.swift.org/t/vapor-4-official-release-begins/34802">of the official release of Vapor 4</a>.</p>
<div class="alert alert-warning sponsor">
<h4>Indie Support Weeks <a href="https://github.com/JohnSundell/IndieSupportWeeks">#IndieSupportWeeks</a></h4>
<h4><a href="https://sundialapp.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_156" target="_blank">Sundial - Solar & Lunar Times and Alerts</a></h4>
<p>Sundial provides essential sun and moon data in a compact, beautiful display. Create alerts for 24 solar/lunar events. Want to be notified 30 minutes before sunset to take the dog out for a walk? Piece of cake. Need an alert the day before full/new moon to take rest for Ashtanga yoga? No problem. For iPhone, iPad, and Apple Watch.</p>
<p><small><a href="https://sundialapp.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_156" target="_blank">sundialapp.com</a> or download directly <a href="https://apps.apple.com/us/app/sundial-sun-moon-times-alerts/id976460540" target="_blank">on the App Store</a></small></p>
</div>
<h3 id="finally">Finally</h3>
<p>Here’s a <a href="https://twitter.com/jckarter/status/1238669170767585280">great way</a> to print a comma-separated list.</p>
Issue #155
https://swiftweeklybrief.com/issue-155
2020-03-12T00:00:00-07:00
2020-03-12T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Another fortnight passed by, another Swift Weekly Brief. Enjoy!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p>In episode 85 of Swift Unwrapped, Jesse and JP talk <a href="https://spec.fm/podcasts/swift-unwrapped/317221">about Swift on Windows and other news</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/nnnnnnnn/">Nate Cook</a> wrote <a href="https://swift.org/blog/argument-parser/">a blog post</a> on Swift.org,
announcing ArgumentParser, an open-source library that makes it straightforward
— even enjoyable! — to parse command-line arguments in Swift.</p>
<p>Swift 5.1.5 <a href="https://swift.org/download/">has been released</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/30174">a pull request</a>
that adds <code class="language-plaintext highlighter-rouge">switch</code> statement support to function builders!</p>
<p>In that pull request, Doug pushed <a href="https://github.com/apple/swift/commit/ea8d143f6425e4db7ba78df82776cc075add1e22">a commit</a>
after a code review from <a href="https://twitter.com/pathofshrines">John McCall</a> who
noted a subtle omission in constraint generation that affected the semantics of
switch statements in function builders.</p>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> and <a href="https://github.com/tbkka">Tim K</a> merged <a href="https://github.com/apple/swift/pull/30329">a pull request</a> that provides a speedup for bridging
ObjC collections containing NSStrings.</p>
<p><a href="https://twitter.com/kubamracek">Kuba (Brecka) Mracek</a> merged <a href="https://github.com/apple/swift/pull/30112">a pull request</a>,
upstreaming arm64e support for Swift.</p>
<p>Also:</p>
<blockquote>
<p>this means we finally won’t have a billion arm64e merge conflicts every
single week</p>
</blockquote>
<p>Pretty neat!</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0280-enum-cases-as-protocol-witnesses.md">SE-0280</a>: <em>Enum cases as protocol witnesses</em> is <a href="https://forums.swift.org/t/se-0280-enum-cases-as-protocol-witnesses/34257">under review</a>.</p>
<blockquote>
<p>The aim of this proposal is to lift an existing restriction, which is that
enum cases cannot participate in protocol witness matching.</p>
<p>Currently, Swift has a very restrictive protocol witness matching model where
a protocol witness has to match <em>exactly</em> with the requirement, with some
exceptions (see <a href="https://forums.swift.org/t/protocol-witness-matching-mini-manifesto/32752">Protocol Witness Matching Manifesto</a>).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0279-multiple-trailing-closures.md">SE-0279</a>: <em>Multiple Trailing Closures</em> is <a href="https://forums.swift.org/t/se-0279-multiple-trailing-closures/34255">under review</a>.</p>
<blockquote>
<p>Since its inception, Swift has supported <em>trailing closure</em> syntax, which is
a bit of syntactic sugar that makes passing closures more ergonomic. Trailing
closures have always had two restrictions that limited their applicability.
First, that any call is limited to a single trailing closure, making the
feature awkward or even unusable when an API has more than one callback. This
limitation was noticed <a href="https://www.natashatherobot.com/swift-trailing-closure-syntax/">very early on in Swift’s
lifetime</a> as
“the” problem with trailing closure syntax. Second, that a trailing closure
argument does not provide an argument label, which can lead to call sites that
are less clear. This proposal removes both restrictions by providing an
unambiguous syntax for providing multiple, labeled trailing closures in a call,
leading to clearer and more consistent code.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twittter.com/jckarter">Joe Groff</a> provided <a href="https://forums.swift.org/t/update-on-se-0057/34246">an update</a>
on <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md">SE-0057</a>.</p>
<blockquote>
<p>The core team is continuing to review the status of older proposals in order
to bring their status into line with reality. SE-0057 introduced the ability
for Swift to import Objective-C lightweight generics as compile-time generic
types in Swift, with some limitations due to the type-erased nature of generics
in Objective-C. Although this proposal was accepted, and claimed to be in the
“Implemented” state, one aspect of the proposal was not implemented. The
originally accepted proposal described an informal protocol by with Objective-C
classes could optionally provide generic argument information back to Swift.</p>
<p>However, that informal protocol was never implemented. The Core Team has
decided to withdraw this aspect of the proposal.</p>
</blockquote>
<p><a href="https://github.com/Azoy">Alejandro Alonso</a> pitched <a href="https://forums.swift.org/t/tuples-conform-to-equatable-comparable-and-hashable/34156">a proposal</a>
to have tuples conform to <code class="language-plaintext highlighter-rouge">Equatable</code>, <code class="language-plaintext highlighter-rouge">Comparable</code>, and <code class="language-plaintext highlighter-rouge">Hashable</code>.</p>
<blockquote>
<p>Tuples in Swift currently lack the ability to conform to protocols. This has
led many users to stop using tuples altogether in favor of structures that they
can them conform protocols to. The shift from tuples to structures have made
tuples almost feel like a second class type in the language because of them not
being able to do simple operations that should <em>just</em> work.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/varun_gandhi/summary">Varun Gandhi</a> raised <a href="https://forums.swift.org/t/abi-compatibility-hazards-and-new-language-proposals/34347">a question</a>
about ABI compatibility and language proposals.</p>
<blockquote>
<p>One implication of <a href="https://forums.swift.org/t/se-0280-enum-cases-as-protocol-witnesses">SE-0280</a>
is that it introduces a way into the language in which one can break binary
compatibility without breaking source compatibility. More specifically, one can
make a property witness and replace that with an enum case (which also acts as
a witness) but this would break binary compatibility (the other way round
breaks source compatibility, as a client may be pattern-matching on the enum
case you’re getting rid of). There are already other ways in which this happens
today (such as with <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0267-where-on-contextually-generic.md">SE-0267</a>),
but this proposal adds one more way this can happen.</p>
<p>Compared to most other languages, Swift has a much better story around binary
compatibility. Part of the reason why I really like the design is that (in the
majority of cases) changes that “should” not break binary compatibility do not
break binary compatibility. To reappropriate the phrase, fast and loose
reasoning is morally correct with regard to binary compatibility – (in the
majority of cases) source-equivalent code is ABI-equivalent.</p>
<p>If we add more cases like this, that adds an extra wrinkle that users need to
be wary about. I suspect that a large fraction of users of this feature will
probably not be affected by this change. A small percentage of people might be
affected: should we have a backup plan for them?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1234598045511106561">1, 2, 3, 4, 5, 6, 7, 8, 9, X</a></p>
Issue #154
https://swiftweeklybrief.com/issue-154
2020-02-27T00:00:00-08:00
2020-02-27T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I’ve been keeping myself busy the last two weeks with exciting things going on
at work, and visiting other offices. We’ve also been hard at work on
preparations for the SwiftAveiro conference, which I’m co-organizing this year.</p>
<p>All in all, cool stuff going on!</p>
<p>That said, here’s what kept some other people busy these past two weeks…</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://nativeconnect.app?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_154" target="_blank">NativeConnect is a beautiful desktop client for App Store Connect</a></h4>
<p>Hey 👋 We are building a Mac app which is 💯 Swift and AppKit<br /> 1. View downloads and sales on the same page<br /> 2. Edit metadata for multiple languages in batches<br /> 3. Manage customer reviews and developer responses<br /> 4. All fetched data is stored locally and never leaves your Mac<br /> 5. Customers love it ❤️</p>
<p><small><a href="https://nativeconnect.app?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_154" target="_blank">nativeconnect.app</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-12247">SR-12247</a> [Compiler] Replace the
type alias <code class="language-plaintext highlighter-rouge">ModuleDecl::ImportedModule</code> with a dedicated struct</li>
<li><a href="https://bugs.swift.org/browse/SR-12248">SR-12248</a> [TypeChecker] <code class="language-plaintext highlighter-rouge"><unknown></code>
diagnostic location regarding <code class="language-plaintext highlighter-rouge">Codable</code> derived conformances</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://github.com/gribozavr">Dmitri Gribenko</a> shared <a href="https://github.com/apple/swift/blob/master/docs/CppInteroperabilityManifesto.md">the Swift and C++ interoperability manifesto</a>, summarized
possible design options of this goal.</p>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> wrote <a href="https://swift.org/blog/preview-package/">a blog post</a>
on the Swift.org blog, on the newly released Standard Library Preview Package.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> wrote <a href="https://swift.org/blog/library-evolution/">a blog post</a>
on the Swift.org blog, on Swift’s library evolution capabilities.</p>
<p><a href="https://twitter.com/wlisac">Will Lisac</a> open sourced <a href="https://github.com/wlisac/swift-log-slack">a project</a>
on top of <code class="language-plaintext highlighter-rouge">swift-log</code> that allows you to send logging messages to Slack.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/MaxDesiatov">Max Desiatov</a> merged <a href="https://github.com/apple/swift/pull/29530">a pull request</a>,
upstreaming almost a quarter of the huge patch from the <a href="https://github.com/swiftwasm">SwiftWasm</a>
team, which brings us closer to enabling WebAssembly/<a href="https://wasi.dev/">WASI</a>
target in the compiler and running Swift code in browsers.</p>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> merged <a href="https://github.com/apple/swift/pull/24303">a pull request</a>
that adds the new uninitialized buffer String initializer privately, improving
its performance.</p>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/29906">a pull request</a>
mostly finishing the diagnostics engine rewrite, and the people working on the
expression checker are now ready to rip out the old implementation completely!</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/30045">a pull request</a>
to add support for patterns in “if” statements for function builders, so one
can use <code class="language-plaintext highlighter-rouge">if-let</code>, <code class="language-plaintext highlighter-rouge">if-case</code>, etcetera.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0277-float16.md">SE-0277</a>: <em>Float16</em> was <a href="https://forums.swift.org/t/accepted-se-0277-float16/34121">accepted</a>.</p>
<blockquote>
<p>The review has concluded and the proposal is accepted.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274</a>: <em>Concise magic file names</em> was <a href="https://forums.swift.org/t/accepted-se-0274-concise-magic-file-names/34115">accepted</a>.</p>
<blockquote>
<p>The second review has concluded and the proposal has been accepted.</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">#file</code> will be altered to only report the module and filename</li>
<li><code class="language-plaintext highlighter-rouge">#filePath</code> will be introduced to replicate the previous full file+path for
use cases that relied on the path previously.</li>
<li>While the team acknowledges that this does require some existing workflows to
adapt to the new scheme, the binary size and privacy concerns over implicitly
embedding the full path were significant enough to warrant this change.</li>
</ul>
<p>During the second review, the format of the new <code class="language-plaintext highlighter-rouge">#file</code> value was discussed
and will be locked down in a way that users can rely on. The core team expects
future tooling to be created that will allow for easy processing of this value.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0278-package-manager-localized-resources.md">SE-0278</a>: <em>Package Manager Localized Resources</em> is <a href="https://forums.swift.org/t/se-0278-package-manager-localized-resources/33950">under review</a>.</p>
<blockquote>
<p>This proposal builds on top of the <a href="0271-package-manager-resources.md">Package Manager Resources</a> proposal to allow defining localized versions of resources in the SwiftPM manifest and have them automatically accessible at runtime using the same APIs.</p>
<p>The recently accepted <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md">Package Manager Resources</a>
proposal allows SwiftPM users to define resources (images, data file, etc…)
in their manifests and have them packaged inside a bundle to be accessible at
runtime using the Foundation <code class="language-plaintext highlighter-rouge">Bundle</code> APIs. Bundles support storing different
versions of resources for different localizations and can retrieve the version
which makes most sense depending on the runtime environment, but SwiftPM
currently offers no way to define those localized variants.</p>
<p>While it is technically possible to benefit from localization today by
setting up a resource directory structure that the <code class="language-plaintext highlighter-rouge">Bundle</code> API expects and
specifying it with a <code class="language-plaintext highlighter-rouge">.copy</code> rule in the manifest (to have SwiftPM retain the
structure), this comes at a cost: it bypasses any platform-custom processing
that comes with <code class="language-plaintext highlighter-rouge">.process</code>, and doesn’t allow SwiftPM to provide diagnostics
when localized resources are mis-configured.</p>
<p>Without a way to define localized resources, package authors are missing out
on powerful Foundation APIs to have their applications, libraries and tools
adapt to different regions and languages.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/swift-soars-ever-higher/34036">that Foundation’s full test suite passes on Windows</a>!</p>
<blockquote>
<p>I am extremely excited to announce that as of today we have the full test
suite for Foundation passing on Windows as well! Although there are a few tests
which are testing Unix specific behaviors which do not port, this is largely on
parity with the Linux test suite. There are a total of 1706 tests on Windows
that are running with Linux currently having 1714.</p>
</blockquote>
<p><a href="https://twitter.com/kateinoigakukun">Yuta Saito</a> shared <a href="https://forums.swift.org/t/wasm-support/16087/14">an update</a>
on the progress of the WebAssembly compiler target.</p>
<blockquote>
<p>Now that the swiftwasm project succeeds to pass quite a few tests in its test
suite, we are planning to send some patches to upstream.</p>
<p>Before sending them, I want to confirm and clarify the direction of
supporting WebAssembly.</p>
</blockquote>
<p><a href="https://twitter.com/broadway_lamb">Sergej Jaskiewicz</a> shared <a href="https://forums.swift.org/t/support-building-rust-targets-in-spm/33898">an idea</a>
to add support for Rust targets to the Swift Package Manager.</p>
<blockquote>
<p>I’ve just come up with this crazy idea: what if we allow SPM to build Rust
targets?</p>
<p>For now I have the following in mind:</p>
<ul>
<li>Obviously, for building Rust targets the rust toolchain has to be installed.</li>
<li>We don’t use Cargo for building Rust targets, but rather invoke <code class="language-plaintext highlighter-rouge">rustc</code>
directly. We could allow Swift packages to depend on Cargo packages in the
future, but that seems nontrivial.</li>
<li>Rust targets can only depend on other Rust targets. Swift or Clang targets
cannot depend on Rust targets. Why? Because it would require a lot of work.
Later we could allow Rust targets to have the “include” directory just like
Clang targets, which would contain C headers for that target so that the Rust
target could be used from Swift using those headers (just like C++ targets
today can be used from Swift via C headers).</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/_AngeloidBeta">Gwynne Raskind</a> pitched <a href="https://forums.swift.org/t/property-wrapper-requirements-in-protocols/33953">a proposal</a>
to add property wrapper requirements in protocols.</p>
<blockquote>
<p>It is sometimes desirable for a protocol to require that a conforming type
use a property wrapper in the declaration of a required property. This allows
consumers of the protocol to access the wrapper’s projected value and
properties, not just the wrapped value.</p>
<p>We propose allowing a subset of property wrapper syntax to appear in protocol
declarations.</p>
</blockquote>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> shared <a href="https://forums.swift.org/t/update-on-se-0110-and-se-0155/33948">an update</a>
on SE-0110 and SE-0155.</p>
<blockquote>
<p>In the Swift 3 era, several source-breaking proposals had been accepted with
the goal of cleaning up and regularizing parts of the language. However, many
of them have been stuck in the “Accepted” but not “Implemented” stage for
quite a while now, because we never quite got , and the barrier for breaking
source compatibility is much higher now than it was in the heady early days of
Swift evolution. As such, the Core Team has started going through some of these
proposals to record their current implementation status and subset out
remaining unimplemented source-breaking changes. To start off, I recently
reviewed the implementation status of two proposals:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a>, Distinguish between single-tuple and multiple-argument function types</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155</a>, Normalize Enum Case Representation</li>
</ul>
<p><strong>SE-0110</strong></p>
<p>This proposal changed the behavior of functions with multiple arguments from
being considered to have one formal argument of tuple type to instead be
treated as formally having multiple arguments. This change has been fully
implemented as of Swift 5.2; however, the <a href="https://github.com/apple/swift-evolution/blob/9e44932452e1daead98f2bc2e58711eb489e9751/proposals/0110-distingish-single-tuple-arg.md">original proposal as reviewed</a>
did not include the special-case conversion from <code class="language-plaintext highlighter-rouge">(T, U, ...) -> V</code> to
<code class="language-plaintext highlighter-rouge">((T, U, ...)) -> V</code> for function arguments. In response to community feedback,
this conversion was added as part of the Core Team’s acceptance of the proposal.
If and when that happens, it will be done as a fresh pitch and proposal.</p>
<p><strong>SE-0155</strong></p>
<p>Although unfortunate, the Core Team does not consider it worth breaking
source compatibility to change this behavior. Therefore, the pattern matching
part of the proposal has been downscoped to allow for disambiguation when
multiple cases share a base name, without changing the behavior for existing
enums supported today.</p>
</blockquote>
<p><a href="https://twitter.com/kaishin">Reda Lemeden</a> asked <a href="https://forums.swift.org/t/swift-package-naming-conventions/33931">a question</a>
about Swift Package naming conventions.</p>
<blockquote>
<ul>
<li>Some packages use dash-case (aka kebab-case). Notable examples:
<code class="language-plaintext highlighter-rouge">swift-driver</code>, <code class="language-plaintext highlighter-rouge">swift-numerics</code>, <code class="language-plaintext highlighter-rouge">swift-log</code>, <code class="language-plaintext highlighter-rouge">swift-crypto</code>, and <code class="language-plaintext highlighter-rouge">swift-nio</code>.
Other that fall into this group are SSWG packages and the new standard library
preview packages.</li>
<li>Some packages use CamelCase. Notable examples: <code class="language-plaintext highlighter-rouge">SwiftPM</code> itself,
<code class="language-plaintext highlighter-rouge">SourceKitLSP</code>, and <code class="language-plaintext highlighter-rouge">SwiftSyntax</code>. Almost all iOS/macOS packages follow this
convention.</li>
</ul>
<p>I understand if this detail is considered trivial or irrelevant, especially
since package names play a much lesser role compared to other package managers
such as npm. It is also worth noting that this situation is not unique to SPM
and can be found in other ecosystems, such as Rust, where <code class="language-plaintext highlighter-rouge">snake_cased</code> and
<code class="language-plaintext highlighter-rouge">dash-cased</code> crate names are both widely used (although the latter is gaining
more momentum).</p>
<p>At the same time, I think that with the eventual introduction of a package
registry (GitHub’s or otherwise), these naming inconsistencies are going to
surface to the end user much more than they do today.</p>
<p>Is the absence of SPM package naming guidelines by design? If so, can someone
shed some light on this?
If it is not, would it make sense to pursue converging towards one
convention? Could it happen organically or should it be enforced on the
manifest level?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/danielpunkass/status/1232650866949316608"><del><code class="language-plaintext highlighter-rouge">// FIXME</code></del>, oops I mean <code class="language-plaintext highlighter-rouge">// FORGIVE ME</code></a></p>
Issue #153
https://swiftweeklybrief.com/issue-153
2020-02-13T00:00:00-08:00
2020-02-13T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The last two weeks were rather busy at Apple. A new <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_11_4_beta_release_notes">Xcode 11.4 beta</a>, <a href="https://github.com/apple/swift-crypto">Swift Crypto</a> library releases and making <a href="https://developer.apple.com/news/?id=02122020a">Swift Playgrounds</a> available for Mac.</p>
<p>On top of that, the Swift repository now has more than <a href="https://twitter.com/slava_pestov/status/1227438709416628224">100,000 commits</a>!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-12129">SR-12129</a> <code class="language-plaintext highlighter-rouge">swift-driver</code> fails to diagnose a lack of input files</li>
<li><a href="https://bugs.swift.org/browse/TF-1134">TF-1134</a> [Autodiff] [Stlib] Define derivatives for <code class="language-plaintext highlighter-rouge">Float</code> and <code class="language-plaintext highlighter-rouge">Double</code> maximum and minimum methods</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/316012">episode 84 of Swift Unwrapped</a>, <a href="https://twitter.com/jesse_squires">Jesse</a> and <a href="https://twitter.com/simjp">JP</a> discuss Swift in 2020.</p>
<p>In <a href="https://www.swiftcommunitypodcast.org/episodes/7">episode 7 of the Swift Community Podcast</a>, <a href="https://twitter.com/0xTim">Tim Condon</a> talks with <a href="https://twitter.com/k__mahar">Kaitlin Mahar</a>, <a href="https://twitter.com/siemensikkema">Siemen Sikkema</a>, <a href="https://twitter.com/tanner0101">Tanner Nelson</a> and <a href="https://twitter.com/alfa">Ian Partridge</a> about the current state of Swift on the server, and what the future might have in store.</p>
<h3 id="news-and-community">News and community</h3>
<p>Xcode 11.4 beta is out with Swift 5.2, which has a ton of compiler performance and quality of life improvements, including the new diagnostic engine, <a href="https://twitter.com/jckarter/status/1225148705814106112">tweeted</a> <a href="https://twitter.com/jckarter">Joe Groff</a>.</p>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> released <a href="https://github.com/apple/swift-crypto">Swift Crypto</a> at <a href="https://www.dotswift.io/">dotSwift</a> conference <a href="https://twitter.com/NicoonGuitar/status/1224376366092767233">stage</a>. He wrote an <a href="https://swift.org/blog/crypto/">article</a> on the Swift.org website. As well some folks started a <a href="https://forums.swift.org/t/native-implementations-and-boringssl-backed-apple-platform-deployments/33404">discussion</a>.</p>
<blockquote>
<p>Swift Crypto is a new Swift package that brings the fantastic APIs of <a href="https://developer.apple.com/documentation/cryptokit">Apple CryptoKit</a> to the wider Swift community. This will allow Swift developers, regardless of the platform on which they deploy their applications, to access these APIs for a common set of cryptographic operations.</p>
</blockquote>
<p>Apple released <a href="https://developer.apple.com/news/?id=02122020a">Swift Playgrounds for Mac</a> - making it fun to learn and experiment with code. Previously it was available only for iPad.</p>
<p>The release of Swift 5.1.4 for Linux was <a href="https://forums.swift.org/t/announcing-swift-5-1-4-for-linux/33443">announced</a>. New downloads are available on <a href="https://swift.org/download/#swift-514">swift.org</a>. Official Docker images are also available.
Later <a href="https://twitter.com/johannesweiss">Johannes Weiss</a> <a href="https://forums.swift.org/t/development-open-for-swift-5-1-5-for-linux/33744">informed</a> that development is now open for Swift 5.1.5 for Linux.</p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> wrote two great articles. One about <a href="https://oleb.net/2020/swift-test-discovery/">automatic test discovery in Swift on Linux</a> and another on <a href="https://oleb.net/2020/swift-docker-linux/">how to test Swift packages on Linux using Docker</a>.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> wrote an <a href="https://www.swiftbysundell.com/articles/slicing-swift-collections/">article</a> explaining slicing Swift Collections.</p>
<p><a href="https://twitter.com/twannl">Antoine van der Lee</a> explained in his <a href="https://www.avanderlee.com/swift/creating-swift-package-manager-framework/">blog post</a> how to create the Swift Package framework in Xcode.</p>
<p><a href="https://twitter.com/pointfreeco">The Point-Free</a> folks <a href="https://twitter.com/pointfreeco/status/1224742851537514497">announced</a> a library called <a href="https://github.com/pointfreeco/swift-case-paths">CasePaths</a> that brings the power and ergonomics of key paths to enums.</p>
<p><a href="https://twitter.com/aalonso128/status/1224694162055999493">Alejandro tweeted</a> that Swift nightly builds are now available on <a href="https://swift.godbolt.org/">swift.godbolt.org</a>. Godbolt is a compiler explorer tool.</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> <a href="https://twitter.com/twostraws/status/1225207234185121793">tweeted</a> that <a href="https://www.whatsnewinswift.com/?from=5.1&to=5.2">whatsnewinswift.com</a> now covers Swift 5.2 and other changes between the versions.
Along with that, he released a tool called <a href="https://github.com/twostraws/Sitrep">Sitrep</a> that is a source code analyzer for Swift projects, giving you a high-level overview of your code.</p>
<p><a href="https://twitter.com/mattt">Mattt</a> wrote two awesome articles about <a href="https://nshipster.com/language-server-protocol/">Language Server Protocol</a> and <a href="https://nshipster.com/vscode/">Swift Development with Visual Studio Code</a>.</p>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> <a href="https://twitter.com/johannesweiss/status/1227646148237824001">tweeted</a> that <a href="https://github.com/swift-server/async-http-client/releases/tag/1.1.0">AsyncHTTPClient version 1.1.0</a> has been released.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/29579">a pull request</a> that fixes <code class="language-plaintext highlighter-rouge">computeSelfParam()</code> to respect <code class="language-plaintext highlighter-rouge">__consuming</code> on class methods.</p>
<p>He also <a href="https://twitter.com/slava_pestov/status/1223394327340019717">tweeted</a>:</p>
<blockquote>
<p>Dodged an ABI bullet here. Underscored keyword was broken… but thankfully the broken case wasn’t exercised in the standard library</p>
</blockquote>
<p><a href="https://github.com/tbkka">Tim</a> opened [a pull request] that overhauls <code class="language-plaintext highlighter-rouge">swift_dynamicCast</code>. <a href="https://twitter.com/Catfish_Man">David Smith</a> <a href="https://twitter.com/Catfish_Man/status/1225136680039899136">tweeted</a>:</p>
<blockquote>
<p>Swift’s runtime casting infrastructure has been… “scary and organic” I guess? For quite a while. This rewrites it to be properly structured, and cleans up a ton of edge case behavior in the process.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/29786">a pull request</a> which adds function builders support for declaring local variables within a function builder closure.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/26975">a pull request</a> where he and <a href="https://twitter.com/CodaFi_">CodaFi</a> were able to fix the remaining cases where name lookup in imported types would force loading <em>all</em> the members of a type or extension in order to find a <em>single</em> member.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/29728">a pull request</a> that makes it easy to extend Swift function builders to support local <code class="language-plaintext highlighter-rouge">let</code>’s.</p>
<blockquote>
<p>Sink the constraint generation and solution application of initialization patterns, including all
of the logic for property wrappers, from the high-level entry point
<code class="language-plaintext highlighter-rouge">typeCheckBinding</code> down into the lower-level handling for
solution application targets.</p>
</blockquote>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md">SE-0270</a>: <em>Add Collection Operations on Noncontiguous Elements</em> was <a href="https://forums.swift.org/t/accepted-se-0270-add-collection-operations-on-noncontiguous-elements/33270">accepted</a>. See the discussions <a href="https://forums.swift.org/t/evolution-process-discussion/33272">here</a>.</p>
<blockquote>
<p>We can use a <code class="language-plaintext highlighter-rouge">Range<Index></code> to refer to a group of consecutive positions in a collection, but the standard library doesn’t currently provide a way to refer to discontiguous positions in an arbitrary collection. I propose the addition of a <code class="language-plaintext highlighter-rouge">RangeSet</code> type that can represent any number of positions, along with collection algorithms that operate on those positions.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0277-float16.md">SE-0277</a>: <em>Float16</em> is <a href="https://forums.swift.org/t/se-0277-float16/33546">under review</a>.</p>
<blockquote>
<p>Introduce the <code class="language-plaintext highlighter-rouge">Float16</code> type conforming to the <code class="language-plaintext highlighter-rouge">BinaryFloatingPoint</code> and <code class="language-plaintext highlighter-rouge">SIMDScalar</code> protocols, binding the IEEE 754 <em>binary16</em> format (<em>aka float16, half-precision, or half</em>), and bridged by the compiler to the C <code class="language-plaintext highlighter-rouge">_Float16</code> type.</p>
<p>Old pitch thread: <a href="https://forums.swift.org/t/add-float16/19370">Add <code class="language-plaintext highlighter-rouge">Float16</code></a>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274</a>: <em>Concise magic file names</em> is <a href="https://forums.swift.org/t/re-review-se-0274-concise-magic-file-names/33171">under a second review</a>.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://forums.swift.org/u/Tino">Tino Heth</a> started an interesting <a href="https://forums.swift.org/t/jargon-acronyms-vs-accessible-language/33358">discussion</a> about Jargon & acronyms vs. accessible language.</p>
<blockquote>
<p>When it comes to naming, I think it’s best to keep the majority in mind, and not trying to please a very small group by preferring their jargon. An expert may prefer his wording, but would certainly also understand common language easily.</p>
</blockquote>
<p><a href="https://twitter.com/jeffreymacko">Jeffrey Macko</a> informed in a <a href="https://forums.swift.org/t/support-for-semantic-highlighting-is-moving-on-microsoft-part/33489">forum thread</a> that support for semantic highlighting is moving on Microsoft’s end.</p>
<p><a href="https://forums.swift.org/u/mattrips">Matt Rips</a> started a <a href="https://forums.swift.org/t/special-case-protocol-conformance-long-term-tradeoffs-for-near-term-conformance/33544">discussion</a> about special case protocol conformance by explaining long-term tradeoffs for near-term conformance.</p>
<blockquote>
<p>In short, the original pitch was to create a special-case, compiler-level mechanism to generate Equatable conformance for all tuples whose elements themselves conform to Equatable. The conformance would be automatic, without any means to opt-in or opt-out.</p>
<p>There exists a fairly wide-spread and long-standing desire to enable protocol conformance for tuples and perhaps other structural types, and especially so with respect to ubiquitous protocols, like Equatable, Comparable, Hashable and Codable. Presently, we are not in a position to facilitate custom protocol conformance as a general feature for tuples or other structural types. It is anticipated that that sort of feature will be created, eventually.</p>
</blockquote>
<p><a href="https://twitter.com/tanner0101">Taneer Nelson</a> <a href="https://forums.swift.org/t/january-23rd-2020/33715">shared</a> Swift on Server WorkGroup January 23rd, 2020 meeting notes. And <a href="https://twitter.com/TomerDoron">Tom Doron</a> February 6th, 2020 meeting <a href="https://forums.swift.org/t/february-6th-2020/33748">recap</a>.</p>
<h3 id="finally">Finally</h3>
<p>Should a Swift library <a href="https://twitter.com/jesse_squires/status/1224456344792530949">include</a> a lot of Swift code? 🤔</p>
<p>A small <a href="https://github.com/apple/swift/commit/77da6bd3a7c3c2ec02bb0f13e7341cf867cab0d3">change</a>, but big <a href="https://twitter.com/dgregor79/status/1224537246998487040">impact</a>. 🙃</p>
Issue #152
https://swiftweeklybrief.com/issue-152
2020-01-30T00:00:00-08:00
2020-01-30T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I think I don’t have to mention much more than that a lot of fantastic
information on the distant future of Swift has been shared in the last two
weeks: the road to Swift 6, progress on the Function Builders proposal, and
more. 🎉🎉🎉</p>
<p>This is a big issue with lots of interesting topics being discussed!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-12085">SR-12085</a> [Compiler] Clean up
<code class="language-plaintext highlighter-rouge">TypeCheckType</code> so it never returns <code class="language-plaintext highlighter-rouge">Type()</code></li>
<li><a href="https://bugs.swift.org/browse/TF-1107">TF-1107</a> [Autodiff] Add JVPs to
standard library</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared <a href="https://forums.swift.org/t/on-the-road-to-swift-6/32862">an update</a>
on the road to Swift 6, with many interesting insights. If there’s one thing
you’re going to pick up from this issue, it should be this — it’s a great read.
Some things mentioned:</p>
<ul>
<li>Faster builds</li>
<li>More informative and accurate diagnostics</li>
<li>Reliable and fluid debugging experience</li>
<li>Provide excellent solutions for major language features such as memory
ownership and concurrency</li>
<li>Significantly improve the performance of incremental builds</li>
<li>Improve code completion performance, reliability, and experience</li>
</ul>
<p>Like I said; you’re going to want to give this a read.</p>
<p><a href="https://twitter.com/simjp">JP Simard</a> created a poll <a href="https://twitter.com/simjp/status/1218613429881040897">about the oldest Swift version people are actively using</a>;
a quite surprisingly high amount (to me) is pretty up-to-date with the latest
Swift versions!</p>
<p><a href="https://twitter.com/mattt">Mattt</a> announced <a href="https://twitter.com/mattt/status/1221863163915694085"><code class="language-plaintext highlighter-rouge">swift-doc</code></a>,
an (experimental) command-line utility for generating documentation for Swift
projects. One of the distinguishing features of <code class="language-plaintext highlighter-rouge">swift-doc</code> is that it operates
on Swift code at a syntactic level, without first compiling it.</p>
<p><a href="https://twitter.com/glbrntt">George Barnett</a> released <a href="https://github.com/apple/swift-nio/releases/tag/2.13.0">SwiftNIO 2.13.0</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/28837">a pull request</a>
that is a big step toward improving type inference for closures over time.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged a bunch of pull requests:</p>
<ul>
<li><a href="https://github.com/apple/swift/pull/29331">#29331</a> is a large refactor he’s
been doing on-and-off for a while. By itself it has no user-visible effect,
but it’s the building block to make function builders more powerful and
expressive.</li>
<li><a href="https://github.com/apple/swift/pull/29409">#29409</a> makes supporting multiple
conditions for <code class="language-plaintext highlighter-rouge">if</code> statements within function builder closures a
straightforward generalization of the refactored code. This would have required
some gross hackery with the old implementation of function builders.</li>
<li><a href="https://github.com/apple/swift/pull/29419">#29419</a> adds support for
<code class="language-plaintext highlighter-rouge">if #available</code> within function builders.</li>
</ul>
<p>All this is part of a much larger effort to improve function builders, and
<a href="https://forums.swift.org/t/function-builders-implementation-progress/32981">this post</a>
explains this effort further.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md">SE-0276</a>: <em>Multi-Pattern Catch Clauses</em> was <a href="https://forums.swift.org/t/accepted-se-0276-multi-pattern-catch-clauses/33220">accepted</a>.</p>
<blockquote>
<p>Feedback was almost universally positive, and the proposal has been accepted!
Thank you to everyone who participated in the review process.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md">SE-0275</a>: <em>Allow more characters (like whitespaces and punctuations) for escaped identifiers</em> was <a href="https://forums.swift.org/t/se-0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers/32538/46">rejected</a>.</p>
<blockquote>
<p>The core team has decided to reject this proposal. Community reaction was
mixed, and many of the people both supporting and rejecting the idea had
concerns about the breadth of the set of characters this allows. Allowing more
characters in identifiers would also add complexity to tooling, including
syntax highlighting, IDEs, and runtime reflection libraries, which would need
to be able to recognize quoted identifiers, know when identifiers would need
to be quoted for presentation purposes, and potentially need to implement more
elaborate parsing and escaping rules to handle these generalized identifiers.
In the core team’s judgment, this added demand on tooling is not justified by
the amount of utility provided by the proposal.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274</a>: <em>Concise magic file names</em> is <a href="https://forums.swift.org/t/re-review-se-0274-concise-magic-file-names/33171">under a second review</a>.</p>
<blockquote>
<p>The original review thread concluded with the core team accepting the
proposal in principal: <code class="language-plaintext highlighter-rouge">#file</code> will be updated to include only the file and
module names, with <code class="language-plaintext highlighter-rouge">#filePath</code> introduced for use cases that require the full
path to the file.</p>
<p>However, during the review it was proposed that the exact format of <code class="language-plaintext highlighter-rouge">#file</code>
be specified, in order to allow for future tooling to rely on that format to
determine the file and module name from the string.</p>
<p>The proposal has been amended to explicitly include this format, and this
re-review is focused on that aspect of the proposal.</p>
</blockquote>
<blockquote>
<p><strong>Changes since the first review</strong></p>
<ul>
<li>We now specify that the <code class="language-plaintext highlighter-rouge">#file</code> string will have the format
<code class="language-plaintext highlighter-rouge"><module-name>/<file-name></code> (with a second form for future expansion) and
discuss how to parse it. The previous revision left this format as a compiler
implementation detail that tools should always treat as opaque.</li>
<li>We now discuss the behavior of <code class="language-plaintext highlighter-rouge">#sourceLocation</code>’s <code class="language-plaintext highlighter-rouge">file</code> parameter and
provide for a warning when it creates conflicts. The previous revision did not
discuss these topics.</li>
<li>We now mention the need for tooling to map <code class="language-plaintext highlighter-rouge">#file</code> strings back to paths.</li>
<li>We now provide for a warning when a wrapper around a <code class="language-plaintext highlighter-rouge">#filePath</code>-defaulting
function passes it <code class="language-plaintext highlighter-rouge">#file</code> instead, or vice versa. The previous revision did
not discuss this.</li>
<li>We have added several suggestions from the first review to the
“alternatives considered” section to explain why we aren’t proposing them.</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md">SE-0270</a>: <em>Add Collection Operations on Noncontiguous Elements</em> is <a href="https://forums.swift.org/t/se-0270-review-3-add-collection-operations-on-noncontiguous-elements/32839">under a third review</a>.</p>
<blockquote>
<p>We can use a <code class="language-plaintext highlighter-rouge">Range<Index></code> to refer to a group of consecutive positions in a
collection, but the standard library doesn’t currently provide a way to refer
to discontiguous positions in an arbitrary collection. I propose the addition
of a <code class="language-plaintext highlighter-rouge">RangeSet</code> type that can represent any number of positions, along with
collection algorithms that operate on those positions.</p>
<p>There are varied uses for tracking multiple elements in a collection, such as
maintaining the selection in a list of items, or refining a filter or search
result set after getting more input from a user.</p>
<p>The Foundation data type most suited for this purpose, <code class="language-plaintext highlighter-rouge">IndexSet</code>, uses
integers only, which limits its usefulness to arrays and other random-access
collection types. The standard library is missing a collection that can
efficiently store ranges of indices, and is missing the operations that you
might want to perform with such a collection. These operations themselves can
be challenging to implement correctly, and have performance traps as well — see
last year’s <a href="https://developer.apple.com/videos/wwdc/2018/?id=223">Embracing Algorithms</a>
WWDC talk for a demonstration.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/jumhyn">Frederick Kellison-Linn</a> pitched <a href="https://forums.swift.org/t/allow-chained-member-references-in-implicit-member-expressions/32829">a proposal</a>
to allow chained member references in implicit member expressions.</p>
<blockquote>
<p>I propose that we extend implicit member syntax (a.k.a. “leading dot syntax”)
to allow for chained member references rather than just a single level.</p>
<p>When the type of an expression is implied by the context, Swift allows
developers to use what is formally referred to as an “implicit member
expression”, sometimes referred to as “leading dot syntax”:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">class</span> <span class="kt">C</span> <span class="p">{</span>
<span class="kd">static</span> <span class="k">let</span> <span class="nv">zero</span> <span class="o">=</span> <span class="kt">C</span><span class="p">(</span><span class="mi">0</span><span class="p">)</span>
<span class="k">var</span> <span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span>
<span class="nf">init</span><span class="p">(</span><span class="n">_</span> <span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="p">{</span>
<span class="k">self</span><span class="o">.</span><span class="n">x</span> <span class="o">=</span> <span class="n">x</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">f</span><span class="p">(</span><span class="n">_</span> <span class="nv">c</span><span class="p">:</span> <span class="kt">C</span><span class="p">)</span> <span class="p">{</span>
<span class="nf">print</span><span class="p">(</span><span class="n">c</span><span class="o">.</span><span class="n">x</span><span class="p">)</span>
<span class="p">}</span>
<span class="nf">f</span><span class="p">(</span><span class="o">.</span><span class="n">zero</span><span class="p">)</span> <span class="c1">// prints '0'</span>
</code></pre></div></div>
<blockquote>
<p>However, attempting to use this with a chain of member references fails:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">extension</span> <span class="kt">C</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">incremented</span><span class="p">:</span> <span class="kt">C</span> <span class="p">{</span>
<span class="k">return</span> <span class="kt">C</span><span class="p">(</span><span class="k">self</span><span class="o">.</span><span class="n">x</span> <span class="o">+</span> <span class="mi">1</span><span class="p">)</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="nf">f</span><span class="p">(</span><span class="o">.</span><span class="n">zero</span><span class="o">.</span><span class="n">incremented</span><span class="p">)</span> <span class="c1">// Error: Type of expression is ambiguous without more context</span>
</code></pre></div></div>
<blockquote>
<p>On master, the new diagnostic system has improved the produced error:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nf">f</span><span class="p">(</span><span class="o">.</span><span class="n">zero</span><span class="o">.</span><span class="n">incremented</span><span class="p">)</span> <span class="c1">// Error: Cannot infer contextual base in reference to member 'zero'</span>
</code></pre></div></div>
<blockquote>
<p>but the same problem persists.</p>
</blockquote>
<p><a href="https://twitter.com/koher">Yuta Koshizawa</a> pitched <a href="https://forums.swift.org/t/three-steps-to-variadic-generics/33154">a proposal</a>:
Three Steps to Variadic Generics.</p>
<blockquote>
<p>Variadic generics was referred to in “<a href="https://forums.swift.org/t/on-the-road-to-swift-6/32862">On the road to Swift 6</a>”.
I think it may be a good idea to break down it into the following three steps
compared to tackle variadic generics directly.</p>
<ol>
<li>Operations for tuples</li>
<li>Variadic tuples</li>
<li>Variadic generics</li>
</ol>
</blockquote>
<p><a href="https://twitter.com/fabianfett">Fabian Fett</a> announced <a href="https://forums.swift.org/t/official-platform-support-for-other-linux-distributions-and-a-case-for-amazon-linux-2/33167">official platform support for other Linux
Distributions</a>
(besides Ubuntu).</p>
<blockquote>
<p>The SSWG announced that they are looking for other Linux Distributions
besides Ubuntu to support official prebuilt toolchains for in <a href="https://swift.org/blog/sswg-update/">their yearly
update</a>.</p>
<p>After some research the only documented way I found to engage in widening the
platform support is by <a href="https://github.com/apple/swift-community-hosted-continuous-integration">administering a Jenkins slave</a>
that builds Swift on a given platform as part of the Community-CI effort.<br />
Sadly administering such a slave comes with at least a monetary burden (besides
time and security).</p>
<p>For this reason I want to ask: What will the process be to become an
officially supported platform? If there is no process planned so far maybe we
can start a discussion here.</p>
</blockquote>
<p><a href="https://twitter.com/rmalik">Rahul Malik</a> pitched <a href="https://forums.swift.org/t/swiftpm-support-for-swift-scripts/33126">a proposal</a>
to add SwiftPM support for Swift scripts.</p>
<blockquote>
<p>Swift is a general-purpose language that aims expand it’s availability and
impact on various domains and platforms. We believe great scripting support and
experience is an important part of improving the impact of Swift as a language.
Swift already includes basic support for scripting via the Swift command-line
tool. This is a proposal for greatly improving the script support by providing
a deeper integration with the Swift Package Manager.</p>
</blockquote>
<p><a href="https://twitter.com/stephentyrone">Steve Canon</a> pitched <a href="https://forums.swift.org/t/add-float16/33019">a proposal</a>
to add <code class="language-plaintext highlighter-rouge">Float16</code>.</p>
<blockquote>
<p>Introduce the <code class="language-plaintext highlighter-rouge">Float16</code> type conforming to the <code class="language-plaintext highlighter-rouge">BinaryFloatingPoint</code> and
<code class="language-plaintext highlighter-rouge">SIMDScalar</code> protocols, binding the IEEE 754 <em>binary16</em> format (aka <em>float16</em>,
<em>half-precision</em>, or <em>half</em>), and bridged by the compiler to the C <code class="language-plaintext highlighter-rouge">_Float16</code>
type.</p>
</blockquote>
<p><a href="https://twitter.com/dhartbit">David Hart</a> pitched <a href="https://forums.swift.org/t/package-manager-localized-resources/32963">a proposal</a>
to add Localized Resources to the Swift Package Manager.</p>
<blockquote>
<p>This proposal builds on top of the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md">Package Manager Resources</a>
proposal to allow defining localized versions of resources in the SwiftPM
manifest and have them automatically accessible at runtime using the same APIs.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/nikhilpandey4">Nikhil Pandey</a> pitched <a href="https://forums.swift.org/t/more-push-towards-distribution-and-promotion-of-the-server-side-swift-framework/32931">a proposal</a>
for a push towards distribution and promotion of the Server Side Swift
Framework.</p>
<blockquote>
<p>Lots of efforts are being made for creation of new frameworks and creating
new libraries since last few years for making Swift on Server Side a real
success, which is commendable. Let’s also accept the fact that Server Side
Swift is also something which requires cooperation and support of wider
developer community outside Apple ecosystem too, especially on Linux side and,
so cooperation with external developers is also a requirement.</p>
<p>A time has come for putting efforts also towards promotion and distribution
of Server Side Swift too.</p>
</blockquote>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> shared <a href="https://forums.swift.org/t/swift-driver-and-help-documentation-lookup/32881">an update</a>
on <code class="language-plaintext highlighter-rouge">swift-driver</code> and <code class="language-plaintext highlighter-rouge">–help</code> / documentation lookup.</p>
<blockquote>
<p>In short, I think we should consider adding writing a <code class="language-plaintext highlighter-rouge">swift-help</code> in Swift
as part of the <code class="language-plaintext highlighter-rouge">swift-driver</code> project, and use it to entirely replace help
handling in the compiler sooner rather than later. The benefits are:</p>
<ul>
<li>We’d gain experience integrating a Swift package product in compiler
toolchains with minimal impact on day-to-day development. Anything we learned
could then be applied to <code class="language-plaintext highlighter-rouge">swift-driver</code> later on. No bootstrapping would be
needed since the help text isn’t needed to build the compiler.</li>
<li><code class="language-plaintext highlighter-rouge">swift help</code> becomes a supported subcommand</li>
<li>It solves my immediate problem (admittedly not a strong justification)</li>
<li>We could delete a little bit of C++ from the frontend :)</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/nevin">Nevin</a> pitched <a href="https://forums.swift.org/t/set-only-subscripts/32858">a proposal</a>
to add support for set-only subscripts.</p>
<blockquote>
<p>Currently, subscripts can be read-only or they can be read-write, but there
is no way to declare a subscript as write-only. Write-only subscripts have a
number of important uses, and this proposal aims to bring them into the
language.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1217861938136276993">#nofilter</a>.</p>
Issue #151
https://swiftweeklybrief.com/issue-151
2020-01-16T00:00:00-08:00
2020-01-16T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>The holidays are over and during that time a lot has happened.</p>
<ul>
<li>Swift 5.2 nightly builds are now <a href="https://swift.org/download/#snapshots">available</a></li>
<li>folks have discussed and compared <a href="https://www.quora.com/What-are-similarities-and-differences-between-C-and-Swift">Swift and C++</a></li>
<li>a book about Swift by Swift community members and creator of Swift <a href="https://twitter.com/clattner_llvm">Chris Lattner</a> was <a href="https://www.swiftforgood.com/">released</a> — and all proceeds go to charity!</li>
</ul>
<p>But now let’s enjoy the news!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11989">SR-11989</a> Better diagnostic for invalid <code class="language-plaintext highlighter-rouge">enclosing self</code> property wrapper subscript</li>
<li><a href="https://bugs.swift.org/browse/SR-12005">SR-12005</a> [Compiler] Add a smaller test case for AudioKit crash in 5.1</li>
<li><a href="https://bugs.swift.org/browse/SR-12022">SR-12022</a> [Compiler] Refactor <code class="language-plaintext highlighter-rouge">LiteralExpr</code> subclasses to combine common initializer code paths</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/314852">episode 83 of Swift Unwrapped</a>, Jesse and JP discuss Modify Accessors.</p>
<p>In <a href="https://swiftbysundell.com/podcast/61/">Swift by Sundell #63</a>, <a href="https://twitter.com/johnsundell">John Sundell</a>, <a href="https://twitter.com/DonnyWals">Donny Wals</a> and <a href="https://twitter.com/twannl">Antoine van der Lee</a> talk about how Swift has changed in 2019, and where things might be headed in 2020.</p>
<p>In <a href="https://www.empowerapps.show/34">Empower Apps #34</a>, <a href="https://twitter.com/leogdion">Leo Dion</a> and <a href="https://twitter.com/0xtim">Tim Condon</a> discuss Server-Side Swift and the Vapor Web Framework.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_11_3_1_release_notes">Xcode 11.3.1</a> was released. It included some improvements, like:</p>
<ul>
<li>inspection of global variables in Swift</li>
<li>reduced the size of dependency files (<code class="language-plaintext highlighter-rouge">.d</code>) produced by the Swift compiler.</li>
</ul>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> shared a great article about <a href="https://www.swiftbysundell.com/articles/the-decade-of-swift">the decade of Swift</a> and <a href="https://twitter.com/johnsundell/status/1211743896591568899">announced</a> a static site generator built specifically for Swift developers called <a href="https://github.com/johnsundell/publish">Publish</a>.</p>
<p>Sad news that Vapor Cloud will be shutting down on February 29th, but there are many good <a href="https://twitter.com/leogdion/status/1214179319318220802">alternatives</a>.</p>
<p><a href="https://www.twitter.com/Joe_Duffy">Joe Duffy</a> wrote <a href="https://josephduffy.co.uk/partial-in-swift">a blog post</a> about the tool <a href="https://github.com/JosephDuffy/Partial">Partial</a> - a type-safe wrapper that mirrors the properties of the wrapped type but makes each property optional.</p>
<p><a href="https://www.twitter.com/ar_institute">Always Right Institute</a> wrote <a href="https://www.alwaysrightinstitute.com/microexpress-nio2/">a tutorial</a> on SwiftNIO 2.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> shared <a href="https://twitter.com/slava_pestov/status/1215126454767357959?s=21">some insights</a> on how the lines of code in <code class="language-plaintext highlighter-rouge">CSDiag.cpp</code> have decreased between Swift versions.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> made <a href="https://github.com/apple/swift/pull/28515">a pull request</a> that he’s calling <a href="https://twitter.com/dgregor79/status/1215897492568494080?s=21">a little side project</a> and it is coming in at 11x faster than the existing implementation for scanning the dependencies of a Swift file.</p>
<p><a href="https://twitter.com/rintaro">Rintaro Ishizaki</a> merged <a href="https://github.com/apple/swift/pull/29086">a pull request</a> that improves code completion when using <code class="language-plaintext highlighter-rouge">GenericSignature</code> methods to get <code class="language-plaintext highlighter-rouge">associatedtype</code> requirements.</p>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> created <a href="https://github.com/apple/swift/pull/29094">a pull request</a> that adds <code class="language-plaintext highlighter-rouge">withContiguousStorageIfAvailable</code> to <code class="language-plaintext highlighter-rouge">SubString.UTF8View</code> in the Standard Library. This pull request also has a <a href="https://github.com/apple/swift/pull/29146">second part</a>.</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> created <a href="https://github.com/apple/swift/pull/29068">a pull request</a> that has some code size improvements for <code class="language-plaintext highlighter-rouge">Array</code> in the Standard Library.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> made <a href="https://github.com/apple/swift/pull/29133">a work-in-progress pull request</a> that has a refactoring/reimplementation of function builders to <a href="https://twitter.com/dgregor79/status/1216137755102568448?s=21">make handling declarations possible</a>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0273-swiftpm-conditional-target-dependencies.md">SE-0273</a>: <em>Package Manager Conditional Target Dependencies</em> was <a href="https://forums.swift.org/t/accepted-se-0273-package-manager-conditional-target-dependencies/31932">accepted</a>.</p>
<blockquote>
<p>Feedback was positive, and the proposal is accepted. Thanks to everyone who
participated!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0273-swiftpm-conditional-target-dependencies.md">SE-0272</a>: <em>Package Manager Binary Dependencies</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0272-package-manager-binary-dependencies/31926">accepted with modifications</a>.</p>
<blockquote>
<p>Feedback was sparse, but we had generally positive feedback during the first
round of review. Therefore the proposal has been accepted with modifications,
local binary targets will not be able to reference zipped artifacts.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md">SE-0274</a>: <em>Concise Magic File Names</em> is <a href="https://forums.swift.org/t/se-0274-concise-magic-file-names/32373">under review</a>.</p>
<blockquote>
<p>Today, <code class="language-plaintext highlighter-rouge">#file</code> evaluates to a string literal containing the full path to the current source file. We propose to instead have it evaluate to a human-readable string containing the filename and module name, while preserving the existing behavior in a new <code class="language-plaintext highlighter-rouge">#filePath</code> expression.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/concise-magic-file-names/31297">Concise Magic File Names</a>, <a href="https://forums.swift.org/t/we-need-filename/19781">We need <code class="language-plaintext highlighter-rouge">#fileName</code></a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/0c709d72bcda5946b02067745c87217a7e3c48c8/proposals/0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers.md">SE-0275</a>: <em>Allow more characters (like whitespaces and punctuations) for escaped identifiers</em> is <a href="https://forums.swift.org/t/se-0275-allow-more-characters-like-whitespaces-and-punctuations-for-escaped-identifiers/32538">under review</a>.</p>
<blockquote>
<p>Swift has a beautiful concise yet expressive syntax. As part of that, escaped identifiers are adopted to allow usage of reserved keywords. This proposal wants to extend the character allowance for escaped identifiers with more Unicode scalars, like whitespace and punctuation. It will enable to have method names (or other identifiers) with a more readable and natural language like the following:</p>
<p><code class="language-plaintext highlighter-rouge">func test validation should succeed when input is less than ten ()</code></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0276-multi-pattern-catch-clauses.md">SE-0276</a>: <em>Multi-Pattern Catch Clauses</em> is <a href="https://forums.swift.org/t/se-0276-multi-pattern-catch-clauses/32620">under review</a>.</p>
<blockquote>
<p>Currently, each catch clause in a do-catch statement may only contain a single pattern and where clause. This is inconsistent with the behavior of cases in switch statements, which provide similar functionality. It also makes some error handling patterns awkward to express. This proposal extends the grammar of catch clauses to support a comma-separated list of patterns (with optional where clauses), resolving this inconsistency.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/multi-pattern-and-conditionally-compiled-catch-clauses/30246">Thread</a></p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/spprichard">Steven Prichard</a> explained his personal experience with <a href="https://forums.swift.org/t/open-api-tools-swift-personal-experience/31962">Open API Tools & Swift</a>.</p>
<blockquote>
<p>I recently began a personal project in which I wanted to use Kubernetes (K8s) & Swift. To get started I created a library that was going to house all the K8s types, and the HTTP Client for communicating with the K8s API. With the goal of importing this library into all the other projects I had planned. Lucky enough for me, K8s uses the OpenAPI Spec, so generating the client code should be easy. I was mistaken, for Swift that is not the case. Specifically for any Swift client that you wanted to run on Linux. At the time of writing this, there did not exist a Swift Client that the Open-API code generation tool could generate that could be ran on Linux. I had concluded, with the help of others, that if I wanted a Pure-Swift Kubernetes library that could be ran on Linux I would have to write the HTTP Client code myself.</p>
</blockquote>
<p><a href="https://twitter.com/_technogen_">Gor Gyolchanyan</a> pitched an idea about <a href="https://forums.swift.org/t/passing-custom-getter-and-setter-to-property-wrapper-initializer/32000">passing custom getter and setters to a property wrapper initializer</a>.</p>
<blockquote>
<p>A lot of use cases for property wrappers (like SwiftUI’s <code class="language-plaintext highlighter-rouge">@Binding</code> or a simple <code class="language-plaintext highlighter-rouge">@Lazy</code>) rely on custom accessor closures of the form <code class="language-plaintext highlighter-rouge">() -> WrappedValue</code> and <code class="language-plaintext highlighter-rouge">(WrappedValue) -> Void</code> for the getter and the setter respectively. To that end, I’d like to suggest an improvement to the property wrapper mechanism to help improve the readability of such use cases.</p>
</blockquote>
<p><a href="https://twitter.com/broadway_lamb">Sergej Jaskiewicz</a> shared a proposal to <a href="https://forums.swift.org/t/pitch-handling-future-cases-of-enums-in-libraries-without-binary-stability-concerns/32026">handle future cases of enums in libraries without binary stability concerns</a>.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a> introduced a mechanism to add new cases to enums defined in the standard library and overlays in a source-compatible way. <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0260-library-evolution.md">SE-0260</a> later lifted this restriction, allowing to use this mechanism in all libraries built in library evolution mode.</p>
<p>We propose to remove this restriction completely by:</p>
<ul>
<li>allowing all library authors to mark their public enums as @frozen;</li>
<li>warning the clients that exhaustively switch over a non-frozen enum declared in another module, * suggesting them to add an @unknown default case.</li>
</ul>
</blockquote>
<p><a href="https://forums.swift.org/u/steve_k_chiu">Steve K. Chiu</a> <a href="https://forums.swift.org/t/pitch-property-as-fallback-shortcut-to-self-property/32060">pitched</a> how to make <code class="language-plaintext highlighter-rouge">self.property</code> more readable at the point of use.</p>
<blockquote>
<p>The motivation is pretty much the same as <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md">SE-0009</a></p>
<p>That is, we need a shorter form of self.property that is more readable at the point of use.</p>
<p>The idea is:</p>
<p>Add fallback lookup for identifier starts with single <code class="language-plaintext highlighter-rouge">_</code> (ex. _name), if the identifier is not a local variable, member property or global variable, then treat it as self.(identifier without <code class="language-plaintext highlighter-rouge">_</code>) (ex. self.name)</p>
</blockquote>
<p><a href="https://forums.swift.org/u/MasterSwift">MasterSwift</a> shared a <a href="https://forums.swift.org/t/swift-benchmarks/32113">comparison</a> between Swift and Java.</p>
<blockquote>
<p>I once a while check Swift benchmarks against other languages to see how the language is speeding.</p>
<p>Why is Swift so awful in Regex and Binary Trees?</p>
</blockquote>
<p><a href="https://forums.swift.org/u/wildchild9">Wildchild9</a> described an <a href="https://forums.swift.org/t/adding-a-linkedlist-type-to-the-standard-library/32339">idea</a> to add a <code class="language-plaintext highlighter-rouge">LinkedList</code> type to the Standard Library.</p>
<blockquote>
<p>Swift is missing a great many data types (see <a href="https://forums.swift.org/t/adding-more-data-structures-to-the-standard-library/23651">Adding more data structures to the standard library</a>). I thought I may be able to get this going with suggesting the introduction of a <code class="language-plaintext highlighter-rouge">LinkedList</code> type to Swift.</p>
</blockquote>
<p>Alejandro Alonso pitched <a href="https://forums.swift.org/t/tuples-conform-to-equatable/32559">a proposal</a> and <a href="https://github.com/apple/swift/pull/28833">implementation</a> introducing <code class="language-plaintext highlighter-rouge">Equatable</code> conformance for all tuples whose elements are themselves <code class="language-plaintext highlighter-rouge">Equatable</code>.</p>
<blockquote>
<p>Tuples in Swift currently lack the ability to conform to protocols. This has led many users to stop using tuples altogether in favor of structures that they can them conform protocols to. The shift from tuples to structures have made tuples almost feel like a second class type in the language because of them not being able to do simple operations that should just work.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Two things from <a href="https://twitter.com/jckarter">Joe Groff</a>:</p>
<ul>
<li><a href="https://twitter.com/jckarter/status/1208134014961274880">Politics and Swift</a></li>
<li>Are Playgrounds <a href="https://twitter.com/jckarter/status/1211787829652512768">radical</a>?</li>
</ul>
<p><a href="https://twitter.com/slava_pestov/status/1214632943953551361">Are we remote yet</a>?</p>
Issue #150
https://swiftweeklybrief.com/issue-150
2019-12-19T00:00:00-08:00
2019-12-19T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>One. Five. Zero. One hundred and fifty. 150 issues! What an awesome milestone
for this project, and fitting as the last issue in 2019 (this was accidental,
I swear!)</p>
<p>My gratitude to none other than Jesse Squires first and foremost, for starting
this project and keeping it going up until issue 100. Thank you to Kristaps
Grinbergs for helping out behind the scenes over the last months, as well as
writing a few issues. Thanks to <a href="/authors">all other authors</a> and those people
helping behind the scenes for everything. You are the ones making this
newsletter possible!</p>
<p>Lastly, thank you all dearly for reading and sharing the newsletter! When I
took over this project from Jesse, I did so for two main reasons: I wanted to
keep up to date with what’s going on with Swift, and have the possibility to
share that with all others interested as well. And I feel that has worked out
quite splendidly! Looking forward to continuing the journey in the next year.</p>
<p>And with that said, before we jump into the news from over the last two weeks,
I want to wish you all a great end of 2019.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11900">SR-11900</a> [Compiler] <code class="language-plaintext highlighter-rouge">swift help</code>
doesn’t work</li>
<li><a href="https://bugs.swift.org/browse/SR-11905">SR-11905</a> [Compiler] Objective-C
interop allows creation of undefined behavior</li>
<li><a href="https://bugs.swift.org/browse/SR-11918">SR-11918</a> [Compiler] Reject the
combination of <code class="language-plaintext highlighter-rouge">-enable-testing</code> and <code class="language-plaintext highlighter-rouge">-enable-library-evolution</code></li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tanner0101">Tanner Nelson</a> announced <a href="https://forums.swift.org/t/whats-new-in-vapor-4/31832">Vapor 4</a>,
the fourth major release of the web framework for Swift! 🥳</p>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> announced <a href="https://www.swiftforgood.com">Swift for Good</a>,
a book covering 20 Swift topics written by 20 writers, with all revenue going
to charity!</p>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> wrote <a href="https://swiftrocks.com/how-optionset-works-inside-the-swift-compiler.html">a blog post</a>
on how <code class="language-plaintext highlighter-rouge">OptionSet</code> works inside the Swift compiler.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/aciidb0mb3r">Ankit Aggarwal</a> merged <a href="https://github.com/apple/swift-package-manager/pull/2468">a pull request</a>
that allows building and using the <code class="language-plaintext highlighter-rouge">swiftpm</code> binary that was built using
<code class="language-plaintext highlighter-rouge">swiftpm</code>.</p>
<p><a href="https://twitter.com/rintaro">Rintaro Ishizaki</a> opened <a href="https://github.com/apple/swift/pull/28727">a pull request</a>
that would allow for faster code completion by re-using the compiler instance
in SourceKit. Neat!</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/28407">a pull request</a>
that allows a first pass at cross-module optimization, allowing generic
specialization across packages without manual <code class="language-plaintext highlighter-rouge">@inlinable</code> annotations.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0268-didset-semantics.md">SE-0268</a>: <em>Refine <code class="language-plaintext highlighter-rouge">didSet</code> Semantics</em> was <a href="https://forums.swift.org/t/accepted-se-0268-refine-didset-semantics/31822">accepted</a>.</p>
<blockquote>
<p>The proposal has been accepted <a href="https://github.com/apple/swift-evolution/blob/35537af5e63a140c93521d78fdac3c9e2d9ad349/proposals/0268-didset-semantics.md">as it was originally proposed</a>,
prior to the second review.</p>
<p>The change overall received considerable support, despite being
semantic-breaking in rare cases. Being able to make mutations in-place is an
important performance win and one that many current users might already be
expecting.</p>
<p>The second review proposed a small alteration to the original proposal: to
warn on implicit use of <code class="language-plaintext highlighter-rouge">didSet</code>, because in the original review some reviewers
felt that accessing the implicit parameter in the body of the function
resulting in the fetching behavior could be harmful, so proposed a deprecation
warning to be silenced by adding the argument explicitly. During the second
review, it became clear that the feeling of most commenters was that the
increased verbosity (and new warnings) did not justify the change. The core
team agrees with the feedback, and so has accepted the original proposal.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md">SE-0270</a>: <em>Add Collection Operations on Noncontiguous Elements</em> is <a href="https://forums.swift.org/t/se-0270-review-2-add-collection-operations-on-noncontiguous-elements/31653">under review</a>.</p>
<blockquote>
<p>The proposal was returned for revision in order to investigate splitting it
into smaller pieces. Nate Cook, the proposal author, has chosen to make several
revisions, the most significant of which is to remove several sets of methods;
you can see the raw difference <a href="https://github.com/apple/swift-evolution/commit/d61957df1af9fb283da8c0b3108dbea5e3f3b732">here</a>.
The Core Team has elected to run a review of the proposal as revised rather
than sending it back into the pitch phase.</p>
<p>It sometimes happens with re-reviews that the Core Team has substantively
approved parts of the proposal and is asking the community to provide feedback
on specific revisions. That is not the case here because the Core Team did not
feel like it received a strong signal on the core proposal. Accordingly, please
consider this to be a de novo review and provide feedback on the full proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0272-swiftpm-binary-dependencies.md">SE-0272</a>: <em>Package Manager Binary Dependencies</em> is <a href="https://forums.swift.org/t/se-0272-review-2-package-manager-binary-dependencies/31668">under review</a>.</p>
<blockquote>
<p>SwiftPM currently supports source-only packages for several languages, and
with a very proscriptive build model which considerably limits exactly how the
compilation of the source can be performed. While this makes packages consistent
and to some extent “simple”, it limits their use in several important cases:</p>
<ul>
<li>Software vendors who wish to provide easy integration with the package
manager, but do not deliver source code, cannot integrate.</li>
<li>Existing code bases which would like to integrate “simply” with SwiftPM, but
require more complicated build processes, have no recourse.</li>
</ul>
<p>For example, consider these use cases:</p>
<ul>
<li>Someone wants to create a Swift package for
generating <a href="https://llvm.org">LLVM</a> code. However, LLVM’s build process is
far more complex than can be currently fit into SwiftPM’s build model. This
makes building an <em>easy to use</em> package difficult.</li>
<li>A third-party wants to provide a Swift SDK for easily integrating their
service with server-side Swift applications. The SDK itself relies on
substantial amounts of internal infrastructure the company does not want to
make available as open source.</li>
<li>A large company has an internal team which wants to deliver a Swift package
for use in their iOS applications, but for for business reasons cannot publish
the source code.</li>
</ul>
<p>This proposal defines a new SwiftPM feature to allow SwiftPM to accept some
forms of “binary packages”. This proposal is intentionally written to
address the above use cases <em>explicitly</em>, it <strong>does not</strong> define a general
purpose “binary artifact” mechanism intended to address other use cases (such as
accelerating build performance).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0273-swiftpm-conditional-target-dependencies.md">SE-0273</a>: <em>Package Manager Conditional Target Dependencies</em> is <a href="https://forums.swift.org/t/se-0273-package-manager-conditional-target-dependencies/31667">under review</a>.</p>
<blockquote>
<p>This proposal introduces the ability for Swift package authors to
conditionalize target dependencies on platform and configuration with a similar
syntax to the one introduced in
<a href="0238-package-manager-build-settings.md">SE-0238</a> for build settings. This
gives developers more flexibility to describe complex target dependencies to
support multiple platforms or different configuration environments.</p>
<p>This proposal resolves two use cases that the current version of the Package
Manager doesn’t support very well. In the first scenario, packages that span
multiple platforms may need to depend on different libraries depending on the
platform, as can be the case for low-level, platform-specific code. In a second
scenario, packages may want to link against libraries only in certain
configurations, for example when importing debug libraries, which do not make
sense to build and link in release builds, or when importing instrumentation
logic, which only make sense in release builds when the developer can not
benefit from debugging.</p>
<p>This proposal attempts to bring solutions to those use cases by allowing
package authors to define under what build environments dependencies need to be
built and linked against targets.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> shared <a href="https://forums.swift.org/t/generic-type-metadata-prespecialization/31659">some insights</a>
on generic type metadata prespecialization.</p>
<blockquote>
<p>One source of memory and performance overhead in Swift code is the
instantiation and fetching of type metadata. Even though generic specialization
eliminates the need for type metadata in most fully-specialized code, we still
need the metadata in many frequently-occurring situations:</p>
<ul>
<li>Objects always need their class metadata, which serves as the “isa” pointer
with the object’s method table and other dynamic metadata.</li>
<li>When putting a value inside an existential box, the type metadata for the
value’s type is stored in the box to represent its dynamic type.</li>
<li>When calling into unspecialized code, type metadata for the generic type
arguments has to be formed. Code may remain unspecialized because it crosses
ABI boundaries or is invoked via dynamic reflection.</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> shared <a href="https://forums.swift.org/t/december-12th-2019/31735">the Swift Server Work Group December 12th meeting notes</a>.</p>
<blockquote>
<p>Ian Partridge and Chris Bailey let the group know that following a review by
IBM of its open source priorities, it has been decided that they will not be
continuing to work on Swift in 2020. As a result, they are both standing down
from the workgroup.</p>
<p>Ian Partridge will work to hand over responsibilities for the Swift Docker
images and suggested a potential new owner from the community.</p>
</blockquote>
<p><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> pitched <a href="https://forums.swift.org/t/pitch-modify-accessors/31872">a proposal</a>
to make Swift’s modify accessors a public feature.</p>
<blockquote>
<p>We propose the introduction of a new keyword, <code class="language-plaintext highlighter-rouge">modify</code>, for implementing
mutable computed properties and subscripts, alongside the current <code class="language-plaintext highlighter-rouge">get</code> and
<code class="language-plaintext highlighter-rouge">set</code>.</p>
<p>The bodies of <code class="language-plaintext highlighter-rouge">modify</code> implementations will be coroutines, and they will
introduce a new contextual keyword, <code class="language-plaintext highlighter-rouge">yield</code>, that will be used to yield a value
to be modified back to the caller. Control will resume after the <code class="language-plaintext highlighter-rouge">yield</code> when
the caller returns.</p>
<p>This <code class="language-plaintext highlighter-rouge">modify</code> feature is currently available (but not supported) from Swift
5.0 as <code class="language-plaintext highlighter-rouge">_modify</code>, for experimentation purposes when reviewing this proposal.</p>
</blockquote>
<p><a href="https://twitter.com/anandabits">Matthew Johnson</a> pitched <a href="https://forums.swift.org/t/anonymous-structs/31424">a proposal</a>
to introduce anonymous structs.</p>
<blockquote>
<p>This proposal introduces anonymous structs using closure-inspired syntactic
sugar as an alternative to a more verbose local struct declaration. As with
closures, trailing syntax is supported.</p>
<p>While Swift has often been called a protocol-oriented language it still lacks
some features necessary to facilitate protocol-oriented library designs in
practice. One missing feature is syntactic support for ad-hoc, single-use
conformances on par with the expressivity that closures provide for ad-hoc,
single-use functions.</p>
<p>Local type declarations involve a lot of syntactic ceremony that is
unnecessary for singe-use types. This ceremony includes a name, explicit
protocol conformance declarations, and fully written declarations for all
members. In addition to the ceremony of the local type declaration itself, use
of the type requires explicit instantiation, which may itself be verbose if
there are several stored properties to initialize.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>A <a href="https://twitter.com/slava_pestov/status/1206398538743193600">“funny” Swift thing</a>.</p>
Issue #149
https://swiftweeklybrief.com/issue-149
2019-12-05T00:00:00-08:00
2019-12-05T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Earlier today, I finished my last working day of the year. All the holiday
feelings are there now! I hope that you’ve had a great last weeks, including a
great Thanksgiving for those who celebrated it!</p>
<p>And a big special thanks to <a href="https://twitter.com/fassko">Kristaps</a> for helping
out with this issue; I would not have been able to write it without him. 🏎</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11884">SR-11884</a> [Compiler] Link-In
<code class="language-plaintext highlighter-rouge">ubsan_standalone</code> If libFuzzer is used in Isolation</li>
<li><a href="https://bugs.swift.org/browse/SR-11885">SR-11885</a> [Compiler] Allow operator
functions to have extra arguments with default values</li>
<li><a href="https://bugs.swift.org/browse/SR-11889">SR-11889</a> [Compiler] Use a
<code class="language-plaintext highlighter-rouge">Located<T></code> throughout the compiler instead of <code class="language-plaintext highlighter-rouge">std::pair<SourceLoc, T></code></li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/313353">episode 82 of Swift Unwrapped</a>,
Jesse and JP talk about Swift’s New Diagnostic Architecture.</p>
<p>In Swift by Sundell #61, John Sundell and Tim Cordon discuss <a href="https://swiftbysundell.com/podcast/61/">Serverside Swift</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> shared <a href="https://forums.swift.org/t/cve-2019-8849-swiftnio-ssl-executable-stack/31100">a security patch</a>
for SwiftNIO SSL.</p>
<p><a href="https://twitter.com/dmartincy">Daniel Martin</a> wrote <a href="https://pspdfkit.com/blog/2019/intro-cpp-swift-developers/">a blog post</a>
to introduce Swift developers to C++!</p>
<p><a href="https://twitter.com/k__mahar">Kaitlin Mahar</a>’s talk at SwiftServer.conf is
<a href="https://www.youtube.com/watch?v=9-fdbG9jNt4">now available on video</a>, talking
about maintaining Swift libraries.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0269-implicit-self-explicit-capture.md">SE-0269</a>: <em>Increase availability of implicit <code class="language-plaintext highlighter-rouge">self</code> in <code class="language-plaintext highlighter-rouge">@escaping</code> closures when reference cycles are unlikely to occur</em> was <a href="https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376/70">accepted</a>.</p>
<blockquote>
<p>This proposal has been accepted. The proposal discussion roughly divided into
two parts:</p>
<ol>
<li>Discussion around hoisting the explicit mention of <code class="language-plaintext highlighter-rouge">self</code> into the closure
capture list as the alternative to repeatedly writing explicit <code class="language-plaintext highlighter-rouge">self</code> in a
closure body (and having the compiler fix-it encourage that style)</li>
<li>The expansion of implicit <code class="language-plaintext highlighter-rouge">self</code> around the specific case where the type of
<code class="language-plaintext highlighter-rouge">self</code> is a value type</li>
</ol>
<p>The discussion on both topics was deeply constructive and productive. The
core team wants to express their deep thanks to everyone who contributed to
this discussion. Some really fantastic insights were made from different
perspectives.</p>
<p>In the end, the core team felt that the hoisting <code class="language-plaintext highlighter-rouge">self</code> in the closure
capture list provided a better experience where explicit <code class="language-plaintext highlighter-rouge">self</code> will still be
encouraged as it (a) more clearly captures the intent of explicitly mentioning
<code class="language-plaintext highlighter-rouge">self</code> and (b) syntactically will be cleaner in the cases where <code class="language-plaintext highlighter-rouge">self</code> is
uttered multiple times.</p>
<p>The discussion around the expansion of implicit <code class="language-plaintext highlighter-rouge">self</code> was a bit more
fragmented on the review, but ultimately the core team sided with expanding the
use of implicit <code class="language-plaintext highlighter-rouge">self</code> as proposed.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md">SE-0271</a>: <em>Package Manager Resources</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0271-package-manager-resources/31021">accepted with modifications</a>.</p>
<blockquote>
<p>The feedback was positive, but two larger issues were brought up:</p>
<ul>
<li>the proposal states that resource bundles will be located next to the built
executable only on Linux, but that doesn’t quite match up with how software is
packaged up there. In addition, resources will also automatically be found in
all locations specified <a href="https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/FHS%20Bundles.md">here</a>
and there will be a commandline flag to add search paths to custom locations.</li>
<li>the proposal will limit the usefulness of SwiftPM commandline tools on
macOS. We will make it possible to use Xcode specific resources in SwiftPM
directly.</li>
</ul>
<p>The SwiftPM code owners decided to accept a revised version of the proposal
which addresses both of these issues.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0264-stdlib-preview-package.md">SE-0264</a>: <em>Standard Library Preview Package</em> is <a href="https://forums.swift.org/t/se-0264-review-2-standard-library-preview-package/31288">under review #2</a>.</p>
<blockquote>
<p>We propose changing the Swift Evolution process to publish accepted proposals
as individual SwiftPM packages, as well as a <code class="language-plaintext highlighter-rouge">SwiftPreview</code> package that bundles
these proposal packages together. This group of packages will form the initial
landing spot for certain additions to the Swift standard library.</p>
<p>Adding these packages serves the goal of allowing for rapid adoption of new
standard library features, enabling sooner real-world feedback, and allowing
for an initial period of time where that feedback can lead to source- and
ABI-breaking changes if needed.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/reducing-friction-for-development-prebuilt-vscode-images/31109">an update</a>
on reducing friction to get started with Swift through prebuilt Docker images
with complete toolchains, multiple SDKs, and pre-configured VSCode!</p>
<blockquote>
<p>An often cited problem for using Swift on other platforms is the effort
required to get everything working together. To help address this barrier to
entry, I have been exploring some options to reduce the initial friction for
development on other targets (e.g. android, Linux, etc).</p>
<p>Now, I realize that some of my choices may be controversial for some, so, I
would like to preface this as I am <strong>NOT</strong> advocating that this be the only
development, merely an option for those that would like to use it. I personally
prefer to develop locally and use my editor of choice, so I can completely
understand why some may be frustrated with some of the tradeoffs made here.
Please note that I am not trying to remove those options, merely provide an
alternative which others can explore if it suits them.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/filip-sakel/summary">Filip Sakel</a> pitched <a href="https://forums.swift.org/t/better-access-control-on-protocol-requirements/31237">a proposal</a>
for Better Access Control on Protocol Requirements.</p>
<blockquote>
<p>The main problem is that you have to write a lot of boilerplate code. For
every new requirement that you want to be inaccessible to the user for your own
internal Types, you have to:</p>
<ol>
<li>Write the initial Protocol requirement (like the <code class="language-plaintext highlighter-rouge">publish</code> method in
<code class="language-plaintext highlighter-rouge">Publisher</code>).</li>
<li>Rewrite that requirement in the internal Protocol (like the <code class="language-plaintext highlighter-rouge">_publish</code>
method in <code class="language-plaintext highlighter-rouge">TrustedPublisher</code>).</li>
<li>Cancel the initial requirement with an extension implementation that throws
a fatal error (like the <code class="language-plaintext highlighter-rouge">publish</code> method in the extension of
<code class="language-plaintext highlighter-rouge">TrustedPublisher</code>).</li>
</ol>
<p>What I propose is enabling the marking of Protocol requirements with Access
Levels.</p>
</blockquote>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a> pitched <a href="https://forums.swift.org/t/concise-magic-file-names/31297">a proposal</a>
to introduce a concise version of <code class="language-plaintext highlighter-rouge">#file</code>.</p>
<blockquote>
<p>Today, <code class="language-plaintext highlighter-rouge">#file</code> evaluates to a string literal containing the full path to the
current source file. We propose to instead have it evaluate to a human-readable
string containing the filename and module name, while preserving the existing
behavior in a new <code class="language-plaintext highlighter-rouge">#filePath</code> expression.</p>
</blockquote>
<p><a href="https://twitter.com/dhartbit">David Hart</a> pitched <a href="https://forums.swift.org/t/package-manager-conditional-target-dependencies/31306">a proposal</a>
to add Package Manager Conditional Target Dependencies.</p>
<blockquote>
<p>This proposal introduces the ability for Swift package authors to
conditionalize target dependencies on platform and configuration with a similar
syntax to the one introduced in
<a href="0238-package-manager-build-settings.md">SE-0238</a> for build settings. This gives
developers more flexibility to describe complex target dependencies to support
multiple platforms or different configuration environments.</p>
</blockquote>
<p><a href="https://twitter.com/broadway_lamb">Sergej Jaskiewicz</a> pitched <a href="https://forums.swift.org/t/function-calls-in-key-paths/31307">a proposal</a>
to add support for function calls in key paths.</p>
<blockquote>
<p>Today a key path may only reference properties and subscripts:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">\</span><span class="kt">Array</span><span class="o"><</span><span class="kt">String</span><span class="o">>.</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span><span class="o">.</span><span class="n">count</span>
</code></pre></div></div>
<blockquote>
<p>But cannot reference method calls:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="p">\</span><span class="kt">Array</span><span class="o"><</span><span class="kt">String</span><span class="o">>.</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span><span class="o">.</span><span class="nf">lowercased</span><span class="p">()</span><span class="o">.</span><span class="n">count</span>
<span class="c1">// ^</span>
<span class="c1">// error: Invalid component of Swift key path</span>
</code></pre></div></div>
<blockquote>
<p>Since Swift already supports subscripts, how hard can it be to implement
support for method calls in key paths? Sure, subscripts are different from
regular methods, but are they different enough to be an implementation problem?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Swift 6 will include <a href="https://twitter.com/jckarter/status/1197581728665092096">breaking changes</a>!!!</p>
Issue #148
https://swiftweeklybrief.com/issue-148
2019-11-21T00:00:00-08:00
2019-11-21T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I’ve been having a great last two weeks, including a trip to Spain for work —
it’s always great to talk to the people in remote locations and meeting up with
them in person.</p>
<p>I also feel (like some of you, probably) that the holidays are really just
around the corner. Swift Weekly Brief will be here for another two issues this
year; so don’t worry about that.</p>
<p>Speaking of the holiday feeling, it seems like a lot of interesting things are
still going on when it comes to Swift, as you can read about below.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://store.raywenderlich.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_148" target="_blank">Master SwiftUI, Combine and Catalyst!</a></h4>
<p>Three new books from the teams at raywenderlich.com: SwiftUI by Tutorials, Combine: Asynchronous Programming with Swift, and Catalyst by Tutorials. Build fluid and engaging declarative UI for your apps with SwiftUI, master native asynchronous programming with Swift using the Combine framework and run iOS apps natively on macOS with Catalyst!</p>
<p><small><a href="https://store.raywenderlich.com?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_148" target="_blank">store.raywenderlich.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11724">SR-11724</a> [Compiler] Provide a diagnostic when a closure parameter is declared with type sugar</li>
<li><a href="https://bugs.swift.org/browse/SR-11729">SR-11729</a> [llbuild] Add Chromium Tracing as export format option to <code class="language-plaintext highlighter-rouge">llbuild-analyze</code></li>
<li><a href="https://bugs.swift.org/browse/SR-11730">SR-11730</a> [llbuild] Improve GraphViz as export format option to <code class="language-plaintext highlighter-rouge">llbuild-analyze</code></li>
<li><a href="https://bugs.swift.org/browse/SR-11795">SR-11795</a> [Compiler] Replace <code class="language-plaintext highlighter-rouge">OSX</code> with <code class="language-plaintext highlighter-rouge">macOS</code> pretty much everywhere</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/stephentyrone">Steve Cannon</a> wrote <a href="https://swift.org/blog/numerics/">a blog post</a>
on swift.org on <code class="language-plaintext highlighter-rouge">Swift Numerics</code>, a new open source project, partially in lieu
of an implementation for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0246-mathable.md">SE-0246</a>.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> announced <a href="https://forums.swift.org/t/swift-5-1-2-released/30620">Swift 5.1.2</a>,
which includes an improved type-checking algorithm that has significant
performance benefits on code using function builders (such as SwiftUI code).</p>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> gave <a href="https://www.youtube.com/watch?v=Zjlxa1NIfJc">a talk</a>
on bringing Swift to Windows.</p>
<p><a href="https://twitter.com/Gankra_">Alexis Beingessner</a> wrote <a href="https://gankra.github.io/blah/swift-abi/">a blog post</a>
on how Swift achieved dynamic linking support.</p>
<p><a href="https://twitter.com/_plinth_">Steve Hawley</a> announced <a href="http://plinth.org/techtalk/?p=580">Binding Tools for Swift</a>,
which allows C# to interoperate with Swift!</p>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> announced that all core
libraries have been <a href="https://forums.swift.org/t/all-core-libraries-have-been-migrated-to-modern-cmake/30770">migrated to modern CMake (3.51.1)</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/zoecarver">Zoe Carver</a> is working on <a href="https://github.com/apple/swift/pull/28260">a pull request</a>
turning sequences of String comparisons into a fast switch.</p>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a> is working on <a href="https://github.com/apple/swift/pull/25656">a pull request</a>
to make Swift <code class="language-plaintext highlighter-rouge">#file</code> strings include only the base name of the file, making
them a lot easier to digest.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/28399">a pull request</a>
that fixes a <code class="language-plaintext highlighter-rouge">Self</code> type bug that required a mere 1000 line refactoring first. 😅</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0272-swiftpm-binary-dependencies.md">SE-0272</a>: <em>Package Manager Binary Dependencies</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0272-package-manager-binary-dependencies/30994">returned for revision</a>.</p>
<blockquote>
<p>We had a uniformly positive response to the idea of supporting binary
dependencies in SwiftPM and the high-level design, but there are a number of
concerns that came up during review:</p>
<ul>
<li>
<p>The option for disallowing binary dependencies was broadly considered to
not provided enough value to be included. It would also be good to clarify in
the proposal that opt-in/opt-out functionality can still be provided by clients
of libSwiftPM as a workflow feature.</p>
</li>
<li>
<p>Storing the checksum in the resolved file was seen redundant by some folks.
If a revision choses to omit this, we should instead propose to verify the
commit hash that is already stored there to achieve similar results.</p>
</li>
<li>
<p>Several posts mentioned that the API could be simplified and it would make
sense to reduce the complexity here since it isn’t needed for the scoped down
version of the initial pitch that is being proposed here.</p>
</li>
<li>
<p>A number of points should be spelled out more concretely in the proposal:
verifications of the contents of the artifacts, the concrete layout of the ZIP
file and the behaviour if there is no artifact available for the target
platform.</p>
</li>
<li>
<p>Mirror support for this feature should be considered. That should include
adding a new command for specifying mirrors for binary artifacts.</p>
</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md">SE-0271</a>: <em>Package Manager Resources</em> is <a href="https://forums.swift.org/t/se-0271-package-manager-resources/30730">under review</a>.</p>
<blockquote>
<p>Packages should be able to contain images, data files, and other resources
needed at runtime. This proposal describes SwiftPM support for specifying such
package resources, and introduces a consistent way of accessing them from the
source code in the package.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0270-rangeset-and-collection-operations.md">SE-0270</a>: <em>Add Collection Operations on Noncontiguous Elements</em> is <a href="https://forums.swift.org/t/se-0270-add-collection-operations-on-noncontiguous-elements/30691">under review</a>.</p>
<blockquote>
<p>We can use a <code class="language-plaintext highlighter-rouge">Range<Index></code> to refer to a group of consecutive positions in a
collection, but the standard library doesn’t currently provide a way to refer
to discontiguous positions in an arbitrary collection. I propose the addition
of a <code class="language-plaintext highlighter-rouge">RangeSet</code> type that can store any number of positions, along with
collection algorithms that operate on those positions.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> pitched <a href="https://forums.swift.org/t/infer-associated-types-as-generic-parameters-more-eagerly/30833">a proposal</a>
to infer associated types as generic parameters more eagerly.</p>
<blockquote>
<p>This proposal changes associated type inference behavior to short-circuit a
large amount of inference work in the case where the conforming type defines a
generic parameter with the same name as an associated type.</p>
<p>This breaks source compatibility with certain valid programs; in Swift 5.1,
it is possible for an associated type and a generic parameter with the same
name to have different types. However, the name lookup behavior in this case
was already very fragile.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/jon_hull">Jon Hull</a> pitched <a href="https://forums.swift.org/t/pre-pitch-runtime-type-guarantees/30842">a proposal</a>
for Runtime Type Guarantees.</p>
<blockquote>
<p>There is always a tradeoff between safety and performance when writing
reusable code. Low level code either has to make assumptions about the values
being passed to it (e.g. a value is non-zero, or an array is non-empty) or it
has to check those assumptions. When these functions call one another, but
could also be called from the outside, you often find them repeatedly
performing the same check.</p>
</blockquote>
<p><a href="https://twitter.com/lorentey">Karoy Lorentey</a> pitched <a href="https://forums.swift.org/t/pitch-exposing-the-memory-locations-of-class-instance-variables/30584">a proposal</a>
to expose the Memory Locations of Class Instance Variables.</p>
<blockquote>
<p>For Swift to be successful as a systems programming language, it needs to
allow efficient use of the synchronization facilities provided by the
underlying computer architecture and operating system, such as primitive atomic
types or higher-level synchronization tools like <code class="language-plaintext highlighter-rouge">pthread_mutex_t</code> or
<code class="language-plaintext highlighter-rouge">os_unfair_lock</code>. Such constructs typically require us to provide a stable
memory location for the values they operate on.</p>
<p>Swift provides a number of language and runtime constructs that are guaranteed
to have a stable memory location.</p>
<p>However, Swift does not currently provide ways to reliably retrieve the
address of the memory location backing these variables – with the exception of
dynamic variables, where all access is done through an explicit unsafe pointer
whose value is (obviously) known to the code that performs the access.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Formatting<br />
is<br />
<a href="https://twitter.com/uliwitness/status/1193166769688580097">hard</a>.</p>
Issue #147
https://swiftweeklybrief.com/issue-147
2019-11-07T00:00:00-08:00
2019-11-07T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>With the <a href="https://www.serversideswift.info">ServerSide.swift</a> conference having
taken place for the second year, there are a lot of exciting updates on Swift
on the server — and more!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest Swift Unwrapped episode, Jesse and JP talk about the <a href="https://spec.fm/podcasts/swift-unwrapped/311779">new Swift
Compiler Driver</a> project.</p>
<h3 id="news-and-community">News and community</h3>
<p>The Swift for Tensorflow team wrote <a href="https://github.com/apple/swift/blob/master/docs/DifferentiableProgramming.md">an extensive manifesto</a>
on differentiable programming in Swift.</p>
<p><a href="https://twitter.com/tanner0101/">Tanner Nelson</a> wrote <a href="https://swift.org/blog/sswg-update/">a blog post</a>
with an update on the progress in the Swift Server Work Group over the last year.</p>
<p><a href="https://twitter.com/andreascuderi13">Andrea Scuderi</a> wrote <a href="https://medium.com/better-programming/whats-new-in-server-side-swift-3834e70d2281">a blog post</a>
on ServerSide.swift.</p>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> shared <a href="https://twitter.com/Lukasaoz/status/1189835893106003969">some contributions</a>
to the SwiftNIO project from a workshop at ServerSide.swift.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/aciidb0mb3r">Ankit Aggarwal</a> merged <a href="https://github.com/apple/swift/pull/28035">two</a> pull
<a href="https://github.com/apple/swift-package-manager/pull/2397">requests</a> that
simplify the bootstrap script for the Swift Package manager.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0267-where-on-contextually-generic.md">SE-0267</a>: <em><code class="language-plaintext highlighter-rouge">where</code> clauses on contextually generic declarations</em> was <a href="https://forums.swift.org/t/se-0267-where-clauses-on-contextually-generic-declarations/30051/49">accepted with a modification</a>.</p>
<blockquote>
<p>The core team has decided to accept this proposal with one modification. The
proposal addresses the issue of conditional protocol requirements by disallowing
constraints involving <code class="language-plaintext highlighter-rouge">Self</code> from being applied to protocol requirements, but it
should also do so for non-<code class="language-plaintext highlighter-rouge">final</code> class methods, to avoid the same problem with
conditional dynamically-dispatched methods in classes.</p>
</blockquote>
<h2 id="returned-proposals">Returned proposals</h2>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0265-offset-indexing-and-slicing.md">SE-0265</a>: <em>Offset-Based Access to Indices, Elements, and Slices</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0265-offset-based-access-to-indices-elements-and-slices/30503">returned for revision</a>.</p>
<blockquote>
<p>Swift’s indexing model is based on solid concepts that have held up well over
the years, but the verbosity of expressing positions at integer offsets from
known indices has been a persistent pain point. The Core Team feels that this
is a significant problem and is very happy to see a proposal aimed squarely at
it.</p>
<p><code class="language-plaintext highlighter-rouge">OffsetBound</code> allows the expression of abstract indices that aren’t actually
valid in a collection. During the review, it was pointed out that, rather than
responding to this by clamping or reporting an error, we could use it to
improve expressivity: for example, if the user inserts something at <code class="language-plaintext highlighter-rouge">.last + 5</code>,
we could pad out to that index with some (user-provided) padding element. The
Core Team discussed this idea and ultimately decided to reject it. We feel that
it provides a simpler and more consistent programming experience overall if
abstract indices can always be thought of simply as sugar for computing a
specific valid index.</p>
<p>It was also pointed out that anchoring abstract indices at the beginning and
end of a collection is fairly limiting; there are plenty of other interesting
ways of deriving indices, like finding the first index that matches a predicate.
The Core Team feels that it should not be a goal of this feature to totally
replace the need to work with concrete index values. In particular, this
shouldn’t become an arbitrarily-complex expression-template language.</p>
<p>That said, it’s important that abstract indices compose nicely with concrete
indices. Programmers should feel like they can reliably use abstract indices
anywhere they could use concrete indices. That doesn’t appear to be true of the
current proposal: in particular, programmers can slice between two abstract
indices or between two concrete indices, but not between a mix of either. The
Core Team feels it’s important to avoid this kind of inconsistent-feeling
experience.</p>
<p>Along the same vein, abstract indices can only be anchored relative to the
start and end of a collection. It is frequently useful to be able to anchor
relative to a concrete index, e.g. to slice from an index returned by
<code class="language-plaintext highlighter-rouge">firstIndex(where:)</code> to the fifth element past that. This pattern is not
addressed by the current proposal, and it’s not clear whether the proposal can
be extended this way in the future.</p>
<p>If necessary, the Core Team is willing to consider new language support for
slicing subscripts, either through new syntax or through new interpretations of
existing syntax.</p>
<p>The proposal author also requested an opportunity to revise the proposal’s
treatment of certain methods on <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code>.</p>
<p>Accordingly, SE-0265 is returned for revision.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0269-implicit-self-explicit-capture.md">SE-0269</a>: <em>Increase availability of implicit <code class="language-plaintext highlighter-rouge">self</code> in <code class="language-plaintext highlighter-rouge">@escaping</code> closures when reference cycles are unlikely to occur</em> is <a href="https://forums.swift.org/t/se-0269-increase-availability-of-implicit-self-in-escaping-closures-when-reference-cycles-are-unlikely-to-occur/30376">under review</a>.</p>
<blockquote>
<p>Modify the rule that all uses of <code class="language-plaintext highlighter-rouge">self</code> in escaping closures must be explicit
by allowing for implicit uses of <code class="language-plaintext highlighter-rouge">self</code> in situations where the user has already
made their intent explicit, or where strong reference cycles are otherwise
unlikely to occur. There are two situations covered by this proposal. The first
is when the user has explicitly captured <code class="language-plaintext highlighter-rouge">self</code> in the closure’s capture list,
so that the following would compile without error:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">class</span> <span class="kt">Test</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">x</span> <span class="o">=</span> <span class="mi">0</span>
<span class="kd">func</span> <span class="nf">execute</span><span class="p">(</span><span class="n">_</span> <span class="nv">work</span><span class="p">:</span> <span class="kd">@escaping</span> <span class="p">()</span> <span class="o">-></span> <span class="kt">Void</span><span class="p">)</span> <span class="p">{</span>
<span class="nf">work</span><span class="p">()</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">method</span><span class="p">()</span> <span class="p">{</span>
<span class="n">execute</span> <span class="p">{</span> <span class="p">[</span><span class="k">self</span><span class="p">]</span> <span class="k">in</span>
<span class="n">x</span> <span class="o">+=</span> <span class="mi">1</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>Secondly, this proposal would make implicit <code class="language-plaintext highlighter-rouge">self</code> available in escaping
closures when <code class="language-plaintext highlighter-rouge">self</code> is a value type, so that the following would become valid:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">struct</span> <span class="kt">Test</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">x</span> <span class="o">=</span> <span class="mi">0</span>
<span class="kd">func</span> <span class="nf">execute</span><span class="p">(</span><span class="n">_</span> <span class="nv">work</span><span class="p">:</span> <span class="kd">@escaping</span> <span class="p">()</span> <span class="o">-></span> <span class="kt">Void</span><span class="p">)</span> <span class="p">{</span>
<span class="nf">work</span><span class="p">()</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">method</span><span class="p">()</span> <span class="p">{</span>
<span class="n">execute</span> <span class="p">{</span>
<span class="n">x</span> <span class="o">+=</span> <span class="mi">1</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span>
</code></pre></div></div>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/k__mahar">Kaitlin Mahar</a> shared <a href="https://forums.swift.org/t/officially-supported-mongodb-driver/30324">a proposal</a>
to officially support the MongoDB Driver for Swift on the server.</p>
<blockquote>
<p>We’re currently working on adding an asynchronous SwiftNIO-based version of
our API to meet the SSWG incubation process minimal requirements. This is still
in the design phase, and we’d love to hear feedback from the community on what
we’ve come up with so far.</p>
<p><strong>Current State and Future Plans</strong>
We initially developed MongoSwift about 18 months ago with a synchronous API
for use with the mobile/embedded version of MongoDB. However, we’ve increasingly
shifted our focus toward providing a great server-side experience. We did work
over the summer to implement automatic connection pooling in the driver and are
now tackling the crucial asynchronous API.</p>
<p>The driver complies with nearly all of the MongoDB driver
<a href="https://www.github.com/mongodb/specifications">specifications</a>, which are
documents our team writes detailing everything from what a driver’s CRUD API
should look like to how it should select which server to send a command to.
These specs ensure consistent experiences using MongoDB across languages, while
still allowing room for implementations and public APIs to vary in
language-appropriate ways.</p>
</blockquote>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> pitched <a href="https://forums.swift.org/t/multi-pattern-and-conditionally-compiled-catch-clauses/30246">a proposal</a>
to add multi-pattern and conditionally compiled <code class="language-plaintext highlighter-rouge">catch</code> clauses.</p>
<blockquote>
<p>Currently, each <code class="language-plaintext highlighter-rouge">catch</code> clause in a <code class="language-plaintext highlighter-rouge">do</code>-<code class="language-plaintext highlighter-rouge">catch</code> statement may only contain a
single pattern and where clause, and may not be conditionally compiled using a
<code class="language-plaintext highlighter-rouge">#if</code> directive. This is inconsistent with the behavior of cases in switch
statements which provide similar functionality. It also makes some error
handling patterns awkward to express. This proposal extends the grammar of
<code class="language-plaintext highlighter-rouge">catch</code> clauses to support <code class="language-plaintext highlighter-rouge">#if</code> and a comma-separated list of patterns (with
optional <code class="language-plaintext highlighter-rouge">where</code> clauses), resolving this inconsistency.</p>
</blockquote>
<p><a href="https://twitter.com/clarkbw">Bryan Clark</a> asked <a href="https://forums.swift.org/t/github-swift-package-management-service/30406">for ideas and concerns</a>
on how the GitHub package registry will work with the Swift Package Manager.</p>
<blockquote>
<p>Our goal is to present a package management service specification which could
be implemented by anyone, not only GitHub. This spec will include necessary API
endpoints, package naming (URL spec), versioning system, and other elements
required or in addition to the basics. We plan to open source our implementation
(written in Go) such that others can contribute back to it and progress can be
made in the open.</p>
</blockquote>
<p><a href="https://github.com/gmittert">Gwen Mittertreiner</a> has been working on <a href="https://forums.swift.org/t/adding-support-for-windows-as-a-platform/30158">adding support for Windows in the
Swift Package Manager</a>.</p>
<blockquote>
<p>I’ve been making progress on Windows support for SPM, and one of the things
I’d like to add now is adding Windows as a supported platform in the Package
Description.</p>
</blockquote>
<p><a href="https://github.com/GottaGetSwifty">Paul Fechner</a> pitched <a href="https://forums.swift.org/t/pre-pitch-codable-customization-using-propertywrappers/30244">a proposal</a>
on <code class="language-plaintext highlighter-rouge">Codable</code> customization using Property Wrappers.</p>
<blockquote>
<p>Currently the only method of adding custom Encoding/Decoding for <code class="language-plaintext highlighter-rouge">Codable</code>
Types (without a custom implementation) is by adding options to the
<code class="language-plaintext highlighter-rouge">Encoder</code>/<code class="language-plaintext highlighter-rouge">Decoder</code>. Although this is relatively fleshed out in
<code class="language-plaintext highlighter-rouge">JSON</code>(<code class="language-plaintext highlighter-rouge">En</code>/<code class="language-plaintext highlighter-rouge">De</code>)<code class="language-plaintext highlighter-rouge">Coder</code>, there are still some major pain points.</p>
<ol>
<li>Options must be set for every (<code class="language-plaintext highlighter-rouge">En</code>/<code class="language-plaintext highlighter-rouge">De</code>)<code class="language-plaintext highlighter-rouge">coder</code> used</li>
<li>The option Types are separate so e.g. <code class="language-plaintext highlighter-rouge">dateEncodingStrategy</code> and
<code class="language-plaintext highlighter-rouge">dateDecodingStrategy</code> have separate implementations and are both required to
handle full serialization.</li>
<li>The options aren’t Portable and each (en/de)coder must supply their own
options. Not even Swift’s own <code class="language-plaintext highlighter-rouge">PropertyList</code>(<code class="language-plaintext highlighter-rouge">En</code>/<code class="language-plaintext highlighter-rouge">De</code>)<code class="language-plaintext highlighter-rouge">coder</code> has support for
the same options as it’s JSON cousin.</li>
<li>It’s all or nothing. E.g. If a Type or it’s children need to use more than
a single <code class="language-plaintext highlighter-rouge">dateEncodingStrategy</code> they must manage it themselves.</li>
</ol>
</blockquote>
<h3 id="finally">Finally</h3>
<p>You have lacking documentation, and you have <a href="https://github.com/apple/swift/blob/master/docs/DifferentiableProgramming.md#calculus-is-fun">awesome documentation</a>.
(yes, the <a href="https://developer.apple.com/documentation/swift/string">banner</a> here
is amazing, too.)</p>
Issue #146
https://swiftweeklybrief.com/issue-146
2019-10-24T00:00:00-07:00
2019-10-24T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Swift is seeing continuous improvements over the last weeks, including a new
bunch of changes that are backed by interesting proposals.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11619">SR-11619</a> [Compiler] Spurious error
“anonymous closure argument not contained in a closure” in <code class="language-plaintext highlighter-rouge">#if false</code></li>
<li><a href="https://bugs.swift.org/browse/SR-11636">SR-11636</a> [Compiler] Accessing
covariant <code class="language-plaintext highlighter-rouge">Self</code> from stored property initializer in extension segfaults</li>
<li><a href="https://bugs.swift.org/browse/TF-935">TF-935</a> [Autodiff] Add
<code class="language-plaintext highlighter-rouge">-enable-experimental-forward-mode-differentiation</code> flag</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> and <a href="https://twitter.com/joshshaffer">Josh Shaffer</a>
discuss <a href="https://www.swiftbysundell.com/podcast/59">SwiftUI</a>, including the
Swift features that power it.</p>
<h3 id="news-and-community">News and community</h3>
<p>Swift 5.1.1 was <a href="https://forums.swift.org/t/swift-5-1-1-released-linux-only/29732">released</a>.</p>
<p><a href="https://github.com/xedin/">Pavel Yaskevich</a> wrote <a href="https://swift.org/blog/new-diagnostic-arch-overview/">a blog post</a>
about the architectural improvements they’ve been making to get better type
error messages, and goes into detail as to how this works under the hood.</p>
<p><a href="https://github.com/thesayyn">Sahin Yort</a> added <a href="https://github.com/bazelbuild/rules_swift/pull/329">initial support for SwiftPM</a>
to Bazel!</p>
<p>With the release of <a href="https://github.com/swift-server/async-http-client/releases/tag/1.0.0"><code class="language-plaintext highlighter-rouge">async-http-client</code> 1.0.0</a>,
there now is a stable release!</p>
<p>Along <code class="language-plaintext highlighter-rouge">async-http-client</code>, SwiftNIO shipped <a href="https://github.com/apple/swift-nio/releases/tag/2.9.0">version 2.9.0</a>.</p>
<p><a href="https://github.com/hyp">Alex Lorenz</a> announced <a href="https://forums.swift.org/t/the-github-swift-specific-split-llvm-project-repositories-are-now-read-only/29911"><code class="language-plaintext highlighter-rouge">llvm-project</code></a>,
a monorepository for all LLVM-related Swift projects.</p>
<p><a href="https://twitter.com/alfa">Ian Partridge</a> wrote <a href="https://medium.com/@ianpartridge/swift-development-in-docker-using-visual-studio-code-remote-b84d035e70db">a blog post</a>
on doing Swift development in Docker using Visual Studio Code Remote.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> merged <a href="https://github.com/apple/swift/pull/27670">a pull request</a>
improving the performance for decoding data into ASCII… by a factor of 500! 🤯</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0263-string-uninitialized-initializer.md">SE-0263</a>: <em>Add a String Initializer with Access to Uninitialized Storage</em> was <a href="https://forums.swift.org/t/accepted-se-0263-add-a-string-initializer-with-access-to-uninitialized-storage/30057">accepted</a>.</p>
<blockquote>
<p>The proposal has been accepted.</p>
</blockquote>
<p>Well, that’s as clear as it gets. :)</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0266-synthesized-comparable-for-enumerations.md">SE-0266</a>: <em>Synthesized <code class="language-plaintext highlighter-rouge">Comparable</code> conformance for <code class="language-plaintext highlighter-rouge">enum</code> types</em> was <a href="https://forums.swift.org/t/accepted-se-0266-synthesized-comparable-conformance-for-enum-types/29854">accepted</a>.</p>
<blockquote>
<p>The proposal was received positively, and removes boilerplate code for many
common cases.</p>
<p>Concern was raised by some reviewers regarding the implicit reliance on source
ordering to synthesize the conformance. The core team feels this behavior is
justified based on several factors:</p>
<ul>
<li>other features currently expose source ordering for enums (<code class="language-plaintext highlighter-rouge">CaseIterable</code>
order and <code class="language-plaintext highlighter-rouge">rawValue</code> assignment).</li>
<li><code class="language-plaintext highlighter-rouge"><</code> implementations on enums can easily be written in a way where adding
new cases may not break compilation; comparable conformance must always be
considered when adding cases even today.</li>
<li>conforming a type to a protocol requires an understanding of what that
conformance means and how it is being fulfilled. “It compiles” is never enough.</li>
</ul>
<p>Much of the review was occupied with discussion of adding support for structs
and raw-representable enums. The core team would welcome further pitches
weighing the pros and cons of these additions.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0264-stdlib-preview-package.md">SE-0264</a>: <em>Standard Library Preview Package</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0264-standard-library-preview-package/29865">returned for revision</a>.</p>
<blockquote>
<p>The review for SE-0264 has concluded. We had a uniformly positive response to
the idea of previewing standard library content, but many people had questions
and concerns about how the process and versioning was supposed to work. Then
John McCall <a href="https://forums.swift.org/t/se-0264-standard-library-preview-package/29068/21">advanced</a>
the idea of having separately-versioned packages for each proposal. Several
people were favorably disposed, and we didn’t hear any objections from anyone
including the proposers. The core team is, by and large, persuaded that this
approach has many advantages and would like to see a revised proposal that
includes it.</p>
<p>Thanks to all for your engagement, and for making this process work. Even when
a review goes back for revision, we are still making progress, together, on the
evolution of Swift.</p>
</blockquote>
<p>The last sentence also being a good reminder that any input into the evolution
process is greatly appreciated.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0267-where-on-contextually-generic.md">SE-0267</a>: <em><code class="language-plaintext highlighter-rouge">where</code> clauses on contextually generic declarations</em> is <a href="https://forums.swift.org/t/se-0267-where-clauses-on-contextually-generic-declarations/30051">under review</a>.</p>
<blockquote>
<p>This proposal aims to lift the mostly artificial restriction on attaching
<code class="language-plaintext highlighter-rouge">where</code> clauses to declarations that reference only outer generic parameters.
Simply put, this means you no longer have to worry about the <code class="language-plaintext highlighter-rouge">'where' clause
cannot be attached</code> error inside most generic contexts.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0268-didset-semantics.md">SE-0268</a>: <em>Refine <code class="language-plaintext highlighter-rouge">didSet</code> Semantics</em> is <a href="https://forums.swift.org/t/se-0268-refine-didset-semantics/30049">under review</a>.</p>
<blockquote>
<p>Introduce two changes to <code class="language-plaintext highlighter-rouge">didSet</code> semantics -</p>
<ol>
<li>If a <code class="language-plaintext highlighter-rouge">didSet</code> observer does not reference the <code class="language-plaintext highlighter-rouge">oldValue</code> in its body, then
the call to fetch the <code class="language-plaintext highlighter-rouge">oldValue</code> will be skipped. We refer to this as a “simple”
<code class="language-plaintext highlighter-rouge">didSet</code>.</li>
<li>If we have a “simple” <code class="language-plaintext highlighter-rouge">didSet</code> and no <code class="language-plaintext highlighter-rouge">willSet</code>, then we could allow
modifications to happen in-place.</li>
</ol>
<p>Currently, Swift always calls the property’s getter to get the <code class="language-plaintext highlighter-rouge">oldValue</code> if
we have a <code class="language-plaintext highlighter-rouge">didSet</code> observer, even if the observer does not refer to the
<code class="language-plaintext highlighter-rouge">oldValue</code> in its body.</p>
<p>This might look harmless, but it is doing redundant work (by allocating
storage and loading a value which isn’t used). It could also be expensive if the
getter performs some non-trivial task and/or returns a large value.</p>
<p>For example:</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">struct</span> <span class="kt">Container</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">items</span><span class="p">:</span> <span class="p">[</span><span class="kt">Int</span><span class="p">]</span> <span class="o">=</span> <span class="o">.</span><span class="nf">init</span><span class="p">(</span><span class="nv">repeating</span><span class="p">:</span> <span class="mi">1</span><span class="p">,</span> <span class="nv">count</span><span class="p">:</span> <span class="mi">100</span><span class="p">)</span> <span class="p">{</span>
<span class="k">didSet</span> <span class="p">{</span>
<span class="c1">// Do some stuff, but don't access oldValue</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="k">mutating</span> <span class="kd">func</span> <span class="nf">update</span><span class="p">()</span> <span class="p">{</span>
<span class="k">for</span> <span class="n">index</span> <span class="k">in</span> <span class="mi">0</span><span class="o">..<</span><span class="n">items</span><span class="o">.</span><span class="n">count</span> <span class="p">{</span>
<span class="n">items</span><span class="p">[</span><span class="n">index</span><span class="p">]</span> <span class="o">=</span> <span class="n">index</span> <span class="o">+</span> <span class="mi">1</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="k">var</span> <span class="nv">container</span> <span class="o">=</span> <span class="kt">Container</span><span class="p">()</span>
<span class="n">container</span><span class="o">.</span><span class="nf">update</span><span class="p">()</span>
</code></pre></div></div>
<blockquote>
<p>This will create 100 copies of the array to provide the <code class="language-plaintext highlighter-rouge">oldValue</code>, even
though they’re not used at all.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> shared <a href="https://forums.swift.org/t/improving-the-representation-of-polymorphic-interfaces-in-sil-with-substituted-function-types/29711">some thoughts</a>
on improving the representation of polymorphic interfaces in SIL with
“substituted function types”.</p>
<blockquote>
<p>Swift Intermediate Language (SIL) has a lot of incidental complexity arising
from representational issues in how we handle the types of
polymorphically-callable functions such as protocol witnesses, class methods,
and closures. Here is a proposed design for substituted function types, which
tries to address some of these issues.</p>
<p>To implement a polymorphic interface, such as a protocol method or class
method, the different implementations have to share a common generic
machine-level calling convention, even though each implementation has a
different concrete function type derived from the specific parent type it
provides an implementation for.</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched <a href="https://forums.swift.org/t/pitch-add-rangeset-and-related-collection-operations/29961">a proposal</a>
to add <code class="language-plaintext highlighter-rouge">RangeSet</code> and related <code class="language-plaintext highlighter-rouge">Collection</code> operations.</p>
<blockquote>
<p>We can use a range to address a single range of consecutive elements in a
collection, but the standard library doesn’t currently provide a way to access
discontiguous elements. This proposes the addition of a <code class="language-plaintext highlighter-rouge">RangeSet</code> type that
can store the location of any number of collections indices, along with
collection operations that let us use a range set to access or modify the
collection. In addition, because these operations depend on mutable collection
algorithms that we’ve long wanted in the standard library, this proposal
includes those too.</p>
</blockquote>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared <a href="https://forums.swift.org/t/trajectory-for-evaluating-adding-automatic-differentiation-to-swift/30048">some thoughts</a> on
evaluating adding Automatic Differentiation to Swift.</p>
<blockquote>
<p>One of the efforts of the Swift for TensorFlow project has been to explore
adding features like <a href="https://en.wikipedia.org/wiki/Automatic_differentiation">Automatic Differentiation</a>
to the Swift language. This is a powerful capability that can significantly
enrich Swift’s potential as a programming language for scientific computing,
numerics, and machine learning.</p>
<p>Speaking on behalf of the Swift Core Team, we are interested in evaluating
incorporating this capability directly into the Swift language.</p>
<p>[..]</p>
<p>To summarize:</p>
<ul>
<li>An implementation of Automatic differentiation will be added to the
compiler, guarded under a flag (or flags) to indicate it is an experimental
feature. This will be done directly on <code class="language-plaintext highlighter-rouge">master</code>.</li>
</ul>
<p>Once implementations are ready, each component of the feature will go through
the Swift Evolution process. Until that time, the experimental feature will not
be included in official Swift releases.</p>
</blockquote>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> pitched <a href="https://forums.swift.org/t/backwards-deployable-conformances/29876">a proposal</a>
allowing backwards-deployable conformances.</p>
<blockquote>
<p>Let’s say it’s suddenly vitally important that Int conforms to Collection.</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="kd">extension</span> <span class="kt">Int</span><span class="p">:</span> <span class="kt">Collection</span> <span class="p">{</span>
<span class="kd">public</span> <span class="k">var</span> <span class="nv">startIndex</span><span class="p">:</span> <span class="kt">Int</span> <span class="p">{</span> <span class="mi">0</span> <span class="p">}</span>
<span class="kd">public</span> <span class="k">var</span> <span class="nv">endIndex</span><span class="p">:</span> <span class="kt">Int</span> <span class="p">{</span> <span class="k">self</span><span class="o">.</span><span class="n">bitWidth</span> <span class="p">}</span>
<span class="kd">public</span> <span class="nf">subscript</span><span class="p">(</span><span class="nv">index</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span> <span class="p">(</span><span class="k">self</span> <span class="o">>></span> <span class="n">index</span><span class="p">)</span> <span class="o">&</span> <span class="mi">1</span> <span class="p">}</span>
<span class="p">}</span>
</code></pre></div></div>
<blockquote>
<p>What’s the problem? Well, to start, none of these accessors exist in iOS 13,
which means that if someone tries to use this new conformance in iOS, their app
will just crash when running on iOS 13. <a href="https://swift.org/blog/abi-stability-and-apple/">That’s a limitation of shipping Swift
as part of the OS.</a></p>
<p>There are two ways to resolve this today: <code class="language-plaintext highlighter-rouge">@available</code> with a set of minimum
OS versions, or <code class="language-plaintext highlighter-rouge">@_alwaysEmitIntoClient</code>. But that still doesn’t stop someone
from writing this code…</p>
</blockquote>
<div class="language-swift highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="k">let</span> <span class="nv">someInt</span> <span class="o">=</span> <span class="mi">42</span>
<span class="n">myArray</span><span class="o">.</span><span class="nf">append</span><span class="p">(</span><span class="nv">contentsOf</span><span class="p">:</span> <span class="n">someInt</span><span class="p">)</span>
</code></pre></div></div>
<blockquote>
<p>…and trying to run that on iOS 13, where the conformance doesn’t exist. If
the <code class="language-plaintext highlighter-rouge">append(contentsOf:)</code> is not optimized away, this will cause problems.</p>
<p>In theory, we have the same two options for how to deal with this: restrict
the use of the conformance with availability, or emit the conformance into
client binaries. I’ll discuss each of those in turn and then a secret third
option that I think is the best choice.</p>
</blockquote>
<p>You can read the full proposal pitch <a href="https://forums.swift.org/t/backwards-deployable-conformances/29876">here</a>.</p>
<p><a href="https://forums.swift.org/u/lantua/summary">Lantua</a> asked <a href="https://forums.swift.org/t/source-compatibility/29814">for clarification</a>
on source compatability, and <a href="https://twitter.com/beccadax">Becca Royal-Gordon</a>
gave a great answer:</p>
<blockquote>
<p>There are two kinds of Swift releases:</p>
<ul>
<li>
<p>“Non-breaking release”: Language changes that would break any existing Swift
code are not permitted. Any code that was valid before should continue to build
and function the same way.</p>
</li>
<li>
<p>“Source-breaking release”: Some language changes may affect existing, valid
code, either making it invalid or changing its behavior. A source-breaking
release will add a new version to the compiler’s -swift-version flag;
specifying the previous version will cause it to emulate the old compiler’s
behavior in situations where it’s changed, and usually emit deprecation warnings
telling the user what to update for the new version.*</p>
</li>
</ul>
<p>However, things are not quite as black-and-white as this. A
non-source-breaking release may sometimes include very small changes—bug fixes,
new overloads—that could theoretically break existing code, as long as we
believe the breakage will be very small or nonexistent in practice and the
benefit is worth the risk. This is very much a judgement call and the core team
is typically involved with these decisions.</p>
</blockquote>
<p>You can read the full answer <a href="https://forums.swift.org/t/source-compatibility/29814/2">here</a>.</p>
<p><a href="">Frederick Kellison-Linn</a> pitched <a href="https://forums.swift.org/t/instance-level-polymorphism/30087">a proposal</a>
to add suppport for instance-level polymorphism.</p>
<blockquote>
<p>I’ve seen some similar ideas discussed on the forums (notably <a href="https://forums.swift.org/t/polymorphic-methods-in-enums/15093">Polymorphic
methods in enums</a>)
which are focused around the idea of improving the experience of attaching
case-specific behavior to enums without having a totally fragmented
implementation. I encountered this issue yet again yesterday and wanted to
solicit feedback on some thoughts I had about potential solutions.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Together, you can make everything <a href="https://twitter.com/Catfish_Man/status/1186424549455224832">less horrible</a>.
Teamwork is great!</p>
Issue #145
https://swiftweeklybrief.com/issue-145
2019-10-10T00:00:00-07:00
2019-10-10T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I’ve had a great week in Paris, attending and giving a workshop at FrenchKit.
I hope you’ve all had a great week too!</p>
<p>I also wanted to mention that this month is <a href="https://hacktoberfest.digitalocean.com">Hacktoberfest</a>,
a yearly, month-long celebration of open source software. A perfect time to
contribute to (Swift) open source!</p>
<p>And with that, here’s what’s been cookin’ in the last two weeks in terms of
Swift.org and other Apple open source projects.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11574">SR-11574</a> [Compiler] Using <code class="language-plaintext highlighter-rouge">try</code>
instead of <code class="language-plaintext highlighter-rouge">throws</code> should have a better diagnostic</li>
<li><a href="https://bugs.swift.org/browse/SR-11580">SR-11580</a> [SwiftSyntax]
<code class="language-plaintext highlighter-rouge">FloatLiteralExprSyntax</code> and <code class="language-plaintext highlighter-rouge">IntegerLiteralExprSyntax</code> should have comuted
properties that return their <code class="language-plaintext highlighter-rouge">Int</code>/<code class="language-plaintext highlighter-rouge">Float</code> value</li>
<li><a href="https://bugs.swift.org/browse/SR-11588">SR-11588</a> [Compiler] Warn about
derived <code class="language-plaintext highlighter-rouge">Hashable</code> implementation if there’s a custom <code class="language-plaintext highlighter-rouge">Equatable</code></li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/309982">discussed</a> the Standard Library Preview Package.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> merged <a href="https://github.com/apple/sourcekit-lsp/pull/163">a pull request</a>
adding support for local refactoring of Swift code in SourceKit-LSP!</p>
<p><a href="https://github.com/zoecarver">Zoe Carver</a> opened <a href="https://github.com/apple/swift/pull/27551">a pull request</a>
with optimizations for Swift that enables constant-folding of string comparisons.</p>
<p><a href="http://twitter.com/harlanhaskins">Harlan Haskins</a> merged <a href="https://github.com/apple/swift/pull/20420">a pull request</a>
that adds an experimental flag to skip non-inlinable function bodies and turns
it on for the standard library and overlay <code class="language-plaintext highlighter-rouge">.swiftmodules</code>.</p>
<blockquote>
<p>If you’re working on a build system and you’re implementing the
“<code class="language-plaintext highlighter-rouge">-emit-module</code> first, then build” optimization, try adding
<code class="language-plaintext highlighter-rouge">-Xfrontend -experimental-skip-non-inlinable-function-bodies</code>.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0263-string-uninitialized-initializer.md">SE-0263</a>: <em>Add a String Initializer with Access to Uninitialized Storage</em> was <a href="https://forums.swift.org/t/se-0263-review-2-add-a-string-initializer-with-access-to-uninitialized-storage/29663">returned for revision</a>.</p>
<blockquote>
<p>This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">String</code> that provides access
to a String’s uninitialized storage buffer.</p>
<p><code class="language-plaintext highlighter-rouge">String</code> today is well-suited to interoperability with raw memory buffers
when a contiguous buffer is already available, such as when dealing with
<code class="language-plaintext highlighter-rouge">malloc</code>ed C strings. However, there are quite a few situations where no such
buffer is available, requiring a temporary one to be allocated and copied into.
One example is bridging <code class="language-plaintext highlighter-rouge">NSString</code> to <code class="language-plaintext highlighter-rouge">String</code>, which currently uses standard
library internals to get good performance when using <code class="language-plaintext highlighter-rouge">CFStringGetBytes</code>.
Another, also from the standard library, is <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">Float</code>, which currently
create temporary stack buffers and do extra copying. We expect libraries like
SwiftNIO will also find this useful for dealing with streaming data.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0265-offset-indexing-and-slicing.md">SE-0265</a>: <em>Offset-Based Access to Indices, Elements, and Slices</em> is <a href="https://forums.swift.org/t/se-0265-offset-based-access-to-indices-elements-and-slices/29596">under review</a>.</p>
<blockquote>
<p>This proposal introduces <code class="language-plaintext highlighter-rouge">OffsetBound</code>, which can represent a position in a
collection specified as an offset from either the beginning or end of the
collection (i.e. the collection’s “bounds”). Corresponding APIs provide a more
convenient abstraction over indices. The goal is to alleviate an expressivity
gap in collection APIs by providing easy and safe means to access elements,
indices, and slices from such offsets.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0266-synthesized-comparable-for-enumerations.md">SE-0266</a>: <em>Synthesized <code class="language-plaintext highlighter-rouge">Comparable</code> conformance for <code class="language-plaintext highlighter-rouge">enum</code> types</em> is <a href="https://forums.swift.org/t/se-0266-synthesized-comparable-conformance-for-enum-types/29457">under review</a>.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">SE-185</a>
introduced synthesized, opt-in <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformances for
eligible types. Their sibling protocol <code class="language-plaintext highlighter-rouge">Comparable</code> was left out at the time,
since it was less obvious what types ought to be eligible for a synthesized
<code class="language-plaintext highlighter-rouge">Comparable</code> conformance and where a comparison order might be derived from.
This proposal seeks to allow users to opt-in to synthesized <code class="language-plaintext highlighter-rouge">Comparable</code>
conformances for <code class="language-plaintext highlighter-rouge">enum</code> types without raw values or associated values not
themselves conforming to <code class="language-plaintext highlighter-rouge">Comparable</code>, a class of types which I believe make
excellent candidates for this feature. The synthesized comparison order would be
based on the declaration order of the <code class="language-plaintext highlighter-rouge">enum</code> cases, and then the lexicographic
comparison order of the associated values for an <code class="language-plaintext highlighter-rouge">enum</code> case tie.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> announced <a href="https://forums.swift.org/t/new-project-announcement-swift-compiler-driver-reimplementation-in-swift/29696">a Swift compiler driver
reimplementation in Swift</a>!</p>
<blockquote>
<p><a href="https://github.com/apple/swift-driver">The swift-driver project</a> is a new
implementation of the Swift compiler driver that is intended to replace the
existing driver with a more extensible, maintainable, and robust code base. The
Swift compiler’s driver is what handles the build of a Swift module: it runs the
Swift compiler frontend to compile source code to object files, the linker to
link those object files into a library or executable, and so on, and contains
much of the knowledge of how to produce working programs for any given platform.
The driver is the main program that build systems (e.g. SwiftPM, <code class="language-plaintext highlighter-rouge">xcodebuild</code>,
<code class="language-plaintext highlighter-rouge">make</code>, <code class="language-plaintext highlighter-rouge">ninja</code>) interact with to compile Swift code, so it is a key piece of
infrastructure for building Swift code. The new swift-driver is architected as a
Swift library, allowing for deeper integration with the Swift Package Manager.</p>
</blockquote>
<p><a href="https://twitter.com/ilseman/">Michael Ilseman</a> pitched <a href="https://forums.swift.org/t/prototype-protocol-powered-generic-trimming-searching-splitting/29415">a proposal</a>
for protocol-powered generic trimming, searching, and splitting Collections.</p>
<blockquote>
<p>This prototype demonstrates two main protocols, <code class="language-plaintext highlighter-rouge">CollectionConsumer</code> and
<code class="language-plaintext highlighter-rouge">CollectionSearcher</code>, and a suite of API generic over them.</p>
<p>Native regex literals will be built on top of generic functionality and used
with generic APIs. These can be broken down into 4 stages:</p>
<ol>
<li>Consumers: nibbling off the front or back of a Collection</li>
<li>Searchers: finding a needle in a haystack (i.e. a Collection)</li>
<li>Validators: constructing types in the process of consuming/searching</li>
<li><a href="https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f#syntax-for-destructing-matching">Destructuring Pattern Matching Syntax</a>:
Like <code class="language-plaintext highlighter-rouge">~=</code>, but can bind a value</li>
</ol>
<p>Each stage delivers important API and syntax improvements to users alongside
powerful extension points for libraries. Native regex literals would conform to
these protocols and leverage new syntax, allowing them to be used by the same
generic APIs.</p>
<p>This prototype covers stages 1 and 2.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/vitamin/summary">Jon Gilbert</a> pitched <a href="https://forums.swift.org/t/compositional-initialization/29535">a proposal</a>
to add support for Compositional Initalization.</p>
<blockquote>
<p>This proposal introduces an opt-in protocol, PropertyInitializable, which provides two new init methods:</p>
<ul>
<li>failable init from a collections of extensible, typesafe keypath-value
Property objects</li>
<li>non-failable init to clone from another instance, mutating select properties</li>
</ul>
<p>The name “compositional init” means that this proposal allows the state of an
object or struct to be assembled compositionally from sets of properties
(including another instance). Compositional initialization allows mutations to
be encapsulated in a clear, type-safe way.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/greatape/summary">Gustaf Kugelberg</a> pitched <a href="https://forums.swift.org/t/expressiblebytupleliteral-instead-of-tuples-conforming-to-protocols/29626">a
proposal</a>
to introduce <code class="language-plaintext highlighter-rouge">ExpressibleByTupleLiteral</code> instead of tuples conforming to
protocols.</p>
<blockquote>
<p>As can be seen from the forum history, many people have suggested ways to
make it possible to conform tuple types to protocols. It is perhaps most natural
when the conformance can be synthesized, - in my personal usage it’s certainly
conformance to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> that I’ve wanted to confer on my tuple
typed keys.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>With halloween around the corner, take a look <a href="https://twitter.com/jckarter/status/1180206902732419072">at this spooky quiz</a>! 👻</p>
Issue #144
https://swiftweeklybrief.com/issue-144
2019-09-26T00:00:00-07:00
2019-09-26T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Full steam ahead: with Swift 5.1 released and the release process for Swift 5.2
outlined, we can look forward to another wave of improvements to the Swift
language coming up.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-task">Starter task</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11511">SR-11511</a> [Compiler] A returning
value of <code class="language-plaintext highlighter-rouge">Array<Void></code> should give a warning, like <code class="language-plaintext highlighter-rouge">Optional<Void></code></li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/308610">discussed the Swift 5.1 release</a>
with <a href="https://twitter.com/dgregor79">Doug Gregor</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> wrote <a href="https://swift.org/blog/swift-5-1-released/">a blog post</a>
describing the Swift 5.1 release and all of its changes.</p>
<p><a href="https://twitter.com/racer_girl27">Nicole Jacque</a> shared <a href="https://swift.org/blog/5-2-release-process/">the Swift 5.2 release
process</a>, “a release meant to
include significant quality and performance enhancements.”</p>
<p><a href="https://twitter.com/adam_fish">Adam Fish</a> announced <a href="https://twitter.com/adam_fish/status/1174603574283685888">iOS bitcode support for
Rust</a>.</p>
<p><a href="https://twitter.com/vguerra">Victor Guerra</a> shared <a href="https://www.youtube.com/watch?v=1VOWzfULX2w">a talk</a>
about using Swift as syntactic sugar for Multi-Level Intermediate Representation
in Swift for TensorFlow.</p>
<p>In other Swift for TensorFlow news, <a href="https://twitter.com/bradlarson">Brad Larson</a>
announced <a href="https://twitter.com/bradlarson/status/1176594180971233285">the release of Swift for TensorFlow 0.5</a>.</p>
<p><a href="https://twitter.com/mishaldshah">Mishal Shah</a> announced <a href="https://twitter.com/mishaldshah/status/1176280650308968448">Swift 5.1 availability
on Docker</a>.</p>
<p><a href="https://twitter.com/rderik">Derik Ramirez</a> shared <a href="https://rderik.com/blog/building-a-server-client-aplication-using-apple-s-network-framework/">a blog post</a>
on building a server-client application using <code class="language-plaintext highlighter-rouge">Network.framework</code>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0264-stdlib-preview-package.md">SE-0264</a>: <em>Standard Library Preview Package</em> is <a href="https://forums.swift.org/t/se-0264-standard-library-preview-package/29068">under review</a>.</p>
<blockquote>
<p>We propose the addition of a new package, <code class="language-plaintext highlighter-rouge">SwiftPreview</code>, which will form the
initial landing spot for certain additions to the Swift standard library.</p>
<p>Adding this package serves the goal of allowing for rapid adoption of new
standard library features, enabling sooner real-world feedback, and allowing for
an initial period of time where that feedback can lead to source- and
ABI-breaking changes if needed.</p>
<p>As a secondary benefit, it will reduce technical challenges for new community
members implementing new features in the standard library.</p>
<p>In the first iteration, this package will take the following:</p>
<ul>
<li>free functions and methods, subscripts, and computed properties via
extensions, that do not require access to the internal implementation of
standard library types and that could reasonably be emitted into the client</li>
<li>new types (for example, a sorted dictionary, or useful property wrapper
implementations)</li>
<li>new protocols, with conformance of existing library types to those protocols
as appropriate</li>
</ul>
<p>The package will not include features that need to be matched with language
changes, nor functions that cannot practically be implemented without access to
existing type internals or other non-public features such as LLVM builtins.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/xge_apple">Xi Ge</a> pitched <a href="https://forums.swift.org/t/proposal-emitting-source-information-file-during-compilation/28794">a compiler proposal</a>
to emit source information during compilation.</p>
<blockquote>
<p>To enhance the user experience of diagnostics on locally built modules, we
propose emitting an additional file during compilation to keep track of the
source locations of decls (<code class="language-plaintext highlighter-rouge">.sourceinfo</code> file). Mapping from decl USRs to source
locations in the local file system, the file is always emitted as a side product
of Swift modules into a private sub-directory (<code class="language-plaintext highlighter-rouge">swiftmodule/private</code>). This
‘private’ sub-directory will be present in a local build but excluded for
packaging a Swift module for client consumption. A source location is encoded
as an absolute path to the source file and the byte offset inside the source
file.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/jamesgh">James H</a> asked <a href="https://forums.swift.org/t/swift-performance/28776">about Swift’s performance</a> on the server.</p>
<blockquote>
<p>I want to know if there are any plans to effort improving Swift’s performance?
Benchmark after benchmark have…pretty dismal… metrics for Swift when
compared to other systems languages.</p>
<p>Now you could make an argument that benchmarks aren’t necessarily
representative of real-world use-cases.</p>
</blockquote>
<blockquote>
<p>The current Swift implementation is still nowhere near representative of the
performance that should be possible, since we’ve been primarily in the “make it
work” phase of development, and are only now starting to get into the “make it
fast” work.</p>
</blockquote>
<p><a href="https://twitter.com/CTMacUser">Daryle Walker</a> pitched <a href="https://forums.swift.org/t/partial-sorting/28941/7">a proposal</a>
to allow for partial sorting in Swift.</p>
<blockquote>
<p>Just cruising the C++ algorithm list and wondered about <code class="language-plaintext highlighter-rouge">std::partial_sort</code>
and <code class="language-plaintext highlighter-rouge">std::nth_element</code>.</p>
<p>But I’m still wondering why would these be needed, outside of implementing
other sorting things? Stopping at a point much smaller then the whole collection
doesn’t help too much because you still have to scan the whole thing.</p>
<p>Can any of these be implemented stably?</p>
</blockquote>
<p><a href="https://twitter.com/_logicist">Elviro Rocca</a> asked for <a href="https://forums.swift.org/t/whats-the-state-of-modify-yield/29171">an update</a> on <code class="language-plaintext highlighter-rouge">modify</code> and <code class="language-plaintext highlighter-rouge">yield</code>.</p>
<blockquote>
<p>The idea of an <code class="language-plaintext highlighter-rouge">@Atomic</code> wrapper is also cited as an example in the proposal,
so I thought it could be implemented, but it seems that you can’t actually do
that because you cannot ensure that read-write-read processes actually happen
atomically</p>
</blockquote>
<blockquote>
<p>[..] atomic anything will require compiler support when not explicitly working
with pointers or global stored properties. Even with <code class="language-plaintext highlighter-rouge">modify</code>, Swift’s formal
model is still move-in/move-out with assumed/enforced exclusivity, not
by-address. (<code class="language-plaintext highlighter-rouge">modify</code> gets it to move-in/move-out rather than copy-in/copy-out,
but not all the way to by-address. That’s still considered an optimization.)</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/olebegemann/status/1172885004243865601">Only constants 😭</a></p>
Issue #143
https://swiftweeklybrief.com/issue-143
2019-09-12T00:00:00-07:00
2019-09-12T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A lot of new hardware to talk and think about from Tuesday’s Apple Event.
And a lot of new software to look forward to — which includes a whole lot of
the features the Swift team has been working on. I’m very much looking forward
to the new software in particular, and the app updates it will bring.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p>The Gradle team <a href="https://blog.gradle.org/introducing-the-swift-plugins">announced</a>
Swift support to compile, link and install applications and libraries, C++
interoperability, dependency management and more.</p>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> shared <a href="https://github.com/apple/swift/blob/master/docs/CToSwiftNameTranslation.md">a document</a>
explaining name translation from C to Swift.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/27033">a pull request</a>
that directly leads to the elimination of over 400 lines of code from the
compiler. 🎉</p>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> merged <a href="https://github.com/apple/swift-nio/pull/1130">a pull request</a>
enabling the thread sanitizer for SwiftNIO, now that it works well enough on
Linux, thanks to <a href="https://github.com/yln">Julian Lettner</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0263-string-uninitialized-initializer.md">SE-0263</a>: <em>Add a String Initializer with Access to Uninitialized Storage</em> is <a href="https://forums.swift.org/t/se-0263-add-a-string-initializer-with-access-to-uninitialized-storage/27417">under review</a>.</p>
<blockquote>
<p>This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">String</code> that provides access to
a String’s uninitialized storage buffer.</p>
<p><code class="language-plaintext highlighter-rouge">String</code> today is well-suited to interoperability with raw memory buffers when
a contiguous buffer is already available, such as when dealing with <code class="language-plaintext highlighter-rouge">malloc</code>ed
C strings. However, there are quite a few situations where no such buffer is
available, requiring a temporary one to be allocated and copied into. One
example is bridging <code class="language-plaintext highlighter-rouge">NSString</code> to <code class="language-plaintext highlighter-rouge">String</code>, which currently uses standard
library internals to get good performance when using <code class="language-plaintext highlighter-rouge">CFStringGetBytes</code>.
Another, also from the standard library, is <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">Float</code>, which currently
create temporary stack buffers and do extra copying. We expect libraries like
SwiftNIO will also find this useful for dealing with streaming data.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Davide Mendolia pitched <a href="https://forums.swift.org/t/generic-covariance-to-improve-api-usage/28719">a proposal</a>
to introduce generalized Generic Coveriance.</p>
<blockquote>
<p>As far as I know, only Arrays support Generic Covariance. Is it possible to
generalize it or to introduce in core elements like <code class="language-plaintext highlighter-rouge">Result</code> and allow libraries
like Combine to use it?</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">class</span> <span class="kt">Base</span> <span class="p">{</span>
<span class="p">}</span>
<span class="kd">class</span> <span class="kt">Derived</span><span class="p">:</span> <span class="kt">Base</span> <span class="p">{</span>
<span class="p">}</span>
<span class="kd">class</span> <span class="kt">ArrayBase</span> <span class="p">{</span>
<span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="p">[</span><span class="kt">Derived</span><span class="p">])</span> <span class="o">-></span> <span class="p">[</span><span class="kt">Base</span><span class="p">]</span> <span class="p">{</span> <span class="k">return</span> <span class="n">x</span> <span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Would allow simplification of the following code instead of throwing errors
and require casting. Somethings that’s already done today for <code class="language-plaintext highlighter-rouge">Optional</code>s and
<code class="language-plaintext highlighter-rouge">Array</code>.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">class</span> <span class="kt">JustBase</span> <span class="p">{</span>
<span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="kt">Just</span><span class="o"><</span><span class="kt">Derived</span><span class="o">></span><span class="p">)</span> <span class="o">-></span> <span class="kt">Just</span><span class="o"><</span><span class="kt">Base</span><span class="o">></span> <span class="p">{</span> <span class="k">return</span> <span class="n">x</span> <span class="p">}</span> <span class="c1">// Compiler Error: Cannot convert return expression of type 'Just<Derived>' to return type 'Just<Base>'</span>
<span class="p">}</span>
<span class="kd">class</span> <span class="kt">ResultBase</span> <span class="p">{</span>
<span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="kt">Result</span><span class="o"><</span><span class="kt">Derived</span><span class="p">,</span> <span class="kt">Error</span><span class="o">></span><span class="p">)</span> <span class="o">-></span> <span class="kt">Result</span><span class="o"><</span><span class="kt">Base</span><span class="p">,</span> <span class="kt">Error</span><span class="o">></span> <span class="p">{</span> <span class="k">return</span> <span class="n">x</span> <span class="p">}</span> <span class="c1">// Compiler Error: Cannot convert return expression of type 'Result<Derived, Error>' to return type 'Result<Base, Error>'</span>
<span class="p">}</span></code></pre></figure>
<p><a href="https://twitter.com/rxwei">Richard Wei</a> shared <a href="https://forums.swift.org/t/differentiable-programming-mega-proposal/28547">a proposal</a>
for Differentiable Programming.</p>
<blockquote>
<p>We have completed a comprehensive proposal for the differentiable programming
feature we’ve been incubating over the last 1.5 years. We’ve gone over many
iterations on the feature design, and have partially completed the
implementation. Now we are ready to start a discussion on Swift Evolution,
specifically on upstreaming and standardizing the feature.</p>
<p>Since this proposal is overly long (~60 pages), we hope to start by merging
it into the <code class="language-plaintext highlighter-rouge">docs/</code> directory via <a href="https://github.com/apple/swift/pull/27034">this pull request</a>,
and draft bite-sized proposals that contain references to the mega-proposal.</p>
</blockquote>
<p>You can find the full proposal <a href="https://github.com/dan-zheng/swift/blob/differentiable-programming/docs/DifferentiableProgramming.md">here</a>.</p>
<p><a href="https://twitter.com/_AngeloidBeta">Gwynne Raskind</a>
pitched <a href="https://forums.swift.org/t/yet-another-varargs-splat-proposal/28649">a proposal</a>
to support varargs “splat”.</p>
<blockquote>
<p>Forwarding variadic arguments has come up fairly often in discussion, and I
thought I’d try my hand at working up a proposal, with a focus on arguments
against the oft-proposed “prefix operator” syntax.</p>
</blockquote>
<p>You can find the full proposal <a href="https://github.com/gwynne/swift-evolution/blob/splat-proposal/proposals/NNNN-forward-array-to-variadic-args.md">here</a>.</p>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> pitched <a href="https://forums.swift.org/t/pitch-extended-error-messages/28754">a proposal</a>
to extend the capabilities of error messages.</p>
<blockquote>
<p>As a follow up from <a href="https://forums.swift.org/t/future-of-diagnostics-ux/28178">Future of Diagnostics UX</a>
a couple weeks back, I wanted to further explore the idea of “extended
diagnostic messages” and see if they would be a good fit for Swift. What follows
is a rough pitch for what that might look like. I’m not sure if this will/should
result in an evolution proposal, but I think writing this up using the pitch
format makes it easy to evaluate and discuss alternatives.</p>
<p>I’m interested in any and all feedback people have on whether they’d find
this useful! I’m especially interested in hearing from anyone who has worked
with Rust/Elm in the past and can comment on the benefits & drawbacks of their
approaches to diagnostics.</p>
</blockquote>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> shared <a href="https://forums.swift.org/t/august-11th-2019/28553">meeting notes</a>
from the Swift on the Server Working Group that took place on August 8.</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/netflix/status/1171794533140463617">I know, I know…</a>
Still a good joke in my books.</p>
Issue #142
https://swiftweeklybrief.com/issue-142
2019-09-05T00:00:00-07:00
2019-09-05T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>While I have the feeling I’ve had a busy two weeks, it seems like I haven’t
been the only one…</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11397">SR-11397</a> [Standard Library] <code class="language-plaintext highlighter-rouge">FixedWidthInteger.init?(_: radix:)</code> fails for <code class="language-plaintext highlighter-rouge">Self</code> with short <code class="language-plaintext highlighter-rouge">bitWidth</code></li>
<li><a href="https://bugs.swift.org/browse/SR-11418">SR-11418</a> [Compiler / Standard Library] Add Graph Algorithm benchmarks to test <code class="language-plaintext highlighter-rouge">unowned</code>, <code class="language-plaintext highlighter-rouge">weak</code>, and <code class="language-plaintext highlighter-rouge">unmanaged</code></li>
<li><a href="https://bugs.swift.org/browse/SR-11419">SR-11419</a> [Compiler] <code class="language-plaintext highlighter-rouge">missing_witnesses_general</code> Should only be emitted in IDE mode</li>
<li><a href="https://bugs.swift.org/browse/SR-11420">SR-11420</a> [Compiler] Protocol Stubs Should Suggest Requirement Stubs for Renames As Well</li>
<li><a href="https://bugs.swift.org/browse/SR-11421">SR-11421</a> [Compiler] Checked Cast Diagnostics Should Be More Specific When Literals Are Involved</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>On the latest episode of Swift Unwrapped, Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/307679">discussed</a>
Binary Dependencies in Swift Package Manager.</p>
<h3 id="news-and-community">News and community</h3>
<p>Swift 5.0.3 for Linux <a href="https://forums.swift.org/t/swift-5-0-3-for-linux/28523">has been released</a>.</p>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> wrote <a href="https://github.com/apple/swift/blob/master/docs/CToSwiftNameTranslation.md">a document</a>
describing Swift’s C-to-Swift name translation, featuring <code class="language-plaintext highlighter-rouge">enum</code>s and
<code class="language-plaintext highlighter-rouge">swift_wrapper</code> structs.</p>
<p><a href="https://twitter.com/wlisac">Will Lisac</a> shared that <a href="https://github.com/wlisac/swift-on-balena">Swift Docker images for Raspberry Pi 4</a>
are now available.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> shared <a href="https://twitter.com/slava_pestov/status/1166519010135019520">a Twitter thread</a>
detailing an optimization for name lookup.</p>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> shared <a href="https://swiftrocks.com/introsort-timsort-swifts-sorting-algorithm.html">a post</a>
detailing the sorting algorithms Swift uses.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> merged <a href="https://github.com/apple/swift/pull/26630">a pull request</a>
that removes the Swift runtime and standard library’s dependency on Foundation.</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/26803">a pull request</a>
that eliminates temporary copies during in-place updates of enum payloads.</p>
<p><a href="https://twitter.com/gottesmang">Michael Gottessmann</a> merged <a href="https://github.com/apple/swift/pull/26956">a pull request</a>
demonstrating how much a bug and benchmark can help: the NIO <code class="language-plaintext highlighter-rouge">ChannelPipeline</code>
benchmark now runs in half the time! 😱🏎</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0262-demangle.md">SE-0262</a>: <em>Demangle Function</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0262-demangle-function/28186">returned for revision</a>.</p>
<blockquote>
<p>The core team supports having standardized functionality for turning a Swift
symbol name into a human-readable string for logging, debugging, and crash
reporting purposes. However, many important design points were raised in the
review of SE-0262, and so we are returning the proposal for revision.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md">SE-0042</a>: <em>Flattening the function type of unapplied method references</em> was <a href="https://forums.swift.org/t/formally-revoking-se-0042/28174">rejected</a>.</p>
<blockquote>
<p>SE-0042 was formally <a href="https://forums.swift.org/t/accepted-se-0042-flattening-the-function-type-of-unapplied-method-references/1926">accepted</a>
more than three years ago. However, since the proposal was accepted before
having a working implementation was a requirement, and the change would be
source breaking, and also require massive rewrites of the compiler; it is now
clear that this proposal will never actually be implemented. It has been obvious
for a long time.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0263-string-uninitialized-initializer.md">SE-0263</a>: <em>Add a String Initializer with Access to Uninitialized Storage</em> is <a href="https://forums.swift.org/t/se-0263-add-a-string-initializer-with-access-to-uninitialized-storage/27417">under review</a>.</p>
<blockquote>
<p>This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">String</code> that provides access to
a String’s uninitialized storage buffer.</p>
<p><code class="language-plaintext highlighter-rouge">String</code> today is well-suited to interoperability with raw memory buffers
when a contiguous buffer is already available, such as when dealing with
<code class="language-plaintext highlighter-rouge">malloc</code>ed C strings. However, there are quite a few situations where no such
buffer is available, requiring a temporary one to be allocated and copied into.
One example is bridging <code class="language-plaintext highlighter-rouge">NSString</code> to <code class="language-plaintext highlighter-rouge">String</code>, which currently uses standard
library internals to get good performance when using <code class="language-plaintext highlighter-rouge">CFStringGetBytes</code>.
Another, also from the standard library, is <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">Float</code>, which currently
create temporary stack buffers and do extra copying. We expect libraries like
SwiftNIO will also find this useful for dealing with streaming data.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> pitched <a href="https://forums.swift.org/t/offset-indexing-and-slicing/28333">a proposal</a> improving Offset Indexing and Slicing.</p>
<blockquote>
<p>This pitch introduces <code class="language-plaintext highlighter-rouge">OffsetBound</code>, which can represent a position in a
collection specified as an offset from either the start or end of the collection
(i.e. the collection’s “bounds”). This covers an expressivity gap in collection
APIs by providing easy and safe means to fetch an index or element from such an
offset as well as convenient slicing.</p>
<p>If you would like to try it out, you can just copy-paste from
<a href="https://gist.github.com/milseman/1461e4f3e195974a5d1ad76cefdd6961">this gist</a>,
which includes the functionality as well as test cases and examples.</p>
</blockquote>
<p><a href="https://twitter.com/dancherp">Dan Zheng</a> proposed <a href="https://forums.swift.org/t/adding-a-does-x-conform-to-y-request/28349">adding “does <code class="language-plaintext highlighter-rouge">X</code> conform to <code class="language-plaintext highlighter-rouge">Y</code>?”</a>
to the request evaluator.</p>
<blockquote>
<p>I wonder if there are plans to add a “does X conform to Y” request to the
<a href="https://github.com/apple/swift/blob/tensorflow/docs/RequestEvaluator.md">request evaluator</a> system (or other ways to unify conformance lookup logic)?</p>
<p>I’m curious because there multiple ways to perform conformance lookup (and
find associated type witnesses), some of which have caused bugs for the
<a href="https://forums.swift.org/t/pre-pitch-swift-differentiable-programming-design-overview/25992">differentiable programming project</a>, which needs <code class="language-plaintext highlighter-rouge">Differentiable</code> conformance
lookup and associated type witness lookup during Sema, SILGen, and SIL
transforms.</p>
<p>In my experience, the static function <code class="language-plaintext highlighter-rouge">TypeChecker::conformsToProtocol</code> has
been the most reliable way of obtaining a conformance (over
<code class="language-plaintext highlighter-rouge">ModuleDecl::lookupConformance</code> and <code class="language-plaintext highlighter-rouge">ModuleDecl::conformsToProtocol</code>), but it
is available only during Sema, not during SIL.</p>
</blockquote>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> shared some thoughts <a href="https://forums.swift.org/t/future-of-diagnostics-ux/28178">on the future of the Diagnostics User Experience</a>.</p>
<blockquote>
<p>Lately, I’ve been thinking about how the diagnostics user experience for Swift
could be improved in the long term. I thought it would be valuable to start a
conversation around what kind of improvements people would like to see and what
we can learn from other compilers, maybe resulting in some kind of rough
roadmap if there’s enough interest.</p>
</blockquote>
<p><a href="https://twitter.com/GLDeveloper">Giuseppe Lanza</a> pitched <a href="https://forums.swift.org/t/allowing-explicit-escaping-for-optional-closures-in-function-parameters/28334">a proposal</a>
allowing explicit <code class="language-plaintext highlighter-rouge">@escaping</code> for optional closures in function parameters.</p>
<blockquote>
<blockquote>
<p>A closure is said to escape a function when the closure is passed as an argument
to the function, but is called after the function returns . When you declare a
function that takes a closure as one of its parameters, you can write @escaping
before the parameter’s type to indicate that the closure is allowed to escape.</p>
</blockquote>
<p>Quote from the <a href="https://docs.swift.org/swift-book/LanguageGuide/Closures.html">Swift documentation</a></p>
<p>This statement is not always true when considering optional closures passed
as function parameters.</p>
<p>This proposal aims to uniform the behaviour of optional closures with the
well-known behaviour of non-optional closures when passed as function
parameters.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1167087565100339202">Swift “<code class="language-plaintext highlighter-rouge">weak</code>ly” Brief?</a></p>
Issue #141
https://swiftweeklybrief.com/issue-141
2019-08-22T00:00:00-07:00
2019-08-22T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Summer is almost over and it seems that the Swift community is getting ready for some big product announcements later this year. Nevertheless we had quite an intense last two weeks in the Swift.org open source projects.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11295">SR-11295</a> [Compiler] There should be a warning for unnecessary casts</li>
<li><a href="https://bugs.swift.org/browse/SR-11321">SR-11321</a> [SwiftPM] <code class="language-plaintext highlighter-rouge">generate-xcodeproj</code> does not generate relative search paths correctly</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In the <a href="https://www.swiftbysundell.com/podcast/54">latest Swift by Sundell podcast</a>, <a href="https://twitter.com/johnsundell">John Sundell</a>, <a href="https://twitter.com/terhechte">Benedikt Terhechte</a> and <a href="https://twitter.com/basthomas">Bas Broek</a> dive into the new APIs and features in iOS 13 and iPadOS, as well as Swift 5.1.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/Lukasaoz">Cory Benfield</a> gave <a href="https://twitter.com/Lukasaoz/status/1161323863411777537">a heads up</a> that if we are using SwiftNIO HTTP/2, we need to upgrade as soon as possible.</p>
<blockquote>
<p>All <code class="language-plaintext highlighter-rouge">swift-nio-http2</code> users, please update to <code class="language-plaintext highlighter-rouge">swift-nio-http2</code> version 1.5.0 urgently.</p>
<p>A number of HTTP/2 server implementations have been discovered to be at risk of a number of different denial of service attacks. SwiftNIO HTTP/2 has been affected by several of these vulnerabilities. This disclosure covers all of them.</p>
<p>All SwiftNIO HTTP/2 versions between 1.0.0 and 1.4.0 inclusive are affected.</p>
</blockquote>
<p><a href="https://github.com/yln/">Julian Lettner</a> shared a <a href="https://swift.org/blog/tsan-support-on-linux/">blog post</a> about the thread sanitizer for Swift on Linux. If you have any questions head down to the <a href="https://forums.swift.org/t/swift-org-blog-thread-sanitizer-for-swift-on-linux/27872">forum discussion</a>.</p>
<blockquote>
<p>The Swift language guarantees <a href="https://docs.swift.org/swift-book/LanguageGuide/MemorySafety.html">memory safety</a> in single threaded environments. However, conflicting accesses in multithreaded code lead to data races. Data races in Swift cause unexpected behavior and can even lead to memory corruption, breaking Swift’s memory safety. <a href="https://developer.apple.com/documentation/code_diagnostics/thread_sanitizer">Thread Sanitizer</a> is a bug-finding tool that diagnoses data races at run time. It instruments code during compilation and detects data races when they happen during execution.</p>
</blockquote>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> wrote a great <a href="https://swiftrocks.com/using-lldb-manually-xcode-console-tricks.html">blog post</a> on advanced <code class="language-plaintext highlighter-rouge">lldb</code> tricks for Swift - injecting and changing code on the fly.</p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> tweeted about <a href="https://twitter.com/olebegemann/status/1160846803274801152">autodiscovery of test methods</a> on Linux and other non-Darwin platforms.
It was introduced in <a href="https://github.com/apple/swift-package-manager/pull/2174">pull request 2174</a>.</p>
<blockquote>
<p>Autodiscovery of test methods on Linux* is now a thing in recent Swift 5.1 snapshots. You should be able to delete LinuxMain.swift and run your tests with:</p>
<p><code class="language-plaintext highlighter-rouge">swift test --enable-test-discovery</code></p>
</blockquote>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> tweeted that <a href="https://twitter.com/jckarter/status/1161298507527000064">now you can implement</a> the wrapper as a static subscript with access to <code class="language-plaintext highlighter-rouge">self</code>. This was done in <a href="https://github.com/apple/swift/pull/25884">pull request 25884</a> by <a href="https://github.com/DougGregor">Doug Gregor</a>. Be careful and use this at your own risk!</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> tweeted that <a href="https://twitter.com/slava_pestov/status/1160616505589030914">we could learn from JavaScript</a> that delayed parsing is a cool trick.</p>
<blockquote>
<p>Delayed parsing is a cool trick. I know JS implementations do it too. The idea is you can skip building AST for some parts of a source file. In order to correctly parse code following a delayed range, you still have to run the lexer - but it suffices to just count matching braces</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/JDevlieghere">Jonas Devlieghere</a> merged <a href="https://github.com/apple/swift/pull/26673">a pull request</a> that moves Xcode support to C++14. It’s useful to mention that <a href="http://llvm.org/D66195">LLVM and clang are now compiling with C++14</a> as well. You can discuss it <a href="https://forums.swift.org/t/llvm-is-now-on-c-14/27931">here</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> created <a href="https://github.com/apple/swift/pull/26700">a pull request</a> that will simplify one-way constraints to Equal.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>A <a href="https://forums.swift.org/t/proposal-sswg-incubation-process-change-discourage-use-of-unsafe/27921">new proposal</a> from the Swift Server Workgroup about an incubation process change. Feedback period will be till August 29.</p>
<blockquote>
<p>When using <em>Unsafe</em> in Swift, Swift becomes as “safe” as C(++). <a href="https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/">Research</a> shows <a href="https://langui.sh/2019/07/23/apple-memory-safety/">that</a> about <a href="https://alexgaynor.net/2019/aug/12/introduction-to-memory-unsafety-for-vps-of-engineering/">70%</a> of the security vulnerabilities are related to memory safety issues.</p>
<p>Swift and SwiftNIO try to offer programmers fast and safe APIs which should mostly make the use of <em>Unsafe</em> constructs unnecessary. If that is not the case, we appreciate feature requests to add API allowing to use safe APIs to the respective projects.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>The Swift on Server Workgroup had a meeting on July 25th, 2019 and <a href="https://twitter.com/tanner0101">Tanner Nelson</a> shared <a href="https://forums.swift.org/t/july-25th-2019/27732">notes</a>.</p>
<p><a href="https://twitter.com/airspeedswift">Ben Cohen</a> started a discussion whether it’s appropriate to provide a default implementation relying on <code class="language-plaintext highlighter-rouge">ObjectIdentifier</code>. This is a continued discussion from <a href="https://forums.swift.org/t/accepted-se-0261-identifiable-protocol/27358">SE-0261: Identifiable Protocol</a>.</p>
<blockquote>
<p>To set expectations clearly: the proposal has been accepted and the default implementation will ship in Swift 5.1. There is no possibility of it being removed from that release, given the point we are at in the convergence of 5.1, regardless of the direction of this discussion.</p>
</blockquote>
<p><a href="https://twitter.com/gottesmang">Michael Gottesman</a> shared <a href="https://forums.swift.org/t/stdlibcore-now-always-lowers-ownership-after-running-the-diagnostic-passes/27832">news</a> that <code class="language-plaintext highlighter-rouge">stdlibCore</code> now always lowers ownership after running the diagnostic passes.</p>
<blockquote>
<p>…I flipped the switch causing stdlibCore to always lower ownership /after/ running the diagnostic passes. This is a large milestone for ownership in general since this is the first time we have exposed some passes downstream of the Mandatory Inlining to ownership in the build itself (vs tests). It will ensure that changes in tree do not break basic functionality when we are in this mode (something that I have run into).</p>
</blockquote>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> pitched <a href="https://forums.swift.org/t/pitch-didset-semantics/27858">a proposal</a> about <code class="language-plaintext highlighter-rouge">didSet</code> semantics.</p>
<blockquote>
<p>This proposal aims to make a small change to the semantics of didSet, so that the call to the property’s getter is skipped if the user does not refer to the oldValue in the body of the observer. It also aims to make another change, where the lack of a willSet and the presence of a unparameterised didSet could allow for modifications to happen in-place.</p>
</blockquote>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared that now <a href="https://forums.swift.org/t/swift-package-manager-on-windows-sure-why-not/27884">you can use the Swift Package Manager on Windows</a>.</p>
<p><a href="https://forums.swift.org/u/Morten_Bek_Ditlevsen">Morten Bek Ditlevsen</a> started <a href="https://forums.swift.org/t/future-directions-of-property-wrappers/27934">a discussion</a> about future directions of Property Wrappers.</p>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> started <a href="https://forums.swift.org/t/class-constrained-protocol-extension-has-incorrect-mutatingness/27962">a discussion</a> about class-constrained protocol extensions that have incorrect mutatingness.</p>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> posted <a href="https://forums.swift.org/t/why-are-these-evolution-proposals-not-moving-forward/27996">a question</a>: why aren’t some evolution proposals moving forward?</p>
<blockquote>
<p>I’m opening this thread because one of my proposals, <a href="https://github.com/apple/swift-evolution/pull/1053">Synthesized <code class="language-plaintext highlighter-rouge">Comparable</code> for pure enumerations</a>, has been sitting with its swift evolution PR open for nearly a month with no action from core team members who would have the authority to bring it to review. the proposal text is finished, raised issues have been addressed, and its <a href="https://github.com/apple/swift/pull/25696">implementation branch</a> has been untouched for about two months now. By all means, the proposal has fulfilled all the requirements to go to community review (except for CI tests, which can only be triggered by members with write-access), yet still, no review has been scheduled.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/marcrasi">Marc Rasi</a> shared an idea about <a href="https://forums.swift.org/t/building-swiftmodules-for-sourcekit/28030">building <code class="language-plaintext highlighter-rouge">.swiftmodules</code> for SourceKit</a></p>
<blockquote>
<p>I’m working on adding SourceKit to Google’s internal source tooling. The architecture is a server that runs one instance of SourceKit per user, and uses those instances of SourceKit to serve requests from IDEs.</p>
<p>To make this work on code that imports modules, I need to give SourceKit access to the appropriate “.swiftmodule” files.</p>
</blockquote>
<p><a href="https://twitter.com/benlangmuir">Ben Langmuir</a> noted that a preview version of <a href="https://github.com/apple/sourcekit-lsp">SourceKit-LSP</a> is now included in the <a href="https://swift.org/download/#snapshots">nightly toolchain downloads</a> for both Swift 5.1 Development and Trunk Development (<code class="language-plaintext highlighter-rouge">master</code>).</p>
<p><a href="https://forums.swift.org/u/dlbuckley">Dale Buckley</a> started a discussion about <a href="https://forums.swift.org/t/default-protocol-implementation-inheritance-behaviour-the-current-situation-and-what-if-anything-should-be-done-about-it/28049">default protocol implementation inheritance behaviour</a>. The original bug was reported <a href="https://bugs.swift.org/browse/SR-103">here</a>.</p>
<h3 id="finally">Finally</h3>
<p>It is summertime now, need to do some <a href="https://github.com/apple/swift/pull/26650">gardening</a>.</p>
Issue #140
https://swiftweeklybrief.com/issue-140
2019-08-08T00:00:00-07:00
2019-08-08T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Podcast episodes to listen to, interesting proposals and tools that help you go
through all Swift packages. And more.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11198">SR-11198</a> [Compiler] Compiler crash on <code class="language-plaintext highlighter-rouge">inout</code>-to-pointer used with <code class="language-plaintext highlighter-rouge">@autoclosure</code> param returning optional</li>
<li><a href="https://bugs.swift.org/browse/SR-11261">SR-11261</a> [Compiler] Parser recovery for keyword after <code class="language-plaintext highlighter-rouge">case</code> declaration</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest Swift Community Podcast, <a href="https://twitter.com/gridnaka">Kateryna</a>, <a href="https://twitter.com/twostraws">Paul</a>, <a href="https://twitter.com/ericasadun">Erica</a>, and <a href="https://twitter.com/johnsundell">John</a> talk about <a href="https://www.swiftcommunitypodcast.org/episodes/6">their first impressions</a> on SwiftUI.</p>
<p>In the latest Swift Unwrapped episode, <a href="https://twitter.com/jesse_squires">Jesse</a> and <a href="https://twitter.com/simjp">JP</a> discuss <a href="https://spec.fm/podcasts/swift-unwrapped/305700">Generic Math Functions and Approximate Equality</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/daveverwer">Dave Verwer</a> announced <a href="https://daveverwer.com/blog/launching-the-swiftpm-library/">The SwiftPM Library</a>, a Swift Package Manager search engine.</p>
<p>In lights of the Combine release, <a href="https://twitter.com/jasdev">Jasdev Singh</a> wrote <a href="https://jasdev.me/duals">a post</a> explaining reactive and imperative programming.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/26369">a pull request</a> that “fixes a glaring algorithmic problem in code [he] wrote <em>checks notes</em> six years ago”. 😅</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/26356">a pull request</a> that gets them closer to having local variables with <code class="language-plaintext highlighter-rouge">lazy</code> and property wrappers.</p>
<p><a href="https://github.com/atrick">Andrew Trick</a> merged <a href="https://github.com/apple/swift/pull/26440">a pull request</a> where exclusivity enforcement is not just about safety - it also enables better optimizations.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0261-identifiable.md">SE-0261</a>: <em>Identifiable Protocol</em> was <a href="https://forums.swift.org/t/accepted-se-0261-identifiable-protocol/27358">accepted</a>.</p>
<blockquote>
<p>The proposal was positively received as addressing a common need for which a standard protocol is appropriate.</p>
<p>During review, there were some concerns about the use of the property <code class="language-plaintext highlighter-rouge">id</code>, with some preferring <code class="language-plaintext highlighter-rouge">identifier</code> to avoid clashes with existing properties, while others stated they would have the same problem with <code class="language-plaintext highlighter-rouge">id</code>. The core team feels that id, as the term of art, is the better choice. Future <a href="https://forums.swift.org/t/se-0261-identifiable-protocol/26602/166">language features</a> should provide a path to resolve clashes.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0263-string-uninitialized-initializer.md">SE-0263</a>: <em>Add a String Initializer with Access to Uninitialized Storage</em> is <a href="https://forums.swift.org/t/se-0263-add-a-string-initializer-with-access-to-uninitialized-storage/27417">under review</a>.</p>
<blockquote>
<p>This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">String</code> that provides access to a String’s uninitialized storage buffer.</p>
<p><code class="language-plaintext highlighter-rouge">String</code> today is well-suited to interoperability with raw memory buffers when a contiguous buffer is already available, such as when dealing with <code class="language-plaintext highlighter-rouge">malloc</code>ed C strings. However, there are quite a few situations where no such buffer is available, requiring a temporary one to be allocated and copied into. One example is bridging <code class="language-plaintext highlighter-rouge">NSString</code> to <code class="language-plaintext highlighter-rouge">String</code>, which currently uses standard library internals to get good performance when using <code class="language-plaintext highlighter-rouge">CFStringGetBytes</code>. Another, also from the standard library, is <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">Float</code>, which currently create temporary stack buffers and do extra copying. We expect libraries like SwiftNIO will also find this useful for dealing with streaming data.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/deanha">Dean Harel</a> pitched <a href="https://forums.swift.org/t/a-dedicated-function-for-evaluating-void-returning-closures-when-optional-instance-is-not-nil/27367">a proposal</a> for a dedicated function for evaluating <code class="language-plaintext highlighter-rouge">Void</code> returning closures when an <code class="language-plaintext highlighter-rouge">Optional</code> instance is not <code class="language-plaintext highlighter-rouge">nil</code>.</p>
<blockquote>
<p>A transformation of the shape, one that returns nothing, is not uncommon in our day-to-day tasks, and in my opinion deserves a name which clearly and conspicuously translates the writer’s intent in call-site.</p>
<p>In this respect, another Container type in Swift that has been added a dedicated method to handle such “transformations” is the Array type. Consider the following functions:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="n">map</span><span class="o"><</span><span class="kt">T</span><span class="o">></span><span class="p">(</span><span class="n">_</span> <span class="nv">transform</span><span class="p">:</span> <span class="p">(</span><span class="kt">Element</span><span class="p">)</span> <span class="k">throws</span> <span class="o">-></span> <span class="kt">T</span><span class="p">)</span> <span class="k">rethrows</span> <span class="o">-></span> <span class="p">[</span><span class="kt">T</span><span class="p">]</span>
<span class="kd">func</span> <span class="nf">forEach</span><span class="p">(</span><span class="n">_</span> <span class="nv">body</span><span class="p">:</span> <span class="p">(</span><span class="kt">Element</span><span class="p">)</span> <span class="k">throws</span> <span class="o">-></span> <span class="kt">Void</span><span class="p">)</span> <span class="k">rethrows</span></code></pre></figure>
<blockquote>
<p>While we would all agree that <code class="language-plaintext highlighter-rouge">forEach(_:)</code> is not a necessity, we can also agree that for the task of printing all elements in an array, this:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="p">[</span><span class="mi">4</span><span class="p">,</span> <span class="mi">2</span><span class="p">]</span><span class="o">.</span><span class="n">forEach</span> <span class="p">{</span> <span class="nf">print</span><span class="p">(</span><span class="nv">$0</span><span class="p">)</span> <span class="p">}</span></code></pre></figure>
<blockquote>
<p>reads much nicer than this:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="n">_</span> <span class="o">=</span> <span class="p">[</span><span class="mi">4</span><span class="p">,</span> <span class="mi">2</span><span class="p">]</span><span class="o">.</span><span class="n">map</span> <span class="p">{</span> <span class="nf">print</span><span class="p">(</span><span class="nv">$0</span><span class="p">)</span> <span class="p">}</span></code></pre></figure>
<p>Thus I propose adding a parallel function to <code class="language-plaintext highlighter-rouge">Array</code>’s <code class="language-plaintext highlighter-rouge">forEach(_:)</code>, taking advantage of a similar naming for convenience:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">public</span> <span class="kd">extension</span> <span class="kt">Optional</span> <span class="p">{</span>
<span class="kd">func</span> <span class="nf">forValue</span><span class="p">(</span><span class="n">_</span> <span class="nv">body</span><span class="p">:</span> <span class="p">(</span><span class="kt">Wrapped</span><span class="p">)</span> <span class="k">throws</span> <span class="o">-></span> <span class="kt">Void</span><span class="p">)</span> <span class="k">rethrows</span> <span class="p">{</span>
<span class="k">guard</span> <span class="k">let</span> <span class="nv">value</span> <span class="o">=</span> <span class="k">self</span> <span class="k">else</span> <span class="p">{</span> <span class="k">return</span> <span class="p">}</span>
<span class="k">try</span> <span class="nf">body</span><span class="p">(</span><span class="n">value</span><span class="p">)</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p><a href="https://twitter.com/GLDeveloper">Giuseppe Lanza</a> pitched <a href="https://forums.swift.org/t/pitch-unrequired-in-function-signature-for-optional-closure-parameters/27577">a proposal</a> to support <code class="language-plaintext highlighter-rouge">@unrequired</code> in function signatures for optional closure parameters.</p>
<blockquote>
<p>From a perspective of a framework writer it is important to provide clear and understandable documentation for the correct usage of their APIs. Swift allows us to write functions that are at some extent self documenting, and clearly define what the function will actually do.</p>
</blockquote>
<p><a href="https://twitter.com/FranzJBusch">Franz Busch</a> pitched <a href="https://forums.swift.org/t/pitch-support-for-binary-dependencies/27620">a proposal</a> to add support for binary dependencies in the Swift Package Manager.</p>
<blockquote>
<p>This draft introduces support for binary dependencies in SwiftPM. It will allow vendors to upload artifacts for all supported platforms which will be resolved, downloaded and linked by SwiftPM. There are still some open things left, which can be found at the bottom, but we wanted to get community feedback before we continue with this.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/isEqualToDan/status/1154400902083743744">You can do everything you set your mind to.</a></p>
Issue #139
https://swiftweeklybrief.com/issue-139
2019-07-25T00:00:00-07:00
2019-07-25T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It has been a while! The previous issue was beautifully crafted by <a href="https://twitter.com/fassko">Kristaps
Grinbergs</a>. Thanks again so much for that!</p>
<p>With all the heat (in Europe, at least…) I hope you’re keeping it cool.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.pragmaconference.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_139" target="_blank">Pragma Conference 2019 in Bologna - Italy</a></h4>
<p>Join us on 9th October for 4 amazing workshops, continuing on 10th - 11th October for 18 sessions with the greatest international speakers. Be part of something unforgettable: meet the experts, talk with fellow developers and discover new technologies, all in the charming Bologna, while eating some fine food. <br />More than a conference, in the Italian way.</p>
<p><small><a href="https://www.pragmaconference.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_139" target="_blank">pragmaconference.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11148">SR-11148</a> [Compiler] Separate <code class="language-plaintext highlighter-rouge">do</code>
and <code class="language-plaintext highlighter-rouge">while</code> blocks generate error from legacy diagnostic</li>
<li><a href="https://bugs.swift.org/browse/SR-11159">SR-11159</a> [Compiler] Typechecker
crash on overloaded <code class="language-plaintext highlighter-rouge">enum</code> case</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p>SwiftNIO 2.4.0 <a href="https://twitter.com/johannesweiss/status/1149427820948545537">shipped</a>,
containing an important fix for everybody using HTTP/1 + upgraders, for example
WebSocket. You can read the analysis of the issue <a href="https://github.com/IBM-Swift/Kitura-WebSocket-NIO/issues/35">here</a>.</p>
<p><a href="https://twitter.com/kts">Kevin Sweeney</a> shared <a href="https://forums.swift.org/t/swift-5-0-2/27008">the release of Swift 5.0.2</a>
for Linux.</p>
<p><a href="https://twitter.com/edd">Edd Wilder-James</a> shared <a href="https://twitter.com/edd/status/1149438747609448449">an update</a>
on expanding Tensorflow in the open, announcing a special interest group for
Multi-Level Intermediate Representation (MLIR), an intermediate representation
and compiler framework.</p>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> shared <a href="https://forums.swift.org/t/july-11th-2019/26986">meeting notes</a>
of the Swift on the server workgroup meeting on July 11th.</p>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> shared <a href="https://twitter.com/johannesweiss/status/1151390949320384512">an API-breakage
checker</a> has been
added to the SwiftNIO repository.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> once more <a href="https://twitter.com/dgregor79/status/1152280218083586051">asked</a>
to include projects to the Source Compatibility Suite, which is used to detect
breaking changes.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/armen_mkrtchian">Armen Mkrtchian</a> merged
<a href="https://github.com/apple/swift/pull/25309">a pull request</a> with non-ASCII
String case-conversion benchmarks that uncovered optimization opportunities for
ASCII strings.</p>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> merged <a href="https://github.com/apple/swift/pull/26007">a pull request</a>
that implements those optimizations uncovered by Armen! 🏎</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/25978">a pull request</a>
that makes Swift traps more user-friendly. By encoding the error message in the
DWARF line table, you’ll see the message in <code class="language-plaintext highlighter-rouge">.dSYM</code>-symbolicated backtraces and
crash reports, without strings leaking in your binaries.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0261-identifiable.md">SE-0261</a>: <em>Identifiable Protocol</em> is <a href="https://forums.swift.org/t/se-0261-identifiable-protocol/26602">under review</a>.</p>
<blockquote>
<p>This proposal introduces an <code class="language-plaintext highlighter-rouge">Identifiable</code> protocol, a general concept that
is broadly useful — for diff algorithms, user interface libraries, and other
generic code — to correlate snapshots of the state of an entity in order to
identify changes. It is a fundamental notion that deserves representation in
the standard library.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0262-demangle.md">SE-0262</a>: <em>Demangle Function</em> is <a href="https://forums.swift.org/t/se-0262-demangle-function/27199">under review</a>.</p>
<blockquote>
<p>Introduce a new standard library function, <code class="language-plaintext highlighter-rouge">demangle</code>, that takes a mangled
Swift symbol, like <code class="language-plaintext highlighter-rouge">$sSS7cStringSSSPys4Int8VG_tcfC</code>, and output the human readable
Swift symbol, like <code class="language-plaintext highlighter-rouge">Swift.String.init(cString: Swift.UnsafePointer<Swift.Int8>) -> Swift.String</code>.</p>
<p>Currently in Swift, if a user is given an unreadable mangled symbol, they’re
most likely to use the <code class="language-plaintext highlighter-rouge">swift-demangle</code> tool to get the demangled version.
However, this is a little awkward when you want to demangle a symbol in-process
in Swift. One could create a new <code class="language-plaintext highlighter-rouge">Process</code> from Foundation and set it up to
launch a new process within the process to use <code class="language-plaintext highlighter-rouge">swift-demangle</code>, but the
standard library can do better and easier.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/kattrali">Delisa Mason</a> pitched <a href="https://forums.swift.org/t/stdlib-cleanup-callback-for-fatal-swift-errors/26977">a proposal</a> to introduce a cleanup
callback for fatal Swift errors.</p>
<blockquote>
<p>In the event of a fatal error caused by Swift code, there is no direct way to
get the error message and context from Swift without out-of-process log parsing.
Fatal errors “fall through” to signal handlers at which point the crash context
is lost. The goal of this proposal is to provide a native Swift cleanup callback
for fatal errors without the complexity of signal handlers nor allowing
attempted recovery. This context could be written to disk or logged in a custom
format or aggregated for later analysis.</p>
</blockquote>
<p><a href="">Soroush Khanlou</a> pitched <a href="https://forums.swift.org/t/require-parameter-names-when-referencing-to-functions/27048">a proposal</a>
to require parameter names when referencing to functions.</p>
<blockquote>
<p>Some of you may remember <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0220-count-where.md">SE-0220</a>
my proposal that added the <code class="language-plaintext highlighter-rouge">count(where:)</code> function to sequences. This proposal
was ultimately accepted in time for Swift 5, but sadly <a href="https://github.com/apple/swift/pull/22289">had to be reverted</a>
because it was causing issues with the type checker.</p>
<p>The issue was that when you reference <code class="language-plaintext highlighter-rouge">count</code>, in an expression like
<code class="language-plaintext highlighter-rouge">myArray.count * 5</code>, you could be referring to the count property, with type
<code class="language-plaintext highlighter-rouge">Int</code>, or the <code class="language-plaintext highlighter-rouge">count(where:)</code> function, which has type
<code class="language-plaintext highlighter-rouge">((Element) -> Bool) -> Int</code>, which you can refer to in shorthand as <code class="language-plaintext highlighter-rouge">count</code>.
When Swift tries to resolve what version of the <code class="language-plaintext highlighter-rouge">*</code> function to use, it has to
run through a lot more potential implementations, which explode combinatorially
as you increase the number of operators in the expression.</p>
<p>I’ve thought about this problem for a while and chatted with a few folks about
the issue, and I think the simplest path forward to solve this is to require
parameter names when referencing functions.</p>
</blockquote>
<p><a href="https://twitter.com/idrougge">Iggy Drougge</a> pitched <a href="https://forums.swift.org/t/compilation-conditions-for-word-size/26995">a proposal</a>
to add compilation conditions for word size.</p>
<blockquote>
<p>A lot of code written to support more than one platform contains <code class="language-plaintext highlighter-rouge">#if arch()</code>
conditions to handle differences between 32-bit or 64-bit platforms or little
and big endian CPUs. This may turn into long statements like <code class="language-plaintext highlighter-rouge">#if arch(x86_64)
|| arch(arm64) || arch(s390x) || arch(powerpc64) || arch(powerpc64le)</code>,
enumerating every (currently) supported architecture which must be handled by
that <code class="language-plaintext highlighter-rouge">#if ... #endif</code> clause.</p>
</blockquote>
<p><a href="https://twitter.com/LotUDev">Jari Koopman</a> shared <a href="https://forums.swift.org/t/feedback-swift-prometheus-implementation/26928">a proposal</a>
to implement a Swift Prometheus implementation.</p>
<blockquote>
<p>Prometheus is one of the most widely used libraries for metrics in the
serverside world. SwiftPrometheus is a client side implementation in Swift,
with the ability to use it both connected to & separately from swift-metrics.</p>
<p>With Prometheus being one of the most widely used metric reporting tools,
it’s a buildstone that can not be left out in a serverside ecosystem. This
package is created for everyone to use & build upon for their metric reporting.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/UINT_MIN/status/1149409709968912384">Your argument is… valid?!</a></p>
Issue #138
https://swiftweeklybrief.com/issue-138
2019-07-11T00:00:00-07:00
2019-07-11T00:00:00-07:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>It’s already the middle of summer and lot of people are having summer break. Despite that, the Swift team and community members have been active as always. A lot of important pull requests have been merged and created. Not mentioning a lot of active discussions on the forums.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.eventbrite.com/e/swiftfest-2019-tickets-56501408233?discount=Swift-Weekly-99-Off?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_138" target="_blank">SwiftFest Boston 2019, all the talks are live!</a></h4>
<p>SwiftFest is the most community-driven conferences focused on Swift that brings together engineers, architects, midnight-coders, and students in a highly social and vibrant environment. This year you can learn about Swift, SwiftUI, augmented and virtual reality, accessibility, NFC, machine learning, development-culture, security, TDD, etc. <br /><br />SwiftFest Boston - July, 29th-30th, get your discounted ticket today ($99 off) using the code <strong>Swift-Weekly-99-Off</strong>.</p>
<p><small><a href="https://www.eventbrite.com/e/swiftfest-2019-tickets-56501408233?discount=Swift-Weekly-99-Off?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_138" target="_blank">swiftfest.io/schedule</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-11066">SR-11066</a> [Compiler] False positive “never mutated” warning when property with mutating getter is accessed on value</li>
<li><a href="https://bugs.swift.org/browse/SR-11033">SR-11033</a> [Compiler] Add option in Swift driver to disable color diagnostics</li>
<li><a href="https://bugs.swift.org/browse/SR-10979">SR-10979</a> [Compiler] Add FixIt for “Operator implementation without matching operator declaration”</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest Swift by Sundell episode, <a href="https://twitter.com/johnsundell">John Sundell</a> and <a href="https://twitter.com/clattner_llvm">Chris Lattner</a> talked about Swift’s past, present and future.</p>
<p>Property Wrappers are becoming an important topic in the Swift community. That’s why <a href="https://twitter.com/simjp">JP</a> and <a href="https://twitter.com/jesse_squires">Jesse</a> are discussing that in <a href="https://spec.fm/podcasts/swift-unwrapped/302918">the latest Swift Unwrapped podcast episode</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/jeremyphoward">Jeremy Howard</a> and <a href="https://twitter.com/clattner_llvm">Chris Lattner</a> shared <a href="https://medium.com/tensorflow/fast-ais-deep-learning-from-the-foundations-with-swift-for-tensorflow-3ee7dfb68387">a blog post</a> about releasing Swift for TensorFlow v0.4.</p>
<p><a href="https://twitter.com/artemredkin">Artem Redkin</a> and other contributors released <a href="https://github.com/swift-server/async-http-client">AsyncHTTPClient version 1.0.0-alpha.1</a> - a Swift NIO2 based HTTP client recently approved to ‘sandbox’ by the Swift Server Work Group.</p>
<p><a href="https://github.com/swiftbrew/Swiftbrew/releases">Swiftbrew</a> - Homebrew for Swift packages 0.1.1 has been released. A package manager that installs prebuilt Swift command line tool packages, or Homebrew for Swift packages.</p>
<p><a href="https://twitter.com/akyrtzi">Argyrios Kyrtzidis</a> pushed a first commit to the <a href="https://github.com/apple/swift-format">Swift Format</a> repository. Swift-format provides the formatting technology for SourceKit-LSP and the building blocks for doing code formatting transformations.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> merged <a href="https://github.com/apple/swift/pull/25624">a pull request</a> showing ‘some’ type origins in diagnostics, like ‘aka’ for sugared types.</p>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/25892">a pull request</a> that resolves <a href="https://bugs.swift.org/browse/SR-10987">SR-10987</a>: Compiler crashes on invalid reference to <code class="language-plaintext highlighter-rouge">subscript</code> member.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/25884">a pull request</a> which allows property wrapper types to support a second access pattern for instance properties of classes.</p>
<p><a href="https://forums.swift.org/u/john_mccall/summary">John McCall</a> merged <a href="https://github.com/apple/swift/pull/25926">a pull request</a> that adds support for opaque result types when applying a function builder to a function.</p>
<p><a href="https://twitter.com/numist">Scott Perry</a> merged <a href="https://github.com/apple/swift/pull/25794">a pull request</a> that dramatically improves the runtime performance of collection diffing.</p>
<p><a href="https://twitter.com/xwu">Xiaodi Wu</a> merged <a href="https://github.com/apple/swift/pull/25745">a pull request</a> that helps to reorganize <code class="language-plaintext highlighter-rouge">Decimal.swift</code>, aligning two implementations. This resolves <a href="https://github.com/apple/swift/pull/25745">SR-3126</a>.</p>
<p><a href="https://twitter.com/numist">Scott Perry</a> merged <a href="https://github.com/apple/swift/pull/25826">a pull request</a> that adds <code class="language-plaintext highlighter-rouge">CollectionDifference.inverse()</code> and test coverage.</p>
<p><a href="https://forums.swift.org/u/john_mccall/summary">John McCall</a> merged <a href="https://github.com/apple/swift/pull/26019">a pull request</a> which fixes mangling dependent protocol conformances.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md">SE-0258</a>: <em>Property Wrappers</em> was <a href="https://forums.swift.org/t/se-0258-property-wrappers-third-review/26399">accepted with modifications</a>.</p>
<blockquote>
<p>There was a lot more great discussion in this review, and while there were some questions and reservations, overall the community expressed strong support for accepting the proposal. The Core Team agrees and has decided to accept SE-0258 with only one minor change: we would like to accept the community’s suggestion that the initialValue: argument label on wrapper initializers be renamed to wrappedValue: to match the property name. The Core Team feels that this is a minor enough change to make without a further round of review.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0261-identifiable.md">SE-0261</a>: <em>Identifiable Protocol</em> is <a href="https://forums.swift.org/t/se-0261-identifiable-protocol/26602">under review</a>.</p>
<blockquote>
<p>This proposal introduces an <code class="language-plaintext highlighter-rouge">Identifiable</code> protocol, a general concept that is broadly useful - for diff algorithms, user interface libraries, and other generic code - to correlate snapshots of the state of an entity in order to identify changes. It is a fundamental notion that deserves representation in the standard library.</p>
<p>Swift-evolution thread: <a href="https://forums.swift.org/t/move-swiftuis-identifiable-protocol-and-related-types-into-the-standard-library/25713">Move SwiftUI’s <code class="language-plaintext highlighter-rouge">Identifiable</code> and related types into the standard library</a></p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> shared <a href="https://forums.swift.org/t/june-27th-2019/26580">meeting notes</a> from the June 27th Swift Server Working Group meeting.</p>
<blockquote>
<p><a href="https://forums.swift.org/t/redisnio-name-brainstorm/26521">Naming</a> and more <a href="https://forums.swift.org/t/nioapns-naming-brainstorm/26520">naming</a>:</p>
<ul>
<li>summary: there are no good solutions so we need a compromise</li>
<li>we might be overthinking the problem but existing clashes have shown how hard it is to unbreak a clash</li>
<li>after a lot of discussion we came to the conclusion that ‘despite nobody liking cutesy names very much there are the most lightweight workable solution’. However we won’t prescribe cute names</li>
<li>try to stay unique, cutesy/clearly unique name preferred for the time being</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/akyrtzi">Argyrios Kyrtzidis</a> explained about plans to <a href="https://forums.swift.org/t/integrating-libsyntax-into-the-compiler-pipeline/26605">integrate libSyntax into the compiler pipeline</a>.</p>
<blockquote>
<p>We have been developing libSyntax (and SwiftSyntax as the Swift counterpart) whose purpose is to represent the syntax of Swift source code with full fidelity (including whitespace), enable structured editing, provide immutable, thread-safe data structures, and support incremental re-parsing.</p>
</blockquote>
<p><a href="https://twitter.com/eaplatanios">Anthony Platanios</a> started a discussion about <a href="https://forums.swift.org/t/removing-the-comparable-constraint-for-numeric-magnitude/26498">removing the <code class="language-plaintext highlighter-rouge">Comparable</code> constraint for <code class="language-plaintext highlighter-rouge">Numeric.Magnitude</code></a>.</p>
<blockquote>
<p>As part of Swift for TensorFlow we have been working towards designing a set of protocols that more closely resemble mathematical concepts and can, for example, be used for conveniently implementing numerical optimizers. In trying to integrate our changes with the standard library we bumped into an issue related to Numeric. We have already designed a few protocols (e.g., VectorProtocol and PointwiseMultiplicative) for which we support automatic conformance derivation for aggregate types (e.g., structs containing tensors). We want to also support Numeric derivations for such aggregate structures and the current issue is that the Comparable constraint on Magnitude is causing some issues as it’s not straightforward what the semantics should be.</p>
</blockquote>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> pointed out post by <a href="https://twitter.com/akyrtzi">Argyrios Kyrtzidis</a> about <a href="https://forums.swift.org/t/formatting-technology-for-sourcekit-lsp-and-other-tools/26560">bringing formatting technology to SourceKit-LSP</a>.</p>
<blockquote>
<p>Formatting is integral to the experience of editing source code which why it is included in the LSP specification. This functionality, however, is currently missing from SourceKit-LSP. We want to provide users a great out-of-the-box experience of using SourceKit-LSP, across all editors and platforms, and first-class support for formatting is a critical piece of the experience.</p>
<p>For SourceKit-LSP we’d like to have formatting functionality that is:</p>
<ol>
<li>Fast and capable of real-time, “as you type”, performance</li>
<li>Be robust and work even in the presence of invalid code</li>
<li>Work in contexts that may only provide a string of Swift source code for context such as snippets in code-review</li>
</ol>
</blockquote>
<p>An excellent pitch by <a href="https://forums.swift.org/u/owenv/summary">Owen Voorhees</a> explaining <a href="https://forums.swift.org/t/pitch-another-attempt-at-passing-arrays-as-varargs-with-implementation/26718">another attempt in passing arrays as variadic arguments</a>.</p>
<blockquote>
<p>This proposal introduces a new expression, <code class="language-plaintext highlighter-rouge">#variadic</code>, which may appear in the argument list of a function or subscript call. <code class="language-plaintext highlighter-rouge">#variadic</code> allows the user to pass an <code class="language-plaintext highlighter-rouge">Array</code>’s elements in lieu of variadic arguments. This enables cleaner API interfaces and allows for the manual forwarding of variadic arguments.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/rlziii/summary">Richard L Zarth III</a> pitched <a href="https://forums.swift.org/t/pitch-allow-for-compile-time-checked-intervals-for-parameters-expecting-literal-values/26743">an idea to allow for compile-time checked intervals for parameters expecting literal values</a>.</p>
<blockquote>
<p>Certainly methods are written to primarily accept literal values. However, when using types such as Int or Double there is no way to check at compile time that the supplied arguments are valid for a given interval/range. We must rely on run time checks that could cause for adverse side effects which may be difficult to handle.</p>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> <a href="https://forums.swift.org/t/feedback-swift-statsd-client-implementation/26848">informed</a> about the <a href="https://github.com/swift-server/sswg/blob/master/proposals/SSWG-0007.md">SSWG-0007</a>: <em><code class="language-plaintext highlighter-rouge">Statsd</code> Client</em> review.</p>
<blockquote>
<p>After the <a href="https://forums.swift.org/t/discussion-swift-statsd-client-implementation/26109">discussion thread</a>, we are proposing this as a final revision of this proposal and enter the proposal review phase which will run until the 29th July 2019.</p>
<p>The feedback model will be very similar to the one known from Swift Evolution. The community is asked to provide feedback in the way outlined below and after the review period finishes, the SSWG will – based on the community feedback – decide whether to promote the proposal to the [Sandbox}(https://github.com/swift-server/sswg/blob/master/process/incubation.md#process-diagram) maturity level or not.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Sometimes <a href="https://developer.apple.com/documentation/contacts/cnlabelcontactrelationeldercousinmotherssiblingsdaughterorfatherssistersdaughter">variable names can be quite long</a>.</p>
Issue #137
https://swiftweeklybrief.com/issue-137
2019-06-27T00:00:00-07:00
2019-06-27T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It has at this point already been more than two and a half weeks since WWDC.
While many are looking into the new tech announced there, as well as playing
with the beta software, this is what has been going on in the Swift.org open
source projects over the last two weeks.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/bsaeta">Brennan Saeta</a> shared that Swift for Tensorflow
<a href="https://twitter.com/bsaeta/status/1137014498995257344">will be holding weekly open design meetings</a>.</p>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> shared the release of
<a href="https://github.com/grpc/grpc-swift/releases/tag/1.0.0-alpha.1">grpc-swift</a>,
the first Swift gRPC (Remote Procedure Calls) built on top of <code class="language-plaintext highlighter-rouge">SwiftNIOHTTP2</code>.</p>
<p>The second <a href="https://www.serversideswift.info/2019/">Server Side Swift Conference</a>
will be held on October 30th and November 1st, 2019, in Copenhagen, Denmark.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/25449">a pull request</a>
implementing composition of property wrappers.</p>
<p><a href="https://github.com/apple/swift/pull/25408">A pull request</a> was merged that
makes Dictionaries to not be rewritten into a call expression after type
checking. The new way is to keep the <code class="language-plaintext highlighter-rouge">LiteralExpr</code> around and just stash a
reference to the right initializer.</p>
<p><a href="https://github.com/dcci">Davide Italiano</a> merged <a href="https://github.com/apple/swift-lldb/pull/1693">a pull request</a>
that fixes a bug by simply removing code!</p>
<p><a href="https://twitter.com/owenvoorhees">Owen Voorhees</a> opened <a href="https://github.com/apple/swift/pull/25510">a pull request</a>
fully qualifies names for types with the same name in either different modules,
or different scopes. The diagnostic would be really confusing, and this change
improves that.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/25615">a pull request</a>
cleaning up the implementation of lazy property’s underlying storage.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-wrappers.md">SE-0258</a>: <em>Property Wrappers</em> is <a href="https://forums.swift.org/t/se-0258-property-wrappers-second-review/25843">under a second review</a>.</p>
<blockquote>
<p>Doug Gregor has provided the following list of differences from the previous
revision:</p>
<ul>
<li>The name of the feature has been changed from “property delegates” to
“property wrappers” to better communicate how they work and avoid the existing
uses of the term “delegate” in the Apple developer community</li>
<li>When a property wrapper type has a no-parameter <code class="language-plaintext highlighter-rouge">init()</code>, properties that
use that wrapper type will be implicitly initialized via <code class="language-plaintext highlighter-rouge">init()</code>.</li>
<li>Support for property wrapper composition has been added, using a “nesting”
model.</li>
<li>A property with a wrapper can no longer have an explicit get or set
declared, to match with the behavior of existing, similar features (<code class="language-plaintext highlighter-rouge">lazy</code>,
<code class="language-plaintext highlighter-rouge">@NSCopying</code>).</li>
<li>A property with a wrapper does not need to be <code class="language-plaintext highlighter-rouge">final</code>.</li>
<li>Reduced the visibility of the synthesized storage property to <code class="language-plaintext highlighter-rouge">private</code>.</li>
<li>When a wrapper type provides <code class="language-plaintext highlighter-rouge">wrapperValue</code>, the (computed) <code class="language-plaintext highlighter-rouge">$</code> variable is
internal (at most) and the backing storage variable gets the prefix <code class="language-plaintext highlighter-rouge">$$</code> (and
remains <code class="language-plaintext highlighter-rouge">private</code>).</li>
<li>Removed the restriction banning property wrappers from having names that
match the regular expression <code class="language-plaintext highlighter-rouge">_*[a-z].*</code>.</li>
<li><code class="language-plaintext highlighter-rouge">Codable</code>, <code class="language-plaintext highlighter-rouge">Hashable</code>, and <code class="language-plaintext highlighter-rouge">Equatable</code> synthesis are now based on the
backing storage properties, which is a simpler model that gives more control to
the authors of property wrapper types.</li>
<li>Improved type inference for property wrapper types and clarified that the
type of the wrappedValue property is used as part of this inference. See the
“Type inference” section.</li>
<li>Renamed the value property to <code class="language-plaintext highlighter-rouge">wrappedValue</code> to avoid conflicts.</li>
<li>Initial values and explicitly-specified initializer arguments can both be
used together; see the <code class="language-plaintext highlighter-rouge">@Clamping</code> example.</li>
</ul>
</blockquote>
<p>An amendment for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0240-ordered-collection-diffing.md">SE-0240</a>: <em>Ordered Collection Diffing</em> is <a href="https://forums.swift.org/t/amendment-se-0240-ordered-collection-diffing/26084">under review</a>.</p>
<blockquote>
<p>This amendment is to add a new method, <code class="language-plaintext highlighter-rouge">inverse()</code>, to the
<code class="language-plaintext highlighter-rouge">CollectionDifference</code> type.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="">Michael Gottesman</a> shared <a href="https://forums.swift.org/t/what-does-swift-support-in-cmake-mean-for-swifts-build/24828/14">what Swift support in CMake means for Swift’s build</a>.</p>
<blockquote>
<p>I was thinking about this a little bit and I actually think that there are
two additional motivating actions here we are not considering:</p>
<ol>
<li>
<p>We could use this to break the dependency of Swift based tools (e.x.
swift-syntax) that Swift’s CMake builds on building the standard library.</p>
</li>
<li>
<p>CMake for free will let us integrate Swift code into swiftc itself
trivially.</p>
</li>
</ol>
</blockquote>
<p>You can read the full overview <a href="https://forums.swift.org/t/what-does-swift-support-in-cmake-mean-for-swifts-build/24828/14">here</a>.</p>
<p><a href="">Ankit Aggarwal</a> shared <a href="https://forums.swift.org/t/test-discovery-on-linux/26203">that he has been working on test discovery on Linux</a>.</p>
<blockquote>
<p>I’ve been slowly <a href="https://github.com/apple/swift-package-manager/pull/2174">working</a>
on test discovery for Linux and I think the implementation is in a reasonable
state now. I’ve tested it on some OSS Swift packages but it would be great if
others can try it out and report any issues they run into. It can be enabled by
passing the <code class="language-plaintext highlighter-rouge">--enable-test-discovery</code> flag to the swift test invocation.</p>
</blockquote>
<p><a href="https://twitter.com/alfa">Ian Partridge</a> shared <a href="https://forums.swift.org/t/june-12th-2019/26023">meeting notes</a>
for the June 12th Swift Server Working Group meeting.</p>
<blockquote>
<p>Docker: Mishal joined to discuss publishing nightlies to Docker Hub. Happy to
scope out doing this - it would involve some infra work from Apple but in
principle happy to do this. We would prioritise Swift 5.1 convergence nightlies,
add <code class="language-plaintext highlighter-rouge">master</code> afterwards. Would prioritise having the latest build available,
historical builds can come later. Just full images, not slim.</p>
<p>Ubuntu 14.04 update: there are still users although usage is believed to be
low. Mishal will check the stats. When we switch it off, we’ll start with
<code class="language-plaintext highlighter-rouge">master</code>.</p>
<p>Naming collisions: Johannes explained the current status, post discussions
around WWDC. There are a number of separate but related problems.</p>
</blockquote>
<p><a href="https://twitter.com/artemredkin">Artem Redkin</a> created <a href="https://forums.swift.org/t/feedback-nio-based-http-client/26149">a proposal</a>
for an HTTP Client Library.</p>
<blockquote>
<p>There are a number of projects implemented their own HTTP client libraries.
This shows that there is a need for generic, multi-purpose, non-blocking,
asynchronous HTTP client library built on top of SwiftNIO. The Swift Server
Working Group aims to provide a number of packages that could be shared between
different projects, and I think the proposed HTTP client library would be a
good fit for those projects and other use-cases.</p>
<p>Having one, community-driven project that can be shared between different
projects will hopefully solve the need to implement this functionality in every
project from scratch.</p>
</blockquote>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> opened a discussion <a href="https://forums.swift.org/t/additions-to-proposal-process-to-document-feature-syntax-use-and-error-warning-scenarios/26037">to document
feature/syntax use and error/warning scenarios for proposals</a>.</p>
<blockquote>
<p>Since we already have ABI, API resilience and Source Compatibility sections
in the proposal template I think it might make sense to expand on that and make
sure that proposal is considering not only correct
syntax/use, but also accounts for (even if basic) scenarios when new
feature/syntax is used incorrectly or in an (temporary) unsupported way.</p>
<p>I think it would make sense for proposals to state explicitly, in a separate
section, what is supported and what is not (listing possibilities for future
improvements), what is the possible initial set of diagnostic messages and some
basic error/warning scenarios as well as what are the ways current feature might
interact with other features already implemented in the language.</p>
<p>New attributes/keywords could be a good example - it would be very helpful to
list contexts where new attribute/keyword could be used and what error message
should be used for the rest. What are the special cases and areas of the future
improvement e.g. currently could only be used on functions but later support
could be expanded to properties and subscripts. How does new attribute/keyword
interact with existing ones e.g. <code class="language-plaintext highlighter-rouge">@autoclosure</code> vs. <code class="language-plaintext highlighter-rouge">@escaping</code> or
<code class="language-plaintext highlighter-rouge">@autoclosure</code> vs. <code class="language-plaintext highlighter-rouge">inout</code>.</p>
<p>I think having documentation like that in the proposal would make
implementation as well as code review much easier, and would be generally
helpful for posterity.</p>
</blockquote>
<p><a href="https://twitter.com/anandabits">Matthew Johnson</a> pitched <a href="https://forums.swift.org/t/move-swiftuis-identifiable-protocol-and-related-types-into-the-standard-library/25713">a proposal</a>
to move SwiftUI’s <code class="language-plaintext highlighter-rouge">Identifiable</code> protocol and related types to the standard
library.</p>
<blockquote>
<p>Swift UI introduces an <code class="language-plaintext highlighter-rouge">Identifiable</code> protocol as well as the related
<code class="language-plaintext highlighter-rouge">IdentifierValuePair</code> and <code class="language-plaintext highlighter-rouge">IdentifierValuePairs</code> types and the <code class="language-plaintext highlighter-rouge">identified(by:)</code>
method.</p>
<p>I believe that <code class="language-plaintext highlighter-rouge">Identifiable</code> is a “currency” protocol with relevance to an
extremely broad range of Swift code and should therefore be moved into the
standard library along with the related types and method. These will be useful
to any generic code that works with values that represent a snapshot of the
state of an entity.</p>
</blockquote>
<p><a href="">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/partial-nightlies-for-android-sdk/25909">there will be nightly builds</a>
for the Android SDK.</p>
<blockquote>
<p>I’ve been working on getting nightlies of the Android SDK - the Swift
standard library, libdispatch (and swift SDK overlay), as well as libxml2 and
curl. Foundation is something which will take a bit more work, but is easily
added. These are not exactly perfect, but should get you fairly up-to-date
builds of the Swift standard library and libdispatch for the moment.</p>
<p>All of these builds are being done on Windows, but the generated artifacts
are consumable on other targets as well (i.e. you can use this with an
up-to-date toolchain on Windows, Linux, or Darwin). They currently target
Android API level 21.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1141067402387439616">No more 🤖 calls</a>.</p>
Issue #136
https://swiftweeklybrief.com/issue-136
2019-06-13T00:00:00-07:00
2019-06-13T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>So that was quite the week, wasn’t it? So many interesting things announced at
WWDC. Although there were no groundbreaking announcements regarding Swift 6 or
the open source projects, but with SwiftUI, iPadOS, <del>Marzipan</del> Catalyst, and
more, the one word to sum up WWDC for me was
<a href="https://twitter.com/basthomas/status/1137284397617623040">overwhelming</a>. In
a good way, though!</p>
<p>Looking forward to the amazing things we’ll all get to do with these
announcements next. And if we’re lucky, we might even get to see some of the
tools in open source and/or on other platforms… Here’s hoping.</p>
<p>With all of that happening, it has been relatively (read: very) quiet when it
comes to proposals, although a few updates to proposals related to the new
announcements are underway, so expect updates in two weeks!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://semaphoreci.com/product/ios?utm_source=swiftweeklybrief&utm_medium=sponsor&utm_campaign=ios_20190613" target="_blank">Forget slow iOS builds</a></h4>
<p>Semaphore is now the fastest way to test and deploy iOS apps. Powerful CI/CD pipelines run 42% faster comparing to Travis and auto-scale to every git push. You pay only for what you use. Sign up free with GitHub and give it a try today.</p>
<p><small><a href="https://semaphoreci.com/product/ios?utm_source=swiftweeklybrief&utm_medium=sponsor&utm_campaign=ios_20190613" target="_blank">semaphoreci.com</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p>In the latest episode of Swift Unwrapped, Jesse and JP talk
<a href="https://spec.fm/podcasts/swift-unwrapped/299640">about</a> Swift Build Systems
with <a href="https://twitter.com/smileykeith">Keith Smiley</a>.</p>
<p>In the latest episode of the Swift Community Podcast,
<a href="https://twitter.com/AndrewLitteken">Andrew Litteken</a>,
<a href="https://twitter.com/clattner_llvm">Chris Lattner</a>,
and <a href="https://twitter.com/suyashsrijan">Suyash Srijan</a>
an <a href="https://www.swiftcommunitypodcast.org/episodes/5">introduction</a> to
contributing to the Swift Compiler.</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple introduced a new framework,
<a href="https://developer.apple.com/xcode/swiftui/">SwiftUI</a>, that brings a declarative
user interface builder to all Apple platforms. Now to wait for them to open
source it! 🤞</p>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> wrote
<a href="https://medium.com/@suyash.srijan/intro-to-swiftui-part-1-47361a3ffb2e">an article</a>
on the language features of Swift that power SwiftUI.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> pitched
<a href="https://forums.swift.org/t/pitch-function-builders/25167">a proposal</a> for
Function Builders.</p>
<blockquote>
<p>It’s always been a goal of Swift to support declarative programming, and the
language can be quite good for it, but some kinds of “declaration” fit better
into the current language than others. In particular, heterogeneous trees with
a lot of hard-coded structure — such as JSON, HTML, and view hierarchies —
often feel a bit awkward to express using the ordinary tools of the language.
I think we can do better than that, and so I’m proposing a feature to enable a
new class of embedded DSL in Swift.</p>
</blockquote>
<p>You can read the draft proposal
<a href="https://github.com/rjmccall/swift-evolution/blob/function-builders/proposals/XXXX-function-builders.md">here</a>.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> also shared
<a href="https://forums.swift.org/t/important-evolution-discussion-of-the-new-dsl-feature-behind-swiftui/25168">an update</a>
on the pitch above.</p>
<blockquote>
<p>Those of you watching Apple’s WWDC keynote today and introduction of SwiftUI
likely observed a new enhancement to the Swift language in the form a Domain
Specific Language
(<a href="https://en.wikipedia.org/wiki/Domain-specific_language">DSL</a>) that could be
used to build a UI in code.</p>
<p>This is a feature that has not been discussed on Swift evolution. The work on
that feature has been very iterative with lots of experimentation. Those of us
involved in that work wanted to make sure we had a design we were happy with
before taking it back for discussion with the community. Further, while the
feature is general purpose, adding it to Swift is easier to motivate and
discuss the details with a compelling and concrete use case like SwiftUI.</p>
<p>Speaking on behalf of the Core Team, here are the next steps to discuss and
review the feature:</p>
<ul>
<li>The Core Team would like to run a formal review of the feature soon.</li>
<li>Before that review, we’d like to use the pitch thread for general
discussion and questions about the feature.</li>
</ul>
<p>While Apple has embraced the approach as part of SwiftUI, the evolution
review is intended to have a real and tangible impact on the shape of the
feature itself.</p>
</blockquote>
<p><a href="https://twitter.com/Mordil">Nathan Harris</a> shared
<a href="https://forums.swift.org/t/feedback-redisnio-a-nio-based-redis-driver/25521">a proposal</a>
for a NIO-based Redis Driver.</p>
<blockquote>
<p><strong>RedisNIO</strong> is a module providing general implementations for connecting to
a Redis instance and executing commands against it using Redis’ proprietary
<a href="https://redis.io/topics/protocol"><strong>Re</strong>dis <strong>S</strong>eralization <strong>P</strong>rotocol (RESP)</a>.</p>
<p>These types are designed to work in a request / response loop, representing
individual connections to Redis.</p>
<p>The goal of this library is to provide individual building blocks for working
with Redis, while still providing enough mechanisms “out of the box” so users
can get started immediately with Redis.</p>
</blockquote>
<p>You can read the full proposal
<a href="https://github.com/swift-server/sswg/blob/master/proposals/0004-nio-redis.md">here</a>.</p>
<h3 id="finally">Finally</h3>
<p>A <a href="https://twitter.com/UINT_MIN/status/1134479584571736065">sequel</a> to the
previous “finally”, and some Shakespeare
<a href="https://twitter.com/jckarter/status/1134556191583920128">words to live by</a>.</p>
Issue #135
https://swiftweeklybrief.com/issue-135
2019-05-30T00:00:00-07:00
2019-05-30T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>T-4 days for WWDC 2019! Oh yes, if somehow you missed that, it will start
after the weekend. Looking forward to everything that’s new, including potential
news about the future of Swift… fingers crossed!</p>
<p>For those that are attending, have an awesome time! <em>And</em> also make sure to say
hello to <a href="https://twitter.com/fassko">Kristaps</a>… he might have Swift Weekly
Brief <a href="https://twitter.com/swiftlybrief/status/1133353935895445504">stickers</a>
to give out. Make sure to share pictures of where you put those :-)</p>
<p>Also, and I missed to include this two weeks ago,
<a href="https://twitter.com/pathofshrines">John McCall</a> shared
<a href="https://forums.swift.org/t/returned-for-revision-se-0258-property-delegates/24080">something I wanted to point out</a>
to all of you reading, and in particular, those directly involved with the Swift
evolution process:</p>
<blockquote>
<p>I’d like to thank the community for its patience and its commitment. I know
we’ve had a lot of proposals recently, and some of them have been contentious,
and it can be a lot of work to keep up with Swift Evolution. You really are
appreciated; thank you for everything you do to help make Swift a better
language.</p>
</blockquote>
<p>Well said.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.eventbrite.com/e/swiftfest-2019-tickets-56501408233?discount=Swift-Weekly-50-Off?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_135" target="_blank">SwiftFest Boston 2019, join the Swift re-evolution</a></h4>
<p>SwiftFest Boston - July, 29th-30th, get today your discounted ticket ($50 off) using the code <strong>Swift-Weekly-50-Off</strong>. <br /><br />SwiftFest is the most community-driven conferences focused on Swift that brings together engineers, architects, midnight-coders, and students in a highly social and vibrant environment. <br /><br /> Topics: Swift and iOS, server-side Swift, architecture, augmented and virtual reality, open source, hardware projects, platforms, development-culture, security, TDD, etc.</p>
<p><small><a href="https://www.eventbrite.com/e/swiftfest-2019-tickets-56501408233?discount=Swift-Weekly-50-Off?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_135" target="_blank">swiftfest.io</a></small></p>
</div>
<h3 id="starter-task">Starter task</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/TF-449">TF-449</a> [Standard Library]
Conditionally conform <code class="language-plaintext highlighter-rouge">Optional</code> to <code class="language-plaintext highlighter-rouge">Differentiable</code></li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/lmoroney">Laurence Moroney</a> and <a href="https://twitter.com/clattner_llvm">Chris Lattner</a>
talked <a href="https://www.youtube.com/watch?v=z5M4otA4S3A">about how Swift has grown beyond mobile development</a>.</p>
<p><a href="https://twitter.com/wlisac">Will Lisac</a> open sourced <a href="https://github.com/wlisac/swift-on-balena">a set of Docker images</a>
for Swift on Raspberry Pi and other ARM devices.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> merged <a href="https://github.com/apple/swift/pull/25030">a pull request</a>
using the runtime hook mechanism to backward deploy <a href="https://bugs.swift.org/browse/SR-10600">a bug fix</a>.</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> merged <a href="https://github.com/apple/swift/pull/24929">a pull request</a>
allowing Swift’s optimizer to constant fold key path accesses down into direct
field accesses!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0260-library-evolution.md">SE-0260</a>: <em>Library Evolution for Stable ABIs</em> was <a href="https://forums.swift.org/t/accepted-se-0260-library-evolution-for-stable-abis/24845">accepted</a>.</p>
<blockquote>
<p>Stable library evolution has been a goal of the Swift project since its
earliest days. SE-0260 builds on years of design and implementation effort,
and it is as much an announcement of the success of that work as it is a
proposal to change the language. Most of the formal content of the proposal is
carved deep into the bones of the language; it could not be made any other way
without grave consequences. All of this is to say that the basic outcome of
this review is at least a little preordained.</p>
<p>Still, there are details that are worth debating. There were two basic
categories of discussion in the review:</p>
<ul>
<li>
<p>Several reviewers provided concrete feedback on specific aspects of the
new attributes and compilation modes proposed by SE-0260. On balance, the Core
Team is satisfied with the language rules and names as proposed.</p>
</li>
<li>
<p>There was quite a lot of debate about the exact process of developing and
evolving stable libraries and the exact guarantees that Swift is making here.
While SE-0260 lays out the most basic rules for stable libraries, there are
many details like these that remain unsettled and which may have significant
consequences for the evolution of the implementation. The Core Team feels that
these details can be worked out in later proposals, and that any limitations on
the implementation will provide adequate incentive to ensure that they are.</p>
</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md">SE-0253</a>: <em>Callable values of user-defined nominal types</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0253-callable-values-of-user-defined-nominal-types/24605">accepted with modification</a>.</p>
<blockquote>
<p>[..] the core team decided to accept the proposal, with the request to change
<code class="language-plaintext highlighter-rouge">func call()</code> syntax to <code class="language-plaintext highlighter-rouge">func callFunction()</code>. The core team chose this
direction because it retains the ‘call’ nomenclature established by
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md">SE-0216</a>,
but is a more verbose name that is less likely to already exist, or be
accidentally used for an unrelated purpose.</p>
</blockquote>
<p>After more feedback from the community, it was then <a href="https://forums.swift.org/t/accepted-with-modification-se-0253-callable-values-of-user-defined-nominal-types/24605/166">further revised</a>.</p>
<blockquote>
<p>The Core Team discussed this and has decided to <strong>further revise the
proposal</strong> to name the operator function <code class="language-plaintext highlighter-rouge">func callAsFunction()</code>. We are
comfortable with enabling this functionality purely based on nothing more than
the name of a function, and we are not persuaded that <code class="language-plaintext highlighter-rouge">init</code> and <code class="language-plaintext highlighter-rouge">subscript</code>
(which both have substantially different semantic and syntactic rules and are
not simply functions) provide important precedents here requiring a new
declaration introducer.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/palimondo">Pavol Vaskovic</a> shared <a href="https://forums.swift.org/t/towards-robust-performance-measurement/11490/26">an update on benchmark performance</a>.</p>
<blockquote>
<p>I’m happy to announce that by the beginning of March 2018, <a href="https://github.com/pulls?utf8=✓&q=is%3Amerged+is%3Apr+author%3Apalimondo+Janitor">a series of pull
requests</a>
that applied <strong>legacy factor</strong> across the whole Swift Benchmark Suite (SBS) has
lowered the workloads of individual benchmarks to execute in the 20–1000 μs
range. My thanks go to <a href="https://github.com/eeckstein">Erik Eckstein</a> for his
patient review and guidance.</p>
<p>Point of this modification was to strengthen the resilience of our measurement
process against accumulated errors caused by context switches that happen every
10 ms on macOS.</p>
</blockquote>
<p><a href="https://twitter.com/Dale_Buckley">Dale Buckley</a> pitched <a href="https://forums.swift.org/t/pre-pitch-removeall-at/24820">a proposal</a>
that introduces a <code class="language-plaintext highlighter-rouge">removeAll(at:)</code> function.</p>
<blockquote>
<p>When dealing with collections of data, there are often times where it is
required to remove multiple elements from a collection at different indices
within the same operation. There are some common mistakes that can lead to
unperformant and buggy code when presented with this task. This proposal intends
to provide a simplified method to perform this operation in a safe and
performant way.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> shared <a href="https://forums.swift.org/t/pitch-3-property-wrappers-formerly-known-as-property-delegates/24961">a revised pitch</a>
for property wrappers.</p>
<blockquote>
<p>I’ve revised the property delegates proposal again, albeit under a more
descriptive name <a href="https://github.com/DougGregor/swift-evolution/blob/property-wrappers/proposals/0258-property-wrappers.md">“property wrappers”</a>.</p>
<ul>
<li>
<p>The name of the feature has been changed from “property delegates” to
“property wrappers” to better communicate how they work and avoid the existing
uses of the term “delegate” in the Apple developer community</p>
</li>
<li>
<p>When a property wrapper type has a no-parameter <code class="language-plaintext highlighter-rouge">init()</code>, properties that
use that wrapper type will be implicitly initialized via <code class="language-plaintext highlighter-rouge">init()</code>.</p>
</li>
<li>
<p>Support for property wrapper composition has been added, using a “nesting”
model.</p>
</li>
<li>
<p>A property with a wrapper can no longer have an explicit get or set
declared, to match with the behavior of existing, similar features
(<code class="language-plaintext highlighter-rouge">lazy</code>, <code class="language-plaintext highlighter-rouge">@NSCopying</code>).</p>
</li>
<li>
<p>A property with a wrapper does not need to be <code class="language-plaintext highlighter-rouge">final</code>.</p>
</li>
<li>
<p>Reduced the visibility of the synthesized storage property to <code class="language-plaintext highlighter-rouge">private</code>,
and expanded upon potential future directions to making it more visible.</p>
</li>
<li>
<p>Removed the restriction banning property wrappers from having names that
match the regular expression <code class="language-plaintext highlighter-rouge">_*[a-z].*.</code></p>
</li>
<li>
<p><code class="language-plaintext highlighter-rouge">Codable</code>, <code class="language-plaintext highlighter-rouge">Hashable</code>, and <code class="language-plaintext highlighter-rouge">Equatable</code> synthesis are now based on the
backing storage properties, which is a simpler model that gives more control
to the authors of property wrapper types.</p>
</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> announced <a href="https://forums.swift.org/t/announcing-swift-support-in-cmake/24792/1">Swift support in CMake</a>!</p>
<blockquote>
<p>I have been working with upstream to integrate Swift support into CMake with
the Ninja generator so that it can be integrated into existing projects much
more conveniently. I would like to announce that the last of the initial set of
changes needed to support Swift in CMake have been merged now into CMake and I
expect that the next major release of CMake (3.15) to include the Swift support.</p>
</blockquote>
<p>… as well as <a href="https://forums.swift.org/t/comming-soon-to-a-terminal-near-you-swift-repl-on-windows/24917">Swift REPL on Windows</a>!</p>
<blockquote>
<p>I have gotten the REPL to the point where it now runs on Windows! There are
some improvements to be made still, primarily in the application of Data
Formatters. However, the expression evaluation appears to work now and overall.
If there are people who would like to get involved in the Windows port on the
lldb side - this provides an excellent opportunity to delve into lldb. It also
can expand easily into the compiler side if you start looking at the AST side
of things.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/harlanhaskins/status/1133210047952015360/photo/1">The real “Objective-C without the C”</a> 🦕</p>
Issue #134
https://swiftweeklybrief.com/issue-134
2019-05-16T00:00:00-07:00
2019-05-16T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>With WWDC coming up in just two and a half weeks time, there is still a lot
going on when it comes to Swift.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://try.instabug.com/swift-weekly?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_134" target="_blank">The Most Comprehensive Bug Reporting SDK for iOS Apps</a></h4>
<p>The top mobile companies like Lyft, Reddit, and EA Games rely on Instabug to iterate faster and enhance their app quality. Instabug lightweight SDK allows developers to receive detailed bug reports directly from testers and users. Instabug attaches screenshots, screen recordings, device details and repro-steps with each report. Try Instabug now - You just need one minute to integrate the SDK! Use the discount-code <strong>InstabugLovesSwiftWeekly</strong> and get a 20% discount for 3 months on all plans!</p>
<p><small><a href="https://try.instabug.com/swift-weekly?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_134" target="_blank">try.instabug.com/swift-weekly</a></small></p>
</div>
<h3 id="podcasts">Podcasts</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/295535">discuss</a>
“Removing Things From Swift”, talking about implicit returns and eliding commas.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/zhuowei">Zhuowei Zhang</a> and <a href="https://twitter.com/MaxDesiatov">Max Desiatov</a>
worked on <a href="https://swiftwasm.org">initial support for compiling Swift to WebAssembly</a>. 😱</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/rajbarik">Raj Barik</a> merged <a href="https://github.com/apple/swift/pull/19820">a pull request</a>
with an entire optimizer pass to convert existentials to generic parameters,
creating new opportunities for unboxing and devirtualization.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-delegates.md">SE-0258</a>: <em>Property Delegates</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0258-property-delegates/24080">returned for revision</a>.</p>
<blockquote>
<p>There was a lot of great discussion in this review, leading to some very
useful feedback for the Core Team and the proposal authors. That feedback can
be broken down into two categories: (1) procedural feedback about the state of
the proposal and its review and (2) technical feedback about the actual
proposal. Both are useful, and we’ll consider each in turn.</p>
</blockquote>
<p>You can read <a href="https://forums.swift.org/t/returned-for-revision-se-0258-property-delegates/24080">the full post</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0260-library-evolution.md">SE-0260</a>: <em>Library Evolution for Stable ABIs</em> is <a href="https://forums.swift.org/t/se-0260-library-evolution/24260/1">under review</a>.</p>
<blockquote>
<p>One of Swift’s goals is to be a good language for libraries with binary
compatibility concerns, such as those shipped as part of Apple’s OSs. This
includes giving library authors the flexibility to add to their public
interface, and to change implementation details, without breaking binary
compatibility. At the same time, it’s important that library authors be able to
opt out of this flexibility in favor of performance.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md">SE-0253</a>: <em>Callable values of user-defined nominal types</em> is <a href="https://forums.swift.org/t/se-0253-callable-values-of-user-defined-nominal-types/24177">under review</a>.</p>
<blockquote>
<p>This proposal introduces “statically”
<a href="https://en.wikipedia.org/wiki/Callable_object">callable</a> values to Swift.
Callable values are values that define function-like behavior and can be called
using function call syntax. In contrast to dynamically callable values
introduced in
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md">SE-0216</a>,
this feature supports statically declared arities, argument labels, and
parameter types, and is not constrained to primary type declarations.</p>
<p>In a nutshell, values that have a method whose base name is <code class="language-plaintext highlighter-rouge">call</code> (referred to
as a “<code class="language-plaintext highlighter-rouge">call</code> method” for the rest of this proposal) can be called like a
function. The function call syntax forwards arguments to the corresponding
<code class="language-plaintext highlighter-rouge">call</code> method.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">struct</span> <span class="kt">Adder</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">base</span><span class="p">:</span> <span class="kt">Int</span>
<span class="kd">func</span> <span class="nf">call</span><span class="p">(</span><span class="n">_</span> <span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">base</span> <span class="o">+</span> <span class="n">x</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="k">let</span> <span class="nv">add3</span> <span class="o">=</span> <span class="kt">Adder</span><span class="p">(</span><span class="nv">base</span><span class="p">:</span> <span class="mi">3</span><span class="p">)</span>
<span class="nf">add3</span><span class="p">(</span><span class="mi">10</span><span class="p">)</span> <span class="c1">// => 13</span></code></pre></figure>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/ilseman/">Michael Ilseman</a> shared <a href="https://forums.swift.org/t/omitting-returns-in-string-case-study-of-se-0255/24283">a case study</a> omitting <code class="language-plaintext highlighter-rouge">return</code>s in <code class="language-plaintext highlighter-rouge">String</code>.</p>
<blockquote>
<p>I’m a fan of <a href="https://twitter.com/neightchan">Nate Chandler</a>’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md">SE-0255</a> which allows us to omit the <code class="language-plaintext highlighter-rouge">return</code>
keyword in a single-expression function or computed variables. Here is a case
study of SE-0255 as applied to <code class="language-plaintext highlighter-rouge">String</code>’s internal implementation.</p>
</blockquote>
<p><a href="https://github.com/dingobye">Ding Ye</a> pitched <a href="https://forums.swift.org/t/adding-ispowerof2-to-binaryinteger/24087">a proposal</a> to add <code class="language-plaintext highlighter-rouge">isPowerOf2</code> to <code class="language-plaintext highlighter-rouge">BinaryInteger</code>.</p>
<blockquote>
<p>Checking some mathematical properties of integers (e.g., parity,
divisibility, etc.) is widely used in scientific and engineering applications.
While Swift’s standard library provides a convenient method <code class="language-plaintext highlighter-rouge">isMultiple(of:)</code> to
test whether an integer is a multiple of another, there are other cases that
are not yet supported. A frequently used one is to check if an integer is power
of two. This pitch would like to address this problem by adding a computed
property <code class="language-plaintext highlighter-rouge">isPowerOf2</code> to the <code class="language-plaintext highlighter-rouge">BinaryInteger</code> protocol.</p>
</blockquote>
<p><a href="https://twitter.com/GLDeveloper">Giuseppe Lanza</a> pitched <a href="https://forums.swift.org/t/pitch-stdlib-making-sorting-algorithm-choosable/24100">a proposal</a> to make sorting
algorithms selectable.</p>
<blockquote>
<p>It’s currently unclear without peeking under the hood of swift implementation
is the algorithm used for sorting, changes to this algorithm (recently it
passed from introsort to timsort) and performances tradeoffs.</p>
<p>Different sorting algorithms might be preferred depending on the problem
that needs to be solved. In certain cases it’s important to know that the
sorting is stable, in other cases might be important to be sure that the
algorithm is in place.</p>
</blockquote>
<p><a href="https://twitter.com/igorkulman">Igor Kulman</a> pitched <a href="https://forums.swift.org/t/pitch-method-to-sum-numeric-arrays/24170">a proposal</a> to add a <code class="language-plaintext highlighter-rouge">sum</code>-method to numeric arrays.</p>
<blockquote>
<p>I currently sum the arrays using <code class="language-plaintext highlighter-rouge">.reduce(0,+)</code> which I do not mind by the code
is not that readable</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">total</span> <span class="o">=</span> <span class="n">expenses</span><span class="o">.</span><span class="nf">map</span><span class="p">({</span> <span class="nv">$0</span><span class="o">.</span><span class="n">amount</span> <span class="p">})</span><span class="o">.</span><span class="nf">reduce</span><span class="p">(</span><span class="mi">0</span><span class="p">,</span><span class="o">+</span><span class="p">)</span></code></pre></figure>
<blockquote>
<p>Another bigger problem than readability is that I encounter code like this
from other developers all the time:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">var</span> <span class="nv">sum</span> <span class="o">=</span> <span class="mi">0</span>
<span class="k">for</span> <span class="n">expense</span> <span class="k">in</span> <span class="n">expenses</span> <span class="p">{</span>
<span class="n">sum</span> <span class="o">=</span> <span class="n">sum</span> <span class="o">+</span> <span class="n">expense</span><span class="o">.</span><span class="n">amount</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>This code might come from imperative thinking but it might also come from
not knowing how to use <code class="language-plaintext highlighter-rouge">.reduce()</code> which can look like an intimidating method.
A <code class="language-plaintext highlighter-rouge">.sum()</code> would be friendlier and much easier to use even to inexperienced
developers.</p>
</blockquote>
<p><a href="https://twitter.com/pxheller">Philipp Heller</a> pitched <a href="https://forums.swift.org/t/pitch-protocol-conformance-for-tuples-anonymous-structs/24207">a proposal</a> to allow Protocol Conformance for Tuples and Anonymous Structs.</p>
<blockquote>
<p>Currently, if you wish to pass some data to a function that requires the
data to conform to a specific protocol, you have to define some type that
conforms to the protocol and create an object with that type afterward.</p>
<p>Right now tuples cannot be used as literals to construct structs. Assume
there is a function <code class="language-plaintext highlighter-rouge">prettyPrintAsJson(data: Encodable)</code> that you only need to
call once in your code. You would define a <code class="language-plaintext highlighter-rouge">struct</code> (or <code class="language-plaintext highlighter-rouge">class</code>) first and
create an instance of that type afterward.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/johannesweiss/status/1126254936801591296">Still going 💪</a>
(puns are the best)</p>
Issue #133
https://swiftweeklybrief.com/issue-133
2019-05-02T00:00:00-07:00
2019-05-02T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I hope all of you had a wonderful last two weeks! I wanted to share that I
recently <a href="https://twitter.com/BasThomas/status/1121102492958433281">tweeted</a>
reaching out to people to talk about iOS, careers and more. And it has been
a really rewarding experience! It is quite different from a newsletter like
the Swift Weekly Brief, but it is great to get to interact with the Swift
community like this!</p>
<p>And with that I wish all of you another two good weeks. Until the next issue :)</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/TF-447">TF-447</a> [Standard Library] Improve TensorShape printing</li>
<li><a href="https://bugs.swift.org/browse/TF-448">TF-448</a> [Standard Library] Improve Tensor type documentation</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>On the Swift by Sundell podcast, <a href="https://twitter.com/johnsundell">John Sundell</a> and <a href="https://twitter.com/ilseman/">Michael Ilseman</a> discuss <a href="https://www.swiftbysundell.com/podcast/46">String, its implementation, and its related APIs</a>.</p>
<p>On the Swift Community Podcast, <a href="https://twitter.com/mdiasdev">Matt Dias</a>, <a href="https://twitter.com/barbieinbeta">Barbie Vanaiki</a>, <a href="https://twitter.com/johnsundell">John Sundell</a>, and I discuss <a href="https://www.swiftcommunitypodcast.org/episodes/4">the state of the Swift community</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> shared <a href="https://twitter.com/slava_pestov/status/1123025223522164742">a thread</a> on insights building a compiler, touching on how to make it performant by designing it in a way where not everything has to happen sequentially.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/_torust">Thomas Roughton</a> merged <a href="https://github.com/apple/swift/pull/24198">a pull request</a> introducing <code class="language-plaintext highlighter-rouge">String</code> to <code class="language-plaintext highlighter-rouge">Float</code> performance improvements and benchmarks.</p>
<p><a href="https://twitter.com/gottesmang">Michael Gottesman</a> merged <a href="https://github.com/apple/swift/pull/24314">a pull request</a> introducing stronger compile-time checking of ownership in the Swift Intermediate Language (SIL), also allowing an improved Auto Reference Counting (ARC) optimizer.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md">SE-0255</a>: <em>Implicit returns from single-expression functions</em> was <a href="https://forums.swift.org/t/accepted-se-0255-implicit-returns-from-single-expression-functions/23581/2">accepted</a>.</p>
<blockquote>
<p>The review demonstrated clear support for this syntax for property and subscript getters, where the need to return simple single expressions is common.</p>
<p>On eliding the <code class="language-plaintext highlighter-rouge">return</code> from functions, the review feedback was more divided. While there was support from some reviewers, others expressed the view that the feature should be restricted to just getters. However, on reviewing the feedback, the core team does not see a strong case was made against applying it to functions as well, when weighed against the benefits of a single uniform rule.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0259-approximately-equal.md">SE-0259</a>: <em>Approximate Equality for Floating Point</em> is <a href="https://forums.swift.org/t/se-0259-approximate-equality-for-floating-point/23627">under review</a>.</p>
<blockquote>
<p>The internet is full advice about what not to do when comparing floating-point values:</p>
<ul>
<li>“Never compare floats for equality.”</li>
<li>“Always use an epsilon.”</li>
<li>“Floating-point values are always inexact.”</li>
</ul>
<p>Much of this advice is false, and most of the rest is technically correct but misleading.
Almost none of it provides specific and correct recommendations for what you <em>should</em>
do if you need to compare floating-point numbers.</p>
<p>There is no uniformly correct notion of “approximate equality”, and there is no uniformly
correct tolerance that can be applied without careful analysis, but we can define
approximate equality functions that are better than what most people will come up with
without assistance from the standard library.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/CTMacUser">Daryle Walker</a> wrote <a href="https://forums.swift.org/t/anti-pitch-just-say-no-to-protocols-on-structural-types/24043">an “anti” pitch</a> reasoning about why it might not be a good idea two allow protocol conformance on tuples.</p>
<blockquote>
<p>If you think that slapping a protocol on a tuple is awesome, you’re probably not the only one to come up with it. The problem comes from the fact that tuple type declarations are global (modulo that a scope can access all the components’ types). What happens if you bring in a library that already had the protocol added to a tuple type you wanted to add? What happens if two different libraries do this? Would there be some kind of priority system? Since you can differentiate function overloads with protocol conformance, what if you didn’t want a particular tuple type to have a conformance? There’s no way to remove a conformance.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/alexanderm/summary">Alexander Momchilov</a> shared <a href="https://forums.swift.org/t/adding-more-data-structures-to-the-standard-library/23651">an overview of the state of data structures</a> in Swift.</p>
<blockquote>
<p>We have just <code class="language-plaintext highlighter-rouge">Set</code> (unordered), <code class="language-plaintext highlighter-rouge">Dictionary</code> (unordered), and <code class="language-plaintext highlighter-rouge">Array</code>. No concurrent collections (value types solves most of the issues here, but it doesn’t solve things like the classic produce-consumer, for example), no linked lists, queues, stacks, bimaps, multimaps, or sort ordered collections.</p>
</blockquote>
<p>Be sure to read <a href="https://forums.swift.org/t/adding-more-data-structures-to-the-standard-library/23651">the thread</a> for some insightful discussion on the topic.</p>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> pitched <a href="https://forums.swift.org/t/pitch-offsetting-indices-and-relative-ranges/23837">a proposal</a> for convenience syntax applying an integer offset to an existing index.</p>
<blockquote>
<p>Applying offsets to indices and using relative ranges brings ease of use improvements to all Collections and is a convenient tools for reducing bugs in <code class="language-plaintext highlighter-rouge">Int</code>-indexed Collections. It also makes types like String more approachable in casual contexts, such as for programming puzzles and learning.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Do we have <a href="https://twitter.com/jckarter/status/1120538032166395905">a competitor</a> for Greg’s haikus? 🤔</p>
Issue #132
https://swiftweeklybrief.com/issue-132
2019-04-18T00:00:00-07:00
2019-04-18T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A short but sweet issue this week. Sorry for the cliché — but it’s true!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://mindgrub.bamboohr.com/jobs/view.php?id=94?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_132" target="_blank">iOS Developer</a></h4>
<p>Are you a mobile developer with 4+ years of experience, proficient in Objective-C or Swift and can help develop mobile applications? If so, we are interested in speaking with you! Contact us using the link provided.</p>
<p><small><a href="https://mindgrub.bamboohr.com/jobs/view.php?id=94?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_132" target="_blank">mindgrub.com</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/alfa">Ian Partridge</a> wrote <a href="https://developer.ibm.com/swift/2019/04/17/announcing-kitura-2-7-and-more/">a blog post</a> announcing Kitura 2.7, which
uses SwiftNIO 2.0.</p>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> announced <a href="https://forums.swift.org/t/swift-log-1-0-0/22927">the release of <code class="language-plaintext highlighter-rouge">swift-log</code> 1.0.0</a>. 📝</p>
<p>Apple <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_1_release_notes/">released</a> Xcode 10.2.1.</p>
<p><a href="https://twitter.com/ilseman">Michael Ilseman</a>’s talk at try! Swift Tokyo, <a href="https://www.youtube.com/watch?v=lMhGnTFA9CI&feature=youtu.be">The Philosopher’s String</a>, is now available. 🧙♂️</p>
<p><a href="https://twitter.com/timothyekl">Timothy Ekl</a> wrote <a href="https://www.timekl.com/blog/2019/04/14/swift-generics-evolution/">a blog post</a> to make the topic of the <a href="https://forums.swift.org/t/improving-the-ui-of-generics/22814">future of Generics</a> more accessible.</p>
<p><a href="https://twitter.com/millenomi">Lily Vulcano</a> put together <a href="https://bugs.swift.org/browse/SR-10347">a list</a> of the remaining <code class="language-plaintext highlighter-rouge">NSUnimplemented()</code> bits in <code class="language-plaintext highlighter-rouge">swift-corelibs-foundation</code>. 🎉</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md">SE-0244</a>: <em>Opaque Result Types</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0244-opaque-result-types/22115">returned for revision</a> and later <a href="https://forums.swift.org/t/accepted-se-0244-opaque-result-types/23294">accepted</a>.</p>
<blockquote>
<p>The core team agrees that this proposal lays important groundwork that can be built on further in ways laid out in the author’s <a href="https://forums.swift.org/t/improving-the-ui-of-generics/">Generics UI Improvements overview</a>. This write-up helped clarify the context of the proposal both for reviewers and the core team itself.</p>
<p>Several reviewers felt that being able to name opaque types is an important feature for many use cases. This is clearly a useful feature and would be a good next step, but the core team thinks that the feature as proposed consists of a reasonable “minimum viable product” to land now, and then can be added to through subsequent proposals.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md">SE-0253</a>: <em>Introduce callables</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0253-static-callables/23290">returned for revision</a>.</p>
<blockquote>
<p>The core team is very positive about the idea of this feature, but would like
to see some changes to the proposal, followed by another round of public
review. As such, the proposal is returned for revision.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0256-contiguous-collection.md">SE-0256</a>: <em>Introduce <code class="language-plaintext highlighter-rouge">{Mutable}ContiguousCollection</code> protocol</em> was <a href="https://forums.swift.org/t/se-0256-introduce-mutable-contiguouscollection-protocol/22569/8">rejected</a>.</p>
<blockquote>
<p>The Core Team did not feel the motivation behind the proposal warranted expanding the <code class="language-plaintext highlighter-rouge">Collection</code> protocol hierarchy. The <code class="language-plaintext highlighter-rouge">Collection</code> hierarchy is already quite rich, and any motivation to expanding it in the Standard Library needs to meet a high bar in general utility. At this time the proposed change was deemed too niche to motivate that change.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0258-property-delegates.md">SE-0258</a>: <em>Property Delegates</em> is <a href="https://forums.swift.org/t/se-0258-property-delegates/23139">under review</a>.</p>
<blockquote>
<p>There are property implementation patterns that come up repeatedly. Rather than hardcode a fixed set of patterns into the compiler, we should provide a general “property delegate” mechanism to allow these patterns to be defined as libraries.</p>
<p>This is an alternative approach to some of the problems intended to be addressed by the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">2015-2016 property behaviors proposal</a>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0257-elide-comma.md">SE-0257</a>: <em>Eliding commas from multiline expression lists</em> is <a href="https://forums.swift.org/t/se-0257-eliding-commas-from-multiline-expression-lists/22889">under review</a>.</p>
<blockquote>
<p>Swift requires a semicolon “<code class="language-plaintext highlighter-rouge">;</code>” to separate statements unless those statements are separated by newlines, in which case the semicolon can be elided. Currently, Swift requires a comma “<code class="language-plaintext highlighter-rouge">,</code>” to separate expressions even when those statements are separated by newlines. We should ease this restriction, allowing the comma between two expressions to be elided when they are separated by a newline.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/dhartbit">Daniel Hartbit</a>, <a href="https://twitter.com/vvendra">Vini Vendramini</a>, and <a href="https://twitter.com/dgregor79">Doug Gregor</a> pitched <a href="https://forums.swift.org/t/pitch-static-custom-attributes-round-2/22938">a proposal</a> for custom static attributes.</p>
<blockquote>
<p>Swift currently supports marking declarations with compiler-defined attributes, such as <code class="language-plaintext highlighter-rouge">@objc</code> and <code class="language-plaintext highlighter-rouge">@deprecated</code>. The compiler uses these attributes to customize the way it interprets the corresponding code. As a first step towards opening attributes to users and library authors, this proposal introduces static custom attributes which exist only at compile time, allowing tools that parse Swift code to use them as markers.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>I mean, <a href="https://i.redd.it/l5xkrl38gxs21.jpg">why not?</a></p>
Issue #131
https://swiftweeklybrief.com/issue-131
2019-04-04T00:00:00-07:00
2019-04-04T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A busy two weeks: the long-awaiting Swift 5 was released, alongside Xcode 10.2.
It took a while, but it is awesome to see this great release come to life.</p>
<p>Furthermore, Swift 5.1 is already being worked on, and there are <em>tons</em> of
proposals ongoing, so you can expect a lot more interesting things to come!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/TF-360">TF-360</a> [Tests] Create unit test for <code class="language-plaintext highlighter-rouge">TensorFlow.h:convertSwiftTypeToTF</code></li>
<li><a href="https://bugs.swift.org/browse/TF-416">TF-416</a> [Python interop] Produce error upon second usage of <code class="language-plaintext highlighter-rouge">PythonLibrary.useVersion</code></li>
<li><a href="https://bugs.swift.org/browse/TF-419">TF-419</a> Improve tensor printing</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>In episode 73 of Swift Unwrapped, Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/288713">discuss</a>
<code class="language-plaintext highlighter-rouge">UTF-8</code> Strings in Swift 5.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/ilseman/">Michael Ilseman</a> wrote <a href="https://swift.org/blog/utf8-string/">about <code class="language-plaintext highlighter-rouge">UTF-8</code> <code class="language-plaintext highlighter-rouge">String</code></a>
on the Swift.org blog.</p>
<blockquote>
<p>Swift 5 switches the preferred encoding of strings from <code class="language-plaintext highlighter-rouge">UTF-16</code> to <code class="language-plaintext highlighter-rouge">UTF-8</code>
while preserving efficient Objective-C-interoperability. Because the <code class="language-plaintext highlighter-rouge">String</code>
type abstracts away these low-level concerns, no source-code changes from
developers should be necessary, but it’s worth highlighting some of the
benefits this move gives us now and in the future.</p>
</blockquote>
<p>SwiftNIO 2 <a href="https://forums.swift.org/t/swiftnio-2/22136">has been released</a>!</p>
<p>Swift 5 <a href="https://swift.org/blog/swift-5-released/">has been released</a>! You can
find the release notes <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_release_notes/swift_5_release_notes_for_xcode_10_2">here</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/nathawes">Nathan Hawes</a> merged <a href="https://github.com/apple/swift/pull/23448">a pull request</a>
to fix variable renaming in switches.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/23734">a pull request</a>
that adds support for default arguments on subscripts. 🎉</p>
<p><a href="https://twitter.com/benlangmuir">Ben Langmuir</a> merged <a href="https://github.com/apple/swift/pull/23674">a pull request</a>
that fixes an infinite looping looking up superclasses, the same day it was
<a href="https://bugs.swift.org/browse/SR-10236">reported</a>. 🏎</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0252-keypath-dynamic-member-lookup.md">SE-0252</a>: <em>Key Path Member Lookup</em> was <a href="https://forums.swift.org/t/accepted-se-0252-key-path-member-lookup/22570/2">accepted</a>.</p>
<blockquote>
<p>The review of this proposal has been unanimously positive. Leading up to the
end of the review period the feedback tapered off, and the Core Team decided
to move ahead and conclude the review a couple days early and accept the
proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0249-key-path-literal-function-expressions.md">SE-0249</a>: <em>Key Path Expressions as Functions</em> was <a href="https://forums.swift.org/t/accepted-se-0249-key-paths-expressions-as-functions/22287">accepted</a>.</p>
<blockquote>
<p>Hi everyone, The review period has now ended and this proposal has been
accepted. Thanks for your feedback during the review!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0248-string-gaps-missing-apis.md">SE-0248</a>: <em>String Gaps and Missing APIs</em> was <a href="https://forums.swift.org/t/se-0248-string-gaps-and-missing-apis/21588/5">accepted</a>.</p>
<blockquote>
<p>This proposal has been accepted. Thank you to everyone who participated in the
review of this proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0247-contiguous-strings.md">SE-0247</a>: <em>Contiguous Strings</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0247-contiguous-strings/22111">accepted with modifications</a>.</p>
<blockquote>
<p>The proposal is accepted with one small naming modification: <code class="language-plaintext highlighter-rouge">isContiguous</code>
and <code class="language-plaintext highlighter-rouge">makeContiguous()</code> have been renamed to <code class="language-plaintext highlighter-rouge">isContiguousUTF8</code> and
<code class="language-plaintext highlighter-rouge">makeContiguousUTF8()</code>, respectively.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0246-mathable.md">SE-0246</a>: <em>Generic Math(s) Functions</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0246-generic-math-functions/22244">accepted with modifications</a>.</p>
<blockquote>
<p>Hi, everybody. The review for SE-0246: Generic Math Functions ran from March
11th through the 25th. This review was extended several times in order to
make some adjustments in response to feedback gathered during the review.
The core team would be interested in getting feedback from reviewers on how
they felt about this rapid iteration, and in particular on whether they felt
it detracted from the process overall.</p>
<p>Feedback was positive on the general idea of providing a standard way of
accessing this functionality. Some suggestions were made that the authors
agreed with and chose to immediately incorporate into the proposal, leading
to extension of the review period. The main suggestions that weren’t
incorporated into mid-review revisions were as follows:</p>
<ul>
<li>
<p>Several people expressed unhappiness that <code class="language-plaintext highlighter-rouge">log</code> meant the natural logarithm
(base <em>e</em>). Unfortunately, as observed in the review, the most obvious
alternative name for the natural logarithm is ln, which is not a good
programming name: it’s too short and too visually similar to keywords like
<code class="language-plaintext highlighter-rouge">in</code>. <code class="language-plaintext highlighter-rouge">log</code> for the natural logarithm is also extensively precedented in
many programming languages, including C, Swift’s most obvious antecedent (and
the way that people have gained access to this functionality in Swift before
this proposal). Ultimately, the core team believes that sticking with <code class="language-plaintext highlighter-rouge">log</code> is
the best choice even if there’s some risk of people using it when they meant
<code class="language-plaintext highlighter-rouge">log10</code> or <code class="language-plaintext highlighter-rouge">log2</code>.</p>
</li>
<li>
<p>There was a suggestion that create a <code class="language-plaintext highlighter-rouge">Math</code> module might create conflicts
with names used by other libraries today. The core team agrees that this is
an issue which needs further study and work, but decided to define it away
for this proposal by simply merging the proposed Math module directly into
the Swift module, which already has some similar math functions (such as <code class="language-plaintext highlighter-rouge">min</code>
and <code class="language-plaintext highlighter-rouge">floor</code>); there didn’t seem to be a strong motivation for separating out
the functions proposed here.</p>
</li>
</ul>
<p>Therefore, SE-0246 is accepted with the modifications that the <code class="language-plaintext highlighter-rouge">Math</code> library
should not be added and that the proposed new entities in it should instead
be added directly to Swift.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0245-array-uninitialized-initializer.md">SE-0245</a>: <em>Add an Array Initializer with Access to Uninitialized Storage</em> was <a href="https://forums.swift.org/t/se-0245-add-an-array-initializer-with-access-to-uninitialized-storage/21469/18">accepted</a>.</p>
<blockquote>
<p>Based on the review feedback, SE-0245 has been accepted as written. Thank you
to everyone who reviewed this proposal and provided feedback!</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md">SE-0244</a>: <em>Opaque Result Types</em> was <a href="https://forums.swift.org/t/returned-for-revision-se-0244-opaque-result-types/22115">returned for revision</a>.</p>
<blockquote>
<p>The core team has considered the feedback from the review so far and has
decided the proposal should be returned for revision.</p>
<p>This proposal and implementation lay important groundwork, but it is clear
from the review that work described in the “future directions” section is
necessary to make this a complete and well-integrated language feature. There
are also similarities to and differences with another feature of generalized
existentials.</p>
<p>In order to better consider this proposal as one of a series of potential
additions to the language, the core team is recommending that the proposal
authors put together a manifesto outlining in more detail the full arc of
these features, similar to the generics manifesto.</p>
<p>The authors expect to be able to present such a document soon, and rework
this proposal to fit into that context, at which point we will re-open the
review.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0243-codepoint-and-character-literals.md">SE-0243</a>: <em>Integer-convertible character literals</em> was <a href="https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188/341">rejected</a>.</p>
<blockquote>
<p>The review for SE-0243 has ended and the proposal has been rejected.</p>
<p>To move forward on this topic, and to help the community converge on more of
a consensus around these features, the core team recommends breaking this
proposal out into two separate proposals that could be re-pitched and
(depending on the pitch outcome) re-run.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0256-contiguous-collection.md">SE-0256</a>: <em>Introduce <code class="language-plaintext highlighter-rouge">{Mutable}ContiguousCollection</code> protocol</em> is <a href="https://forums.swift.org/t/se-0256-introduce-mutable-contiguouscollection-protocol/22569">under review</a>.</p>
<blockquote>
<p>This proposal introduces two new protocols: <code class="language-plaintext highlighter-rouge">ContiguousCollection</code>, which
refines <code class="language-plaintext highlighter-rouge">Collection</code>, and <code class="language-plaintext highlighter-rouge">MutableContiguousCollection</code>, which refines
<code class="language-plaintext highlighter-rouge">MutableCollection</code>. Both provide guaranteed access to an underlying
unsafe buffer.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0255-omit-return.md">SE-0255</a>: <em>Implicit returns from single-expression functions</em> is <a href="https://forums.swift.org/t/se-0255-implicit-returns-from-single-expression-functions/22544">under review</a>.</p>
<blockquote>
<p>Swift provides a pleasant shorthand for short closures: if a closure contains
just a single expression, that expression is implicitly returned–the <code class="language-plaintext highlighter-rouge">return</code>
keyword can be omitted. We should provide this shorthand for functions as
well.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0254-static-subscripts.md">SE-0254</a>: <em>Static and class subscripts</em> is <a href="https://forums.swift.org/t/se-0254-static-and-class-subscripts/22537">under review</a>.</p>
<blockquote>
<p>We propose allowing <code class="language-plaintext highlighter-rouge">static subscript</code> and, in classes, <code class="language-plaintext highlighter-rouge">class subscript</code>
declarations. These could be used through either <code class="language-plaintext highlighter-rouge">TypeName[index]</code> or
<code class="language-plaintext highlighter-rouge">TypeName.self[index]</code> and would have all of the capabilities you would
expect of a subscript. We also propose extending dynamic member lookup to
static properties by using static subscripts.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0253-callable.md">SE-0253</a>: <em>Introduce callables</em> is <a href="https://forums.swift.org/t/se-0253-static-callables/22243">under review</a>.</p>
<blockquote>
<p>This proposal introduces <a href="https://en.wikipedia.org/wiki/Callable_object">callables</a>
to Swift. Callables are values that define function-like behavior and can be
applied using function application syntax.</p>
<p>In a nutshell, we propose to introduce a new declaration syntax with the
keyword <code class="language-plaintext highlighter-rouge">call</code>:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">struct</span> <span class="kt">Adder</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">base</span><span class="p">:</span> <span class="kt">Int</span>
<span class="nf">call</span><span class="p">(</span><span class="n">_</span> <span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">base</span> <span class="o">+</span> <span class="n">x</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Values that have a <code class="language-plaintext highlighter-rouge">call</code> member can be applied like functions, forwarding
arguments to the <code class="language-plaintext highlighter-rouge">call</code> member.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">add3</span> <span class="o">=</span> <span class="kt">Adder</span><span class="p">(</span><span class="nv">base</span><span class="p">:</span> <span class="mi">3</span><span class="p">)</span>
<span class="nf">add3</span><span class="p">(</span><span class="mi">10</span><span class="p">)</span> <span class="c1">// => 13</span></code></pre></figure>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0252-keypath-dynamic-member-lookup.md">SE-0252</a>: <em>Key Path Member Lookup</em> is <a href="https://forums.swift.org/t/se-0252-key-path-member-lookup/22172">under review</a>.</p>
<blockquote>
<p>This proposal attempts to enable stronger-typed version of the dynamic member
lookup by extending functionality of an existing <code class="language-plaintext highlighter-rouge">@dynamicMemberLookup</code>
attribute with key path based variants.</p>
<p>Dynamic member lookup allows a type to opt in to extending member lookup
(“dot” syntax) for arbitrary member names, turning them into a string that
can then be resolved at runtime. Dynamic member lookup allows
interoperability with dynamic languages where the members of a particular
instance can only be determined at runtime… but no earlier. Dynamic member
lookups, therefore, tend to work with type-erased wrappers around foreign
language objects (e.g., <code class="language-plaintext highlighter-rouge">PyVal</code> for an arbitrary Python object), which don’t
provide much static type information.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0251-simd-additions.md">SE-0251</a>: <em>SIMD additions</em> is <a href="https://forums.swift.org/t/se-0251-simd-additions/21957">under review</a>.</p>
<blockquote>
<p>A few teams within Apple have requested additions to the new SIMD types and
protocols to better support their use cases. In addition, there are some
features we punted out of the original review because we were up against a
hard time deadline to which we would like to give further consideration.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/jckarter/">Joe Groff</a> shares why the closure syntax uses <a href="https://forums.swift.org/t/history-why-does-closure-syntax-use-the-keyword-in/21885/2">the <code class="language-plaintext highlighter-rouge">in</code> keyword</a>.</p>
<blockquote>
<p>It’s my fault, sorry. In the early days of Swift, we had a closure syntax
that was very similar to traditional Javascript,
<code class="language-plaintext highlighter-rouge">func (arg: Type, arg: Type) -> Return { ... }</code>. While this is nice and
regular syntax, it is of course also very bulky and awkward if you’re trying
to support expressive functional APIs, such as <code class="language-plaintext highlighter-rouge">map</code>/<code class="language-plaintext highlighter-rouge">filter</code> on collections,
or if you want libraries to be able to provide closure-based APIs that feel
like extensions of the language.</p>
<p>Our earliest adopters at Apple complained about this, and mandated that we
support Ruby-style trailing closure syntax.
This is tricky to fit into a C-style syntax like Swift’s, and we tried many
different iterations, including literally Ruby’s <code class="language-plaintext highlighter-rouge">{|args| }</code> syntax, but many
of them suffered from ambiguities or simply distaste and revolt from our
early adopters. We wanted something that still looked like other parts of the
language, but which could be parsed unambiguously and could span the breadth
of use cases from a fully explicit function signature to extremely compact.</p>
<p>We had already taken <code class="language-plaintext highlighter-rouge">in</code> as a keyword, we couldn’t use <code class="language-plaintext highlighter-rouge">-></code> like Java does
because it’s already used to denote the return type, and we were concerned
that using <code class="language-plaintext highlighter-rouge">=></code> like C# would be too visually confusing. <code class="language-plaintext highlighter-rouge">in</code> made
<code class="language-plaintext highlighter-rouge">xs.map { x in f(x) }</code> look vaguely like <code class="language-plaintext highlighter-rouge">for x in xs { f(x) }</code>, and people
hated it less than the alternatives.</p>
</blockquote>
<p><a href="https://twitter.com/neightchan">Nate Chandler</a> pitched <a href="https://forums.swift.org/t/pitch-implicit-returns-from-single-expression-functions/21898">a proposal</a> for implicit
returns from Single-Expression Functions.</p>
<blockquote>
<p>Swift provides a pleasant shorthand for short closures: if a closure contains
just a single expression, that expression is implicitly returned — the
<code class="language-plaintext highlighter-rouge">return</code> keyword can be omitted. We should provide this shorthand for
functions as well.</p>
</blockquote>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> pitched <a href="https://forums.swift.org/t/pitch-add-a-string-initializer-with-access-to-uninitialized-storage/22611">a proposal</a>
to add a <code class="language-plaintext highlighter-rouge">String</code> initializer with access to uninitialized storage.</p>
<blockquote>
<p>I’ve been working on improving the performance of <code class="language-plaintext highlighter-rouge">NSString</code>-to-<code class="language-plaintext highlighter-rouge">String</code>
bridging, and Michael Ilseman pointed out that the more we can build it out
of public API rather than adding a bunch of private stuff for Foundation’s
use, the better off everyone is.</p>
<p>This new initializer is designed to be consistent with the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0245-array-uninitialized-initializer.md">recently-accepted similar initializer on <code class="language-plaintext highlighter-rouge">Array</code></a>.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a>
pitched <a href="https://forums.swift.org/t/pitch-property-delegates/21895">a proposal</a>
to add Property Delegates.</p>
<blockquote>
<p>There are property implementation patterns that come up repeatedly. Rather
than hardcode a fixed set of patterns into the compiler, we should provide a
general “property delegate” mechanism to allow these patterns to be defined
as libraries.</p>
<p>This is an alternative approach to some of the problems intended to be
addressed by the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">2015-2016 property behaviors proposal</a>.
Some of the examples are the same, but this proposal is a completely
different approach designed to be simpler, easier to understand for users,
and less invasive in the compiler implementation. There is a section that
discusses the substantive differences from that design at the end of this
proposal.</p>
</blockquote>
<p><a href="">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/swift-windows/22458">an update</a>
on Swift on Windows.</p>
<blockquote>
<p>I think at this point, with pending patches, we should be able to claim that
Windows support is as good as macOS and Linux!</p>
<p>I have been working on Foundation as well, which is in a better shape than
before. It is possible to build it on Windows, though there is pending work
to refactor the build a slight bit which will improve things and enable the
nightlies to build Foundation as well. However, getting the library to build
is only the beginning and running through the test suite should help get some
level of confidence in the library functioning properly.</p>
<p>The Windows instructions have been updated to reflect all of this
information, and it should be possible for others to replicate this work as
well. Overall, it seems that most of the compiler, runtime, and core
libraries are now usable on Windows with the test coverage quickly converging
to the point where it is nearly as good as the other supported platforms!</p>
</blockquote>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a>
pitched <a href="https://forums.swift.org/t/pitch-static-and-class-subscripts/21850">a proposal</a>
to allow <code class="language-plaintext highlighter-rouge">static</code> and <code class="language-plaintext highlighter-rouge">class</code> subscripts.</p>
<blockquote>
<p>We propose allowing <code class="language-plaintext highlighter-rouge">static subscript</code> and, in classes, <code class="language-plaintext highlighter-rouge">class subscript</code>
declarations. These could be used through either <code class="language-plaintext highlighter-rouge">TypeName[index]</code> or
<code class="language-plaintext highlighter-rouge">TypeName.self[index]</code> and would have all of the capabilities you would
expect of a subscript. We also propose extending dynamic member lookup and
key paths to static properties by using static subscripts.</p>
</blockquote>
<p><a href="https://twitter.com/ilseman">Michael Ilseman</a> gave <a href="https://forums.swift.org/t/string-consumption/21907">an update</a>
on “<code class="language-plaintext highlighter-rouge">String</code> Consumption”.</p>
<blockquote>
<p><strong>Collection consumers</strong></p>
<p>Processing a string, or any <code class="language-plaintext highlighter-rouge">Collection</code> really, typically involves tracking
and advancing a position (i.e. an <code class="language-plaintext highlighter-rouge">Index</code>). This makes something akin to
<code class="language-plaintext highlighter-rouge">Slice</code> a great basis to add consuming operations, which advance indices from
the front (or back if bidirectional).</p>
<p>There are at least 3 ways to surface this:</p>
<ol>
<li>A new wrapper type</li>
<li>Add these to <code class="language-plaintext highlighter-rouge">Slice</code></li>
<li>Add these to all <code class="language-plaintext highlighter-rouge">Collection</code>s that are their own <code class="language-plaintext highlighter-rouge">SubSequence</code></li>
</ol>
<p>Here’s <a href="https://gist.github.com/milseman/f9b5528345db3a36bbdd138af52c5cda">an example</a>
of approach 3, which would put this functionality in a lot of namespaces
(<code class="language-plaintext highlighter-rouge">Slice</code>, <code class="language-plaintext highlighter-rouge">Substring</code>, even <code class="language-plaintext highlighter-rouge">Data</code>). Having these broadly available could
help discoverability, but we also don’t want to pollute namespaces. These are
all “mutating” because they advance indices, but not because they modify the
underlying collection. We need to see some usage to evaluate the tradeoffs.</p>
<p><strong>Regex</strong></p>
<p>I wrote more about regexes <a href="https://gist.github.com/milseman/bb39ef7f170641ae52c13600a512782f#one-possible-approach">here</a>
Regexes did not make it in Swift 5, but we should still pursue them.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Syntax <a href="https://twitter.com/jesse_squires/status/1113547347756064768">is still hard</a>…</p>
Issue #130
https://swiftweeklybrief.com/issue-130
2019-03-21T00:00:00-07:00
2019-03-21T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Last week, Apple <a href="https://developer.apple.com/wwdc19/">announced</a> this year’s
WWDC, while Swift is steadily progressing to what’s next after Swift 5.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://skafos.ai?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_130" target="_blank">Skafos.ai is Machine Learning for iOS Developers</a></h4>
<p>Skafos is the tool for iOS developers to deploy machine learning to their app. Get started with a pre-trained model, drop in the SDK and then updates are pushed to your app in the background. Sign up for the free beta today.</p>
<p><small><a href="https://skafos.ai?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_130" target="_blank">skafos.ai</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/TF-336">TF-336</a> [Python] Add unit testing infrastructure for Python 2 and 3</li>
<li><a href="https://bugs.swift.org/browse/TF-337">TF-337</a> [Python] <code class="language-plaintext highlighter-rouge">PythonObject</code> conformance to <code class="language-plaintext highlighter-rouge">Sequence</code> uses array indexing instead of <code class="language-plaintext highlighter-rouge">Python.iter(...)</code></li>
<li><a href="https://bugs.swift.org/browse/TF-342">TF-342</a> [Python] Adopt Python iterator C API</li>
<li><a href="https://bugs.swift.org/browse/TF-351">TF-351</a> [AutoDiff] Fixit <code class="language-plaintext highlighter-rouge">.withoutDerivative()</code> is inserted to the wrong place</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> and <a href="https://twitter.com/bsaeta">Brennan Saeta</a> gave <a href="https://www.youtube.com/watch?v=s65BigoMV_I">a talk</a> on Swift for TensorFlow.</p>
<p>SwiftNIO 2 is upon us, having started <a href="https://forums.swift.org/t/swiftnio-2-repository-convergence-plan/21387">its convergence</a>. It includes <a href="https://github.com/apple/swift-nio/blob/master/docs/public-api.md">improvements to the public API</a> and comes with a useful <a href="https://github.com/apple/swift-nio/blob/master/docs/migration-guide-NIO1-to-NIO2.md">migration guide</a>. 🚀</p>
<p>Johannes Weiss <a href="https://forums.swift.org/t/swift-log-is-open/21750">shared</a>
that <code class="language-plaintext highlighter-rouge">swift-log</code> is now <a href="https://github.com/apple/swift-log">available on GitHub</a>.</p>
<blockquote>
<p>[..] <code class="language-plaintext highlighter-rouge">swift-log</code> is only the start of a logging that works across the whole ecosystem.</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>After about three years, <a href="https://twitter.com/Injection4Xcode">John Holdsworth</a>
merged <a href="https://github.com/apple/swift/pull/22863">a pull request</a>
implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md">SE-0068</a>: <em>Expanding Swift <code class="language-plaintext highlighter-rouge">Self</code> to class members and value types</em>! 💪</p>
<p><a href="https://github.com/eeckstein">Eric Eckstein</a> merged <a href="https://github.com/apple/swift/pull/23249">a pull request</a>
that eliminates memory allocations from code making heavy use of generics, protocols with associated types, conditional conformances and various other language features:</p>
<blockquote>
<p>These are temporary allocations made by the Swift runtime, while building type metadata. While in most cases the results are cached and reach a steady state, this will still help startup time. For casts to protocols where the type conditionally conforms, speeds up runtime too.</p>
</blockquote>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0242-default-values-memberwise.md">SE-0242</a>: <em>Synthesize default values for the memberwise initializer</em> was <a href="https://forums.swift.org/t/accepted-se-0242-synthesize-default-values-for-the-memberwise-initializer/21475">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted, with a request that the original proposal be amended for clarification of actual behavior. The Core Team felt that the proposal should more explicitly illustrate the actual behavior in a few specific cases, as this was the crux of some of the back-and-forth in the review thread. Note: the proposal has been updated to include more details in the <a href="https://github.com/apple/swift-evolution/blob/b5bbc5ae1f53189641951acfd50870f5b886859e/proposals/0242-default-values-memberwise.md#proposed-solution"><em>proposed solution</em></a> section, as requested by the Core Team.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0245-array-uninitialized-initializer.md">SE-0245</a>: <em>Add an Array Initializer with Access to Uninitialized Storage</em> was <a href="https://forums.swift.org/t/se-0245-add-an-array-initializer-with-access-to-uninitialized-storage/21469">returned for revision</a> as (part of) <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md">SE-0223</a>.</p>
<blockquote>
<p>This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">Array</code> and <code class="language-plaintext highlighter-rouge">ContiguousArray</code>
that provides access to an array’s uninitialized storage buffer.</p>
<p>Some collection operations require working on a fixed-size buffer of uninitialized memory.
For example, one O(<em>n</em>) algorithm for performing a stable partition of an array is as follows:</p>
<ol>
<li>Create a new array the same size as the original array.</li>
<li>Iterate over the original array,
copying matching elements to the beginning of the new array
and non-matching elements to the end.</li>
<li>When finished iterating, reverse the slice of non-matching elements.</li>
</ol>
<p>Unfortunately, the standard library provides no way to create an array of a
particular size without initializing every element. Even if we
avoid initialization by manually allocating the memory using an
<code class="language-plaintext highlighter-rouge">UnsafeMutableBufferPointer</code>, there’s no way to convert that buffer into an
array without copying the contents. There simply isn’t a way to implement this
particular algorithm with maximum efficiency in Swift.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0250-swift-style-guide-and-formatter.md">SE-0250</a>: <em>Swift Code Style Guidelines and Formatter</em> is <a href="https://forums.swift.org/t/se-0250-swift-code-style-guidelines-and-formatter/21795">under review</a>.</p>
<blockquote>
<p>We propose that the Swift project adopt a set of code style guidelines and provide a formatting tool that lets users easily diagnose and update their code according to those guidelines. These guidelines would not be mandatory for all projects, but encouraged for Swift code to follow for general consistency.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0249-key-path-literal-function-expressions.md">SE-0249</a>: <em>Key Path Expressions as Functions</em> is <a href="https://forums.swift.org/t/se-0249-key-path-expressions-as-functions/21780">under review</a>.</p>
<blockquote>
<p>This proposal introduces the ability to use the key path expression <code class="language-plaintext highlighter-rouge">\Root.value</code> wherever functions of <code class="language-plaintext highlighter-rouge">(Root) -> Value</code> are allowed.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0248-string-gaps-missing-apis.md">SE-0248</a>: <em>String Gaps and Missing APIs</em> is <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0248-string-gaps-missing-apis.md">under review</a>.</p>
<blockquote>
<p>String and related types are missing trivial and obvious functionality, much
of which currently exists internally but has not been made API. We propose
adding 9 new methods/properties and 3 new code unit views.</p>
<p>These missing APIs address <a href="https://forums.swift.org/t/efficiently-retrieving-utf8-from-a-character-in-a-string/19916">commonly encountered</a>
gaps and <a href="https://bugs.swift.org/browse/SR-9955">missing functionality</a> for
users of String and its various types, often leading developers to
<a href="https://github.com/apple/swift-nio-http2/blob/master/Sources/NIOHPACK/HPACKHeader.swift#L412">reinvent</a>
the same trivial definitions.</p>
<p>We propose:</p>
<ul>
<li>6 simple APIs on Unicode’s various encodings</li>
<li>2 generic initializers for string indices and ranges of indices</li>
<li><code class="language-plaintext highlighter-rouge">Substring.base</code>, equivalent to <code class="language-plaintext highlighter-rouge">Slice.base</code></li>
<li>Make <code class="language-plaintext highlighter-rouge">Character.UTF8View</code> and <code class="language-plaintext highlighter-rouge">Character.UTF16View</code> public</li>
<li>Add <code class="language-plaintext highlighter-rouge">Unicode.Scalar.UTF8View</code></li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0247-contiguous-strings.md">SE-0247</a>: <em>Contiguous Strings</em> is <a href="https://forums.swift.org/t/se-0247-contiguous-strings/21483">under review</a>.</p>
<blockquote>
<p>One of the most common API requests from performance-minded users of string is a way to get direct access to the raw underlying code units. Now that <a href="https://forums.swift.org/t/string-s-abi-and-utf-8/17676">Swift 5 uses UTF-8</a> for its preferred encoding, we can provide this.</p>
<p>“Contiguous strings” are strings that are capable of providing a pointer and length to <a href="https://en.wikipedia.org/wiki/UTF-8#Invalid_byte_sequences">validly encoded</a> UTF-8 contents in constant time. Contiguous strings include:</p>
<ul>
<li>All native Swift string forms</li>
<li>Lazily bridged Cocoa strings that provide a pointer to contiguous ASCII</li>
<li>Any “shared string” concept we may add in the future</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0246-mathable.md">SE-0246</a>: <em>Generic Math(s) Functions</em> is <a href="https://forums.swift.org/t/se-0246-generic-math-s-functions/21479">under review</a>.</p>
<blockquote>
<p>This proposal introduces two new protocols to the standard library: <code class="language-plaintext highlighter-rouge">ElementaryFunctions</code>
and <code class="language-plaintext highlighter-rouge">Real</code>. These protocols combine to provide “basic math functions” in generic contexts
for floating-point and SIMD types, and provide a path to extend that functionality to
planned complex types in the future.</p>
<p><code class="language-plaintext highlighter-rouge">BinaryFloatingPoint</code> (and the protocols it refines) provides a powerful set of
abstractions for writing numerical code, but it does not include the transcendental
operations defined by the C math library, which are instead imported by the platform
overlay as a set of overloaded concrete free functions.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/ilseman">Michael Ilseman</a> shared <a href="https://forums.swift.org/t/piercing-the-string-veil/21700">some background information</a>
about what is available in String’s ABI in Swift 5.</p>
<blockquote>
<p>String’s ABI encodes information for performant processing and future flexibility, allowing the standard library to run faster and producer smaller and more flexible code. But, this information is not available as API for low-level programming as it’s hidden behind the abstraction of the String type. With this information formally part of <code class="language-plaintext highlighter-rouge">String</code>’s ABI, we should lift the veil of the <code class="language-plaintext highlighter-rouge">String</code> type and start exposing these as API.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/mundaym/summary">Michael Munday</a> shared <a href="https://forums.swift.org/t/fixing-enums-on-big-endian-systems/21730">an update</a>
summarizing the implementation of the <code class="language-plaintext highlighter-rouge">enum</code> layout.</p>
<blockquote>
<p>The issues this post is concerned with affect enums with multiple cases, one or more of which has a payload. In the Swift compiler enums fitting this description are implemented either as a single-payload enum or a multi-payload enum. A single-payload enum consists of exactly one case with a payload as well as one or more empty cases. Multi-payload enums are any other enum with multiple cases and one or more payloads. In particular, multi-payload enums are used whenever there are multiple cases with payloads regardless of whether the payloads have the same type.</p>
</blockquote>
<p><a href="https://twitter.com/dgregor79/">Doug Gregor</a> pitched <a href="https://forums.swift.org/t/pitch-key-path-member-lookup/21579">a proposal</a> around Key Path Member Lookup.</p>
<blockquote>
<p>Dynamic member lookup allows a type to opt in to extending member lookup
(“dot” syntax) for arbitrary member names, turning them into a string that
can then be resolved at runtime. Dynamic member lookup allows
interoperability with dynamic languages where the members of a particular
instance can only be determined at runtime… but no earlier. Dynamic member
lookups therefore tend to work with type-erased wrappers around foreign
language objects (e.g., <code class="language-plaintext highlighter-rouge">PyVal</code> for an arbitrary Python object), which don’t
provide much static type information.</p>
<p>[We propose to] introduce a new attribute <code class="language-plaintext highlighter-rouge">@keyPathMemberLookup</code> that can be
placed on the definition of a type. For such types, “dot” syntax to access a
member will be rewritten as a use of a special subscript whose argument is a
key path describing the member.</p>
</blockquote>
<p><a href="https://forums.swift.org/u/orobio/summary">Manolo van Ee</a> wrote <a href="https://forums.swift.org/t/reverse-generics-and-opaque-result-types/21608">a post</a> with thoughts on Opaque Result types.</p>
<blockquote>
<p>I’ve been trying to wrap my head around <a href="https://forums.swift.org/t/se-0244-opaque-result-types/21252">SE-0244</a>: <em>Opaque Result Types</em> and
recently I had some realizations that helped me understand the proposal
better. I noticed I’m not the only one confused about it, so I thought I’d
write down some things that might help others to get a better grasp of the
concept as well.</p>
<p>In doing so, I’d also like to try and rebrand opaque result types, or at
least the underlying mechanism, to something I’m calling ‘reverse generics’.
I think viewing this all from a slightly different perspective helps a lot
in understanding the concepts involved.</p>
</blockquote>
<p><a href="https://twitter.com/TomerDoron">Tom Doron</a> shared <a href="https://forums.swift.org/t/feedback-server-metrics-api/21353">a proposal</a>
for a Server Metrics API.</p>
<blockquote>
<p>Almost all production server software needs to emit metrics information for observability. The SSWG aims to provide a number of packages that can be shared across the whole Swift Server ecosystem so we need some amount of standardization. Because it’s unlikely that all parties can agree on one full metrics implementation, this proposal is attempting to establish a metrics API that can be implemented by various metrics backends which then post the metrics data to backends like prometheus, graphite, publish over statsd, write to disk, etc.</p>
<p>As outlined above, we should standardize on an API that if well adopted would allow application owners to mix and match libraries from different parties with a consistent metrics collection solution.</p>
</blockquote>
<p><a href="https://twitter.com/vvendra">Vinicius Vendramini</a> pitched <a href="https://forums.swift.org/t/pitch-introduce-custom-attributes/21335">a proposal</a>
to introduce custom attributes.</p>
<blockquote>
<p>Swift currently supports marking declarations with attributes, such as <code class="language-plaintext highlighter-rouge">@objc</code> and <code class="language-plaintext highlighter-rouge">@deprecated</code>. The compiler uses these attributes to change the way it interprets the corresponding code. However, there is no support for declaring and using new attributes to suit the needs of a project or library. This proposal aims to change that.</p>
</blockquote>
<p><a href="https://github.com/dan-zheng">Dan Zheng</a> and <a href="https://twitter.com/rxwei">Richard Wei</a> pitched <a href="https://forums.swift.org/t/pitch-introduce-static-callables/21732">a proposal</a>
to introduce (static) callables in Swift.</p>
<blockquote>
<p>This proposal introduces <a href="https://en.wikipedia.org/wiki/Callable_object">callables</a> to Swift. Values that behave like functions can take advantage of this syntactic sugar, to look like a function call when they are called.</p>
<p>In a nutshell, we propose to introduce a new declaration syntax with the keyword <code class="language-plaintext highlighter-rouge">call</code>:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">struct</span> <span class="kt">Adder</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">base</span><span class="p">:</span> <span class="kt">Int</span>
<span class="nf">call</span><span class="p">(</span><span class="n">_</span> <span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">base</span> <span class="o">+</span> <span class="n">x</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Values that have a call member can be applied like a function, forwarding arguments to the call member.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">add3</span> <span class="o">=</span> <span class="kt">Adder</span><span class="p">(</span><span class="nv">base</span><span class="p">:</span> <span class="mi">3</span><span class="p">)</span>
<span class="nf">add3</span><span class="p">(</span><span class="mi">10</span><span class="p">)</span> <span class="c1">// => 13</span></code></pre></figure>
<h3 id="finally">Finally</h3>
<p>Ever created a <a href="https://twitter.com/oskargroth/status/1106693954991476745">“small”</a> memory leak? 🚰</p>
Issue #129
https://swiftweeklybrief.com/issue-129
2019-03-07T00:00:00-08:00
2019-03-07T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>In the last two weeks, a lot about Swift has been discussed. Proposals, ideas, improvements, and updates galore.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://skafos.ai?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_129" target="_blank">Skafos.ai is Machine Learning for iOS Developers</a></h4>
<p>Skafos is the tool for iOS developers to deploy machine learning to their app. Get started with a pre-trained model, drop in the SDK and then updates are pushed to your app in the background. Sign up for the free beta today.</p>
<p><small><a href="https://skafos.ai?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_129" target="_blank">skafos.ai</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/TF-67">TF-67</a> [Autodiff] <code class="language-plaintext highlighter-rouge">BumpPtrAllocating</code> some classes that have <code class="language-plaintext highlighter-rouge">SmallBitVector</code> fields</li>
<li><a href="https://bugs.swift.org/browse/TF-86">TF-86</a> [Tests] Use <code class="language-plaintext highlighter-rouge">expectEqual</code> instead of <code class="language-plaintext highlighter-rouge">expectTrue</code></li>
<li><a href="https://bugs.swift.org/browse/TF-93">TF-93</a> [Graph Program Extraction] Deabstraction should properly diagnose recursion</li>
<li><a href="https://bugs.swift.org/browse/TF-130">TF-130</a> [Graph Program Extraction] Add API to serialize a <code class="language-plaintext highlighter-rouge">@convention(tensorflow)</code> function as a graph</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/279806">talk about</a> the pitch for an official style guide & formatter for Swift.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> and <a href="https://twitter.com/tkremenek">Ted Kremenek</a> <a href="https://www.swiftbysundell.com/podcast/42">talk about</a> Swift 5, looking at ABI stability and what it means for the future of the language.</p>
<h3 id="news-and-community">News and community</h3>
<p>Swift 4.2.3 for Linux <a href="https://forums.swift.org/t/swift-4-2-3/21089">was released</a>!</p>
<p><a href="https://twitter.com/SmileyKeith/">Keith Smiley</a> shared <a href="https://gist.github.com/keith/3f01e1c9b763e9aceb70411927a0c42c">an overview</a> of Xcode build settings to compiler flags for Swift memory exclusivity.</p>
<p><a href="https://twitter.com/UINT_MIN/">Jordan Rose</a> shared <a href="https://twitter.com/UINT_MIN/status/1098628355539124224">an interesting easter egg</a>: the <a href="https://t.co/VE0jlyjZWA">magic number</a> for <code class="language-plaintext highlighter-rouge">swiftmodule</code> files is <code class="language-plaintext highlighter-rouge">E2 9C A8 0E</code>, or <code class="language-plaintext highlighter-rouge">✨14</code>, referring to the initial name for Swift and its (planned) release year.</p>
<p>The Server Side Swift Conference <a href="https://www.serversideswift.info/videos">posted</a> all its videos from their latest event.</p>
<p>Ray Wenderlich <a href="https://www.raywenderlich.com/server-side-swift">created</a> an overview of Server Side Swift resources.</p>
<p>Swift will once again <a href="https://forums.swift.org/t/swift-to-participate-in-gsoc-2019/20937">participate</a> in the Google Summer of Code project this year.</p>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> shed <a href="https://twitter.com/UINT_MIN/status/1098628355539124224">some more light</a> on Swift’s initial “Shiny” name and where this can still be found within the project. ✨</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0243-codepoint-and-character-literals.md">SE-0243</a>: <em>Integer-convertible character literals</em> is <a href="https://forums.swift.org/t/se-0243-codepoint-and-character-literals/21188">under review</a>.</p>
<blockquote>
<p>Swift’s <code class="language-plaintext highlighter-rouge">String</code> type is designed for Unicode correctness and abstracts away the underlying binary representation of the string to model it as a <code class="language-plaintext highlighter-rouge">Collection</code> of grapheme clusters. This is an appropriate string model for human-readable text, as to a human reader, the atomic unit of a string is (usually) the extended grapheme cluster. When treated this way, many logical string operations “just work” the way users expect.</p>
<p>However, it is also common in programming to need to express values which are intrinsically numeric, but have textual meaning, when taken as an ASCII value. We propose adding a new literal syntax takes single-quotes (<code class="language-plaintext highlighter-rouge">'</code>), and is transparently convertible to Swift’s integer types. This syntax, but not the behavior, will extend to all “single element” text literals, up to and including <code class="language-plaintext highlighter-rouge">Character</code>, and will become the preferred literal syntax these types.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md">SE-0244</a>: <em>Opaque Result Types</em> is <a href="https://forums.swift.org/t/se-0244-opaque-result-types/21252">under review</a>.</p>
<blockquote>
<p>This proposal introduces the ability to hide the specific result type of a function from its callers. The result type is described only by its capabilities, for example, to say that a function returns a <code class="language-plaintext highlighter-rouge">Collection</code> without specifying which specific collection. Clients can use the resulting values freely, but the underlying concrete type is known only to the implementation of the function and need not be spelled out explicitly.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/a-swift-takes-flight/20845">an interesting progress update</a> on Swift on Windows.</p>
<blockquote>
<p>After the Swift/Win32 post, I figure that some people may be curious as to the actual state of Swift for Windows. Well, I would like to share a small status update to that end.</p>
<p>This has been a rather interesting and fun journey. I feel that up until this point, we have been making progress, but the surface area is pretty high, particularly for a single person to take on. I have been chipping away at this for a while now. However, as of today, I think that the situation is about to change. I have finally managed to get the compiler, the support libraries, the runtime, standard library, libdispatch, and now, Foundation to build and run on Windows!</p>
</blockquote>
<p>Awesome work! 🎉</p>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> pitched <a href="https://forums.swift.org/t/protocol-assoctype-t-shorthand-for-combined-protocol-and-associated-type-constraints-without-naming-the-constrained-type/21217">a proposal</a> that introduces a shorthand for combined protocol and associated type constraints without naming the constrained type.</p>
<blockquote>
<p>Swift’s notation for generic constraints generally requires naming the things being constrained; you say that a particular generic parameter conforms to a protocol by naming the generic parameter and the protocol it conforms to, like <code class="language-plaintext highlighter-rouge"><C: Collection></code>, and you put further constraints on its associated types by naming them in a where clause, like <code class="language-plaintext highlighter-rouge">C.Element: Equatable</code>. However, opaque result types, generalized existentials, and other conceivable future language features need a way to describe constraints on a type that doesn’t otherwise have a name; an opaque type is intentionally hidden from the interface, and an existential’s contained type is dynamic and can change at runtime. I can see this evolving into its own major design discussion so I figured it’s a good idea to spin this off from the initial opaque result types proposal.</p>
<p>To kick things off, I’d like to suggest borrowing another idea from Rust here: In Rust, you can use <code class="language-plaintext highlighter-rouge">T: Trait<Assoc = Type></code> as shorthand for a combined constraint that <code class="language-plaintext highlighter-rouge">T</code> implements <code class="language-plaintext highlighter-rouge">Assoc</code> and that <code class="language-plaintext highlighter-rouge">T.Assoc</code> is same-type-constrained to <code class="language-plaintext highlighter-rouge">Type</code>, as if you’d written <code class="language-plaintext highlighter-rouge">T: Trait where T.Assoc = Type</code>. This shorthand can also be used in Rust’s equivalents of opaque types (<code class="language-plaintext highlighter-rouge">impl Trait<Assoc = Type></code>) and existentials (<code class="language-plaintext highlighter-rouge">dyn Trait<Assoc = Type></code>) in addition to generic type constraints. If we were going to do something similar for Swift, we could generalize it a bit so that the shorthand can be used for both protocol and same-type constraints on associated types and to allow constraints between associated types. The result might look something like this:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Leading dot is used to refer to an associated type</span>
<span class="kt">T</span><span class="p">:</span> <span class="kt">Protocol</span><span class="o"><.</span><span class="k">Type</span> <span class="o">==</span> <span class="kt">Int</span><span class="o">></span> <span class="c1">// T: Protocol where T.Type == Int</span>
<span class="kt">T</span><span class="p">:</span> <span class="kt">Protocol</span><span class="o"><.</span><span class="kt">TypeA</span> <span class="o">==</span> <span class="o">.</span><span class="kt">TypeB</span><span class="o">></span> <span class="c1">// T: Protocol where T.TypeA == T.TypeB</span>
<span class="kt">T</span><span class="p">:</span> <span class="kt">Protocol</span><span class="o"><.</span><span class="k">Type</span><span class="p">:</span> <span class="kt">OtherProtocol</span><span class="o">></span> <span class="c1">// T: Protocol where T.Type: OtherProtocol</span></code></pre></figure>
<p><a href="https://twitter.com/tony_allevato">Tony Allevato</a> and <a href="https://twitter.com/daveabrahams">Dave Abrahams</a> pitched <a href="https://forums.swift.org/t/pitch-an-official-style-guide-and-formatter-for-swift/21025">a proposal</a> to introduce an official style guide and formatter for Swift.</p>
<blockquote>
<p>We propose that the Swift project adopt a set of code style
guidelines and provide a formatting tool that lets users easily
diagnose and update their code according to those guidelines.</p>
<p>At the time of this writing, there is no single style agreed on
by developers using Swift. Indeed, even Apple’s own Swift
projects on GitHub—such as the standard library, Foundation,
Swift NIO, and so forth—have adopted their own varying styles.
Furthermore, in many cases the code in those projects—despite
the owners’ best efforts—is not always completely consistent in
terms of style.</p>
</blockquote>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> pitched <a href="https://forums.swift.org/t/pitch-contiguous-strings/21206">a proposal</a> to introduce the concept of contiguous strings.</p>
<blockquote>
<p>One of the most common API requests from performance-minded users of string is a way to get direct access to the raw underlying code units. Now that Swift 5 uses UTF-8 for its preferred encoding, we can provide this.</p>
<p>“Contiguous strings” are strings that are capable of providing a pointer and length to validly encoded UTF-8 contents in constant time.</p>
</blockquote>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> has <a href="https://forums.swift.org/t/development-open-for-swift-4-2-4-for-linux/21287">announced</a> that development for Swift 4.2.4 for Linux is now open.</p>
<blockquote>
<p>Having released Swift 4.2.3, the February 2019 release where we could land a good number of fixes, we’re now happy to open the development of Swift 4.2.4 for Linux.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>The Swift team has a new <a href="https://twitter.com/jckarter/status/1100431977755234306">emotional support dog</a>! 🐶</p>
Issue #128
https://swiftweeklybrief.com/issue-128
2019-02-21T00:00:00-08:00
2019-02-21T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A <em>lot</em> has been happening in the last two weeks. I think a long intro would only distract you from all the interesting bits, so let’s get into it…</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://try.instabug.com/swift-weekly?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_128" target="_blank">Get Detailed Bug Reports from Users In-App</a></h4>
<p>Tired of wasting time debugging your Swift app? Instabug’s SDK is here to help you minimize your debugging time by providing you with complete device details, network logs, and reproduction steps with every bug report. All data is attached automatically. It only takes a line of code to setup. Signup now for free.</p>
<p><small><a href="https://try.instabug.com/swift-weekly?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_128" target="_blank">try.instabug.com/swift-weekly</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-9795">SR-9795</a> [Compiler] Cannot use <code class="language-plaintext highlighter-rouge">super</code> in lazy property: ‘super’ cannot be used outside of class members</li>
<li><a href="https://bugs.swift.org/browse/SR-9851">SR-9851</a> [Compiler] Incorrect fixit for logical NOT operator on value of <code class="language-plaintext highlighter-rouge">Bool?</code> type</li>
<li><a href="https://bugs.swift.org/browse/TF-46">TF-46</a> [Tests] Create unit tests for functions in TFUtilities.</li>
<li><a href="https://bugs.swift.org/browse/TF-51">TF-51</a> [Stdlib] Check and diagnose that a <code class="language-plaintext highlighter-rouge">graph_op</code> is valid when creating a <code class="language-plaintext highlighter-rouge">GraphOperationInst</code></li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>On the Swift Community Podcast, Jon Shier, Kelvin Ma and Chris Lattner discuss <a href="https://www.swiftcommunitypodcast.org/episodes/3">the <code class="language-plaintext highlighter-rouge">Result</code> type</a> that is being introduced in Swift 5.</p>
<h3 id="news-and-community">News and community</h3>
<p>Xcode 10.2 beta 3 is shipping with a <a href="https://twitter.com/jckarter/status/1097944089801052160">stable ABI</a>. 🎉🎉🎉</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> wrote <a href="https://swift.org/blog/5-1-release-process/">a blog post</a> laying out the Swift 5.1 release process.</p>
<p>On the Swift blog, <a href="https://twitter.com/UINT_MIN/">Jordan Rose</a> went in-depth on <a href="https://swift.org/blog/abi-stability-and-more/">ABI Stability and More</a>. Especially recommend taking a look at the nice summary at the end of the post!</p>
<p>In another post on the Swift blog, <a href="https://twitter.com/jckarter">Joe Groff</a> wrote about <a href="https://swift.org/blog/abi-stability-and-apple/">Evolving Swift on Apple Platforms After ABI Stability</a>.</p>
<p>… and in another one (!), <a href="https://twitter.com/ericasadun">Erica Sadun</a> writes <a href="https://swift.org/blog/behind-se-0200/">about enhancing String literals delimiters</a>. 👏</p>
<p><a href="https://twitter.com/chriseidhof">Chris Eidhof</a> and <a href="https://twitter.com/floriankugler">Florian Kugler</a> have <a href="https://www.objc.io/blog/2019/02/12/open-sourcing-the-swift-talk-backend/">open sourced</a> the Swift Talk backend, which is written in Swift. This adds another great resource to learn about Swift on the Server!</p>
<p><a href="https://twitter.com/ericasadun">Erica Sadun</a> wrote <a href="https://ericasadun.com/2019/02/14/bad-things-extension-access-control/">a blog post</a> on some inconsistencies with access control in combination with extensions.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/jenoxx">Christian Schnorr</a> reported <a href="https://forums.swift.org/t/intended-behavior-with-discardableresult/20343">a bug</a> with <code class="language-plaintext highlighter-rouge">@discardableResult</code> and <a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> merged <a href="https://github.com/apple/swift/pull/22518">a pull request</a> to fix it… on the same day! 🏎</p>
<p><a href="https://twitter.com/CodaFi_">Robert Widmann</a> merged <a href="https://github.com/apple/swift/pull/21381">a pull request</a> adding support for default arguments in enum cases. Still remaining: default arguments for subscripts and variadic elements in enum cases. 🎉</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0241-string-index-explicit-encoding-offset.md">SE-0241</a>: <em>Deprecate String Index Encoded Offsets</em> was <a href="https://forums.swift.org/t/accepted-se-0241-explicit-encoded-offsets-for-string-indices/20540">accepted</a>.</p>
<blockquote>
<p>Feedback on the initial proposal was mostly positive, but several people expressed some reservations about some of the new API, and the authors agreed to reduce the proposal to a more minimal change. That new version generally met with approval, with a few dissents:</p>
<ul>
<li>Some community members took the opportunity to register their disapproval of the lack of integer indexing into String. While those complaints are noted, this review was not the place to air them.</li>
<li>Lily Ballard expressed concern about the lack of structure of these encoded offsets and about their behavior when the offset does not correspond to a scalar boundary. The Core Team generally agrees with the proposal author that the offset not matching a scalar boundary is a programmer error for which trapping is consistent with Swift’s general behavior on similar precondition violations.</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0242-default-values-memberwise.md">SE-0242</a>: <em>Synthesize default values for the memberwise initializer</em> is <a href="https://forums.swift.org/t/se-0242-synthesize-default-values-for-the-memberwise-initializer/20618">under review</a>.</p>
<blockquote>
<p>This proposal aims to solve a simple outstanding problem with the way the Swift compiler currently synthesizes the memberwise initializer for structures by synthesizing default values for properties with default initializers.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/TellowKrinkle">Tellow Krinkle</a> pitched <a href="https://forums.swift.org/t/pitch-genericizing-over-annotations-like-throws/20376">a proposal</a> to introduce Generic <code class="language-plaintext highlighter-rouge">throws</code>.</p>
<blockquote>
<p>Right now, you can make a function foo take a function that optionally throws, and only throw if the given function also throws, like this:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="n">_</span> <span class="nv">body</span><span class="p">:</span> <span class="p">()</span> <span class="k">throws</span> <span class="o">-></span> <span class="p">())</span> <span class="k">rethrows</span> <span class="p">{}</span></code></pre></figure>
<blockquote>
<p>However, you can not make a function take an object with a method that optionally throws and only throw if it throws:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Not currently supported</span>
<span class="kd">func</span> <span class="n">foo</span><span class="o"><</span><span class="kt">T</span><span class="p">:</span> <span class="kt">OptionallyThrowingProtocol</span><span class="o">></span><span class="p">(</span><span class="n">_</span> <span class="nv">body</span><span class="p">:</span> <span class="kt">T</span><span class="p">)</span> <span class="k">throws</span> <span class="n">follows</span> <span class="kt">T</span> <span class="p">{}</span></code></pre></figure>
<blockquote>
<p>This pitch would allow you to do that.</p>
</blockquote>
<p><a href="http://github.com/kelvin13">Kelvin Ma</a> shared <a href="https://forums.swift.org/t/vector-manifesto/20508">a <code class="language-plaintext highlighter-rouge">Vector</code> manifesto</a> pitching a possible way of approaching the addition of a Vector type in Swift.</p>
<blockquote>
<p>Vectors, understood as 2, 3, or 4-component numerical aggregates, are a fundamental currency type across many domains of programming. This document seeks to lay out a cohesive vision for adding standard vector support to the Swift language, with consideration for relevant long-term goals for the language type system.</p>
</blockquote>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> posted <a href="https://forums.swift.org/t/swift-win32-programming/20686">another update</a> regarding Swift on Windows… with UI!</p>
<blockquote>
<p>The Windows port has been coming along pretty well. Although it is not yet complete, it is now at the point where you can start doing interesting things with it. As such, I put together a little Hello World^WSwift program for Windows using just Swift! As the saying goes, <a href="https://discourse-cdn-sjc1.com/swift/uploads/default/original/2X/5/565abe55e60e1ed30689483b73eb682b656ed177.png">a picture</a> is worth a thousand words …</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Making working with floating points easier? <a href="https://twitter.com/nnnnnnnn/status/1093576188075958273">I’m all for it</a>. <br />
<a href="https://twitter.com/jnadeau/status/1097946707302572032">And the greatest news of the week is…</a> 😎</p>
Issue #127
https://swiftweeklybrief.com/issue-127
2019-02-07T00:00:00-08:00
2019-02-07T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It has been <a href="https://twitter.com/swiftlybrief/status/1090341325277417473">more than a year</a>
since I took over curating the Swift Weekly Brief from <a href="https://twitter.com/jesse_squires">Jesse</a>.</p>
<p>When Jesse announced that issue 100 would be the Brief’s final issue, I reached
out to him, having helped out with the Brief in the past, to take over the project.</p>
<p>Not only did I really care about this project, but I also felt that it would be
a shame to lose this resource for all of you… and myself. I happily took over
the project (and still feel very fortunate to continue the effort to this day!)
and here we are.</p>
<p>I hope to continue the effort for the foreseeable future! That said, keeping up
a newsletter is no easy feat and <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/blob/master/CONTRIBUTING.md">any help</a>
is very much appreciated.</p>
<p>I want to thank all of the readers, sponsors and specifically contributors over
the last year. You all rock!</p>
<p>Here is to the next year of the Brief! 🏎</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://github.com/exyte/Macaw?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_127" target="_blank">The easiest way to create your own UI controls for iOS</a></h4>
<p>Unfortunately, there is no standard components in iOS to compose drawings, so we are forced to use cumbersome rendering directly on graphics context. Community of iOS developers on Github offers several frameworks to describe graphic components as a scene of primitives. Nowadays, Macaw is the most powerful framework allowing you to create custom components, charts, diagrams and use SVG files. It’s an open source project with 4K+ starts on Github, so take it, use it, and make your life easier.</p>
<p><small><a href="https://github.com/exyte/Macaw?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_127" target="_blank">github.com/exyte/Macaw</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-9738">SR-9738</a> [Compiler] Poor error message when calling @dynamicCallable with incorrect parameter types</li>
<li><a href="https://bugs.swift.org/browse/SR-9781">SR-9781</a> [Compiler] Crash on concrete typealias access through existential metatype</li>
<li><a href="https://bugs.swift.org/browse/SR-9784">SR-9784</a> [Compiler] Crash on accessing type alias through protocol-type instance</li>
<li><a href="https://bugs.swift.org/browse/SR-9789">SR-9789</a> [Compiler] Use “pretty” nullability in generated ObjC headers</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>On Swift Unwrapped, Jesse and JP discuss <a href="https://spec.fm/podcasts/swift-unwrapped/262630">Key Path Expressions as Functions</a>.</p>
<p>On the Swift Community Podcast, Garric, Chris and myself discuss <a href="https://www.swiftcommunitypodcast.org/episodes/2">Scaling A Codeless Open Source Swift Community</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/johannesweiss/">Johannes Weiss</a> announced <a href="https://forums.swift.org/t/announcing-swift-4-2-2-and-monthly-swift-4-2-x-dot-releases-for-linux/20148">Swift 4.2.2 and monthly Swift 4.2.X releases for Linux</a>!</p>
<blockquote>
<p>[..] from now on we will be releasing monthly Swift 4.2.x dot versions for Linux over the next few months. That means you can expect Swift 4.2.3 by the end of February 2019, 4.2.4 by the end of March 2019 and so on.</p>
</blockquote>
<p>On the Swift.org blog, <a href="https://twitter.com/AndrewTrick">Andrew Trick</a>
wrote <a href="https://swift.org/blog/swift-5-exclusivity/">about Swift 5’s Exclusivity Enforcement</a>.</p>
<p><a href="https://github.com/nathawes/">Nathan Hawes</a> also wrote on the Swift.org blog,
about <a href="https://swift.org/blog/sourcekitd-stress-tester/">the <code class="language-plaintext highlighter-rouge">sourcekitd</code> Stress Tester</a>.</p>
<p>Apple released the first Xcode 10.2 beta some time ago. The <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_10_2_beta_release_notes/swift_5_release_notes_for_xcode_10_2_beta">release notes</a>
are now available on the website, without having to login to access the PDF anymore!</p>
<p><a href="https://twitter.com/pathofshrines">John McCall</a>’s <a href="https://www.youtube.com/watch?v=wyAbV8AM9PM">presentation</a>
on Coroutine Representations and ABIs in LLVM is now available!</p>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> and <a href="https://github.com/DougGregor">Doug Gregor</a>’s
<a href="https://www.youtube.com/watch?v=G3bpj-4tWVU">presentation</a> on Efficiently
Implementing Runtime Metadata is now available as well.</p>
<p><a href="https://twitter.com/slava_pestov/">Slava Pestov</a> shared <a href="https://twitter.com/slava_pestov/status/1092845931131817985">a thread</a>
about the ability to Swift compiler to be able to build an Abstract Syntax Tree (AST) Type from a mangled type string stored in the binary’s debug info.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/rintaro">Rintaro Ishizaki</a> merged <a href="https://github.com/apple/swift/pull/22177">a pull request</a>
that fixes a SourceKit regression in Swift 5 — within about 12 hours after it
was reported!</p>
<p><a href="https://twitter.com/aciidb0mb3r/">Ankit Aggarwal</a> merged <a href="https://github.com/apple/swift-package-manager/pull/1966">a pull request</a>
to automatically add package dependencies using SwiftSyntax and libSwiftPM. 🎉</p>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> merged <a href="https://github.com/apple/swift/pull/22231">a pull request</a>
resolves an issue where using a <code class="language-plaintext highlighter-rouge">typealias</code> as an argument to <code class="language-plaintext highlighter-rouge">@escaping</code> on a generic function inside a protocol would trigger an error diagnostic.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0240-ordered-collection-diffing.md">SE-0240</a>: <em>Ordered Collection Diffing</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0240-ordered-collection-diffing/20008">accepted with modifications</a>.</p>
<blockquote>
<p>The proposal is accepted with modifications, specifically:</p>
<ul>
<li>The algorithm’s semantic guarantees have been weakened to specify that it will produce a difference to get from the <code class="language-plaintext highlighter-rouge">self</code> state to the <code class="language-plaintext highlighter-rouge">other</code> state, but not guarantee the shortest such difference. The intent is to allow the standard library to provide a balanced algorithm that provides the shortest difference when possible (e.g., for inputs with fewer differences) but won’t exhibit quadratic behavior for large inputs with many differences.</li>
<li>The name of the algorithm itself is changed from <code class="language-plaintext highlighter-rouge">shortestEditScript(from:)</code> to <code class="language-plaintext highlighter-rouge">difference(from:)</code>.</li>
<li>The name of the collection of differences is changed from <code class="language-plaintext highlighter-rouge">OrderedCollectionDifference</code> to <code class="language-plaintext highlighter-rouge">CollectionDifference</code>.</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0241-string-index-explicit-encoding-offset.md">SE-0241</a>: <em>Deprecate String Index Encoded Offsets</em> is <a href="https://forums.swift.org/t/se-0241-explicit-encoded-offsets-for-string-indices/19929">under review</a>.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a> introduced a computed variable and initializer surrounding the concept of an <code class="language-plaintext highlighter-rouge">encodedOffset</code> for serialization purposes. Unfortunately, that approach is flawed for its intended purpose and is commonly misused in ways that Swift 5 is <a href="https://bugs.swift.org/browse/SR-9749">more likely to expose</a>. It is too late in the Swift 5.0 release to solve all existing problems, so we propose deprecating <code class="language-plaintext highlighter-rouge">encodedOffset</code> and introducing a targeted, semantics-preserving alternative.</p>
<p>Unfortunately, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>’s approach of a single notion of <code class="language-plaintext highlighter-rouge">encodedOffset</code> is flawed. A string can be serialized with a choice of encodings, and the offset is therefore encoding-dependent and requires access to the contents of the string to calculate. A comment in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>’s example source mentioned that <code class="language-plaintext highlighter-rouge">encodedOffset</code> assumes UTF-16, which happened to be the only encoding used internally by String at the time (for offset purposes).</p>
<p>Furthermore, the majority of uses of <code class="language-plaintext highlighter-rouge">encodedOffset</code> in the wild are not following <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>’s intended purpose and are sensitive to encoding changes. <code class="language-plaintext highlighter-rouge">encodedOffset</code> is frequently misused under the assumption that all Characters are comprised of a single code unit, which is error-prone and Swift 5 might surface the underlying bugs in more situations. It is also sometimes used for mapping Cocoa string indices, which happens to work in Swift 4 but might not in Swift 5, and Foundation already provides better alternatives.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Swift is hard. Especially if <a href="https://twitter.com/jckarter/status/1093180314526965760">you want it to be</a>.</p>
Issue #126
https://swiftweeklybrief.com/issue-126
2019-01-24T00:00:00-08:00
2019-01-24T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Last week we saw the introduction of a new <a href="https://www.swiftcommunitypodcast.org">Swift Community Podcast</a>.
The podcast is set up in a similar way (and inspired by) this very Newsletter,
fostering the Swift Community, encouraging anyone to help out.</p>
<p>I think this is a really exciting project and am looking forward to seeing the
Swift community bring it to life!</p>
<p>And without further ado, here is an update on the last two weeks in Swift open
source.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-9670">SR-9670</a> [Compiler] Driver should accept <code class="language-plaintext highlighter-rouge">-serialize-diagnostics-path</code> for the interpret mode</li>
<li><a href="https://bugs.swift.org/browse/SR-9677">SR-9677</a> [Compiler] Using break with unresolved label inside loops produces misleading diagnostic</li>
</ul>
<h3 id="podcasts">Podcasts</h3>
<p>John, Garric and Chris <a href="https://www.swiftcommunitypodcast.org/episodes/1">introduce</a> the Swift Community podcast, talking about its concept and their first impressions of Swift.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/jeremyphoward">Jeremy Howard</a> finished <a href="https://www.fast.ai/2019/01/10/swift-numerics/">a research project</a> trying to answer the question: is Swift a good language for high performance numeric programming in Mac and Linux?</p>
<blockquote>
<p>I think this has the potential to be great for data science.</p>
</blockquote>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> shared <a href="https://forums.swift.org/t/opaque-result-types/15645/250">a prototype implementation</a> of opaque result types.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/aschwaighofer">Arnold Schwaighofer</a> merged <a href="https://github.com/apple/swift/pull/21933">a pull request</a> that has non-escaping context allocated on the stack.</p>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> merged <a href="https://github.com/apple/swift/pull/21932">a pull request</a> that combines two code paths, fixing an edge case neither one could handle. 🎉</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0239-codable-range.md">SE-0239</a>: <em>Add <code class="language-plaintext highlighter-rouge">Codable</code> conformance to <code class="language-plaintext highlighter-rouge">Range</code> types</em> was <a href="https://forums.swift.org/t/se-0239-add-codable-conformance-to-range-types/18794/50">accepted</a>.</p>
<blockquote>
<p>Thank you everyone for the very insightful feedback provided during this review. It provided some great insights into the Swift’s community uses and desires on Codable.</p>
<p>Regarding the proposal itself, the Core Team has decided to accept it, with the proposal amended to include the details of the encoding format chosen. The data encoding chosen is an important semantic invariant of the API that is potentially observable by users and important for binary compatibility. Future proposals like this one that discuss adopting <code class="language-plaintext highlighter-rouge">Codable</code> should include details — and when necessary — rationale on the encoding chosen. Further, it would be valuable if the current chosen encodings for Standard Library types were also documented so that users using the default encodings for those types can either rely upon those encodings or know when they need to customize their encoding logic for a specific task.</p>
<p>In addition, the Core Team decided to extend the proposal to include <code class="language-plaintext highlighter-rouge">Codable</code> conformance for <code class="language-plaintext highlighter-rouge">ContiguousArray</code>, which was similarly missing from the Standard Library. This felt like a case that required no additional review discussion.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0240-ordered-collection-diffing.md">SE-0240</a>: <em>Ordered Collection Diffing</em> is <a href="https://forums.swift.org/t/se-0240-ordered-collection-diffing/19514">under review</a>.</p>
<blockquote>
<p>This proposal describes additions to the standard library that provide an interchange format for diffs as well as diffing/patching functionality for ordered collection types.</p>
<p>Representing, manufacturing, and applying transactions between states today requires writing a lot of error-prone code. This proposal is inspired by the convenience of the <code class="language-plaintext highlighter-rouge">diffutils</code> suite when interacting with text files, and the reluctance to solve similar problems in code with <code class="language-plaintext highlighter-rouge">libgit2</code>.</p>
<p>Many state management patterns would benefit from improvements in this area, including undo/redo stacks, generational stores, and syncing differential content to/from a service.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/stephencelis">Stephen Celis</a> and <a href="https://twitter.com/gregtitus">Greg Titus</a> shared <a href="https://forums.swift.org/t/key-path-expressions-as-functions/19587">a proposal pitch</a> to allow key path expressions as functions.</p>
<blockquote>
<p>One-off closures that traverse from a root type to a value are common in Swift. Consider the following <code class="language-plaintext highlighter-rouge">User</code> struct:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">struct</span> <span class="kt">User</span> <span class="p">{</span>
<span class="k">let</span> <span class="nv">email</span><span class="p">:</span> <span class="kt">String</span>
<span class="k">let</span> <span class="nv">isAdmin</span><span class="p">:</span> <span class="kt">Bool</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Applying <code class="language-plaintext highlighter-rouge">map</code> allows the following code to gather an array of emails from a source user array:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="n">users</span><span class="o">.</span><span class="n">map</span> <span class="p">{</span> <span class="nv">$0</span><span class="o">.</span><span class="n">email</span> <span class="p">}</span></code></pre></figure>
<blockquote>
<p>Similarly, <code class="language-plaintext highlighter-rouge">filter</code> can collect an array of admins:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="n">users</span><span class="o">.</span><span class="n">filter</span> <span class="p">{</span> <span class="nv">$0</span><span class="o">.</span><span class="n">isAdmin</span> <span class="p">}</span></code></pre></figure>
<blockquote>
<p>These ad hoc closures are short and sweet but Swift already has a shorter and sweeter syntax that can describe this: key paths.</p>
</blockquote>
<p><a href="https://twitter.com/loiclec">Loïc Lecrenier</a> shared <a href="https://forums.swift.org/t/support-for-fuzz-testers-in-swift-packages/19494">a pitch</a> to support fuzz testers for Swift packages.</p>
<blockquote>
<p>Recently, I wrote a coverage-guided Swift <a href="https://github.com/loiclec/FuzzCheck">fuzzer</a> similar to <code class="language-plaintext highlighter-rouge">libFuzzer</code>, but I found that SwiftPM did not allow me to specify the build settings I needed, and I had to fork SwiftPM to make my project work.</p>
<p>Using a coverage-guided fuzzer requires the tested targets to be instrumented with LLVM’s <a href="https://clang.llvm.org/docs/SanitizerCoverage.html">SanitizerCoverage</a>, which is kind of possible to do now with the option <code class="language-plaintext highlighter-rouge">-sanitize=fuzzer</code> when using a development version of <code class="language-plaintext highlighter-rouge">swiftc</code>. And it is possible to add that option to a package because SwiftPM supports custom build settings thanks to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0238-package-manager-build-settings.md">SE-0238</a>, but only for targets that are declared in the root package, not for targets declared in a dependency.</p>
<p>Moreover, instrumenting a target makes its resulting binary unfit to be used for any other purpose than fuzzing, so I believe it would be best to isolate the products of a “fuzzing” build by using a separate build configuration than debug or release.</p>
</blockquote>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/swift-corelibs-foundation-windows-and-build-option-defaults-recommendations/19463">a progress update</a> on Swift for Windows.</p>
<blockquote>
<p>Working my way through the <code class="language-plaintext highlighter-rouge">swift-corelibs-foundation</code> for Windows, I think I have gotten to the point where I believe that the last items preventing Windows support for Foundation can now be enumerated:</p>
<ul>
<li>Porting the remaining interfaces in Process, Thread, FileManager, and Host</li>
<li>Fixing the VWT handling for ForeignClassMetadata strategy</li>
<li>Fixing protocol witness table emission to be exported from the standard library</li>
<li>Identifying the desired behaviours for curl/libxml2 linkage</li>
</ul>
<p>The first three are more technical, the implementation for the interfaces just need someone dedicated enough to work through the surface and with some time. The second would be something that is more involved, the third is just a bug.</p>
<p>[..] For those interested in the rest of the Windows port, especially those interested in helping getting Foundation running on Windows, do checkout the <a href="https://github.com/apple/swift-corelibs-foundation/pull/1812">work in progress pull request</a>. I would certainly love some help!</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>// Welcome to the <a href="https://twitter.com/jckarter/status/1085303872883613696">world of software development</a>.</p>
Issue #125
https://swiftweeklybrief.com/issue-125
2019-01-10T00:00:00-08:00
2019-01-10T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Hello all, and a belated happy New Year! May 2019 be a wonderful year to all of you… and Swift!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-9466">SR-9466</a> [Compiler] Redo AssignInst lowering in DI</li>
<li><a href="https://bugs.swift.org/browse/SR-9482">SR-9482</a> [ClangImporter] Swift’s filtering of “header guard” macros is too strict</li>
<li><a href="https://bugs.swift.org/browse/SR-9557">SR-9557</a> [IRGen] Objective-C property description includes ivar name even when getters and setters are non-trivial</li>
<li><a href="https://bugs.swift.org/browse/SR-9558">SR-9558</a> [SwiftPM] Improve error message when test directory is missing</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/246766">discussed</a> SourceKit-LSP (Language Server Protocol), an implementation of the LSP for Swift and C-based languages.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/compnerd">Saleem Abdulrasool</a> shared <a href="https://forums.swift.org/t/windows-nightlies/19174">nightly builds for Swift on Windows</a>! “This has sufficient bits built and packaged to be semi-usable”; a job well done!</p>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> shared <a href="https://twitter.com/pathofshrines/status/1074382960420368384">some interesting thoughts</a> on open source language project management that is valid for Swift.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/Catfish_Man">David Smith</a> merged <a href="https://github.com/apple/swift/pull/21235">a pull request</a> improving <code class="language-plaintext highlighter-rouge">NSDictionary</code> to <code class="language-plaintext highlighter-rouge">Swift.Dictionary</code> bridging! 🎉</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/21370">a pull request</a> that enables shadowing for type lookups, which allows for Swift’s <code class="language-plaintext highlighter-rouge">Result</code> not to cause any source-breaking changes as a result (no pun intended)!</p>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> merged <a href="https://github.com/apple/sourcekit-lsp/pull/24">a pull request</a> that allows folding code structures for the Swift Language Server Protocol.</p>
<p><a href="https://twitter.com/akyrtzi">Argyrios Kyrtzidis</a> merged <a href="https://github.com/apple/swift/pull/21762">a pull request</a> exposing parser details as a C API, allowing Swift clients, such as SwiftSyntax, to reuse compiler logics in-process.
That then gives a significant performance gain for syntax tree generation by avoiding any forms of cross-process serialization. 🏎</p>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/21756">a pull request</a> diagnosing missing members via the new diagnostics framework.</p>
<p><a href="https://twitter.com/suyashsrijan">Suyash Srijan</a> merged <a href="https://github.com/apple/swift/pull/21621">a pull request</a> that adds a warning if usage of a <code class="language-plaintext highlighter-rouge">.none</code> enum case is ambiguous.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0239-codable-range.md">SE-0239</a>: <em>Add Codable conformance to Range types</em> is <a href="https://forums.swift.org/t/se-0239-add-codable-conformance-to-range-types/18794">under review</a>.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a> introduced <code class="language-plaintext highlighter-rouge">Codable</code> conformance for some types in the standard
library, but not the <code class="language-plaintext highlighter-rouge">Range</code> family of types. This proposal adds that
conformance.</p>
<p><code class="language-plaintext highlighter-rouge">Range</code> is a very useful type to have conform to <code class="language-plaintext highlighter-rouge">Codable</code>. A good usage example is a range being sent to/from a client/server to convey a range of time using <code class="language-plaintext highlighter-rouge">Date</code>, or a safe operating temperature range using <code class="language-plaintext highlighter-rouge">Measurement<UnitTemperature></code>.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/rkandhad">Ravi Kandhadai Madhavan</a> wrote <a href="https://forums.swift.org/t/improving-os-log-using-custom-string-interpolation-and-compile-time-interpretation/18799">about</a> improving Swift APIs for Apple’s <a href="https://developer.apple.com/videos/play/wwdc2016/721/">unified logging systems</a>.</p>
<blockquote>
<p>We propose to change the Swift APIs for the Apple’s unified logging system (namely, <code class="language-plaintext highlighter-rouge">os_log</code> and <code class="language-plaintext highlighter-rouge">os_signpost</code>)
to accept string interpolations instead of the printf-style format string and varargs combination that they currently accept.
This means Swift users can pass in string interpolations to the logging functions e.g. like <code class="language-plaintext highlighter-rouge">osLog("Fatal Error \(errno)")</code>.</p>
</blockquote>
<p><a href="https://twitter.com/johannesweiss">Johannes Weiss</a> shared <a href="https://forums.swift.org/t/feedback-server-logging-api-with-revisions/19375">a revised proposal pitch</a> for the Swift Server logging API.</p>
<blockquote>
<p>We have integrated most of the feedback from the discussion thread so even if you have read the previous version, you will find some changes that you hopefully agree with. To highlight a few of the major changes:</p>
<ul>
<li>Logging metadata is now structures and now supports nested dictionaries and list values, in addition to strings of course.</li>
<li>only locally relevant metadata can now be passed to the individual log methods.</li>
<li>ship a multiplex logging solution with the API package</li>
</ul>
<p>The feedback model will be very similar to the one known from Swift Evolution. The community is asked to provide feedback in the way outlined below and after the review period finishes, the SSWG will – based on the community feedback – decide whether to promote the proposal to the <a href="https://github.com/swift-server/sswg/blob/master/process/incubation.md#process-diagram">Sandbox</a> maturity level or not.</p>
</blockquote>
<p><a href="https://twitter.com/benlangmuir">Ben Langmuir</a> shared <a href="https://forums.swift.org/t/rfc-building-swift-packages-in-build-script/18920">some thoughts</a> on building, testing and installing Swift packages.</p>
<blockquote>
<p>We have a number of SwiftPM packages (swift-syntax, sourcekitd stress tester, and now SourceKit-LSP) that we want to be able to build, test and install along with the rest of the Swift toolchain in continuous integration and packaging infrastructure. I started looking into this to add sourcekit-lsp to Swift CI, and I ran into a number of difficulties. The key challenge is that we want to build and run these packages using the just-built toolchain, including the compiler, package manager, and corelibs, but our tooling is not setup well for that. The rest of this post dives into what the problems are and how I propose we tackle them.</p>
</blockquote>
<p><a href="https://twitter.com/numist">Scott Perry</a> pitched <a href="https://forums.swift.org/t/ordered-collection-diffing/18933">a proposal</a> for “diffing” of ordered collections.</p>
<blockquote>
<p>I’d like to pitch the formalization of ordered collections as well as the addition of diffing functionality and related types necessary to provide easy creation, representation, and application of ordered collection state transitions.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>It’s not only programming languages that are hard… <a href="https://twitter.com/jckarter/status/1075156018198265856">or is it</a>?</p>
Issue #124
https://swiftweeklybrief.com/issue-124
2018-12-13T00:00:00-08:00
2018-12-13T00:00:00-08:00
Kristaps Grinbergs
https://twitter.com/fassko
https://github.com/fassko.png?size=100
fassko
<p>Welcome to issue 124 of the Weekly Brief! This is my first issue as an author. I have always been amazed by the Swift community and open source.</p>
<p><a href="https://twitter.com/SwiftLang/status/672556073362960384">Three years ago today</a>, Swift was open sourced. What a journey it has been!</p>
<p>A lot has happened in the Swift community and it seems that team wants to finish all the tasks before the New Year - accepting the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md">Result proposal</a> and <a href="https://twitter.com/mishaldshah/status/1070048389893505024">publishing</a> <a href="https://swift.org/download/#snapshots">Swift 5.0 nightly builds</a>.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8728">SR-8728</a> [Compiler] Add note about conditional conformance to <code class="language-plaintext highlighter-rouge">RandomAccessCollection</code> docs</li>
<li><a href="https://bugs.swift.org/browse/SR-8513">SR-8513</a> [Compiler] Confusing error messages for interactions between same-name types from different modules</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/234517">explored</a> the famous <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md">Result proposal</a>, discussing its pros and cons.</p>
<h3 id="news-and-community">News and community</h3>
<p>The Swift Server Work Group had a meeting. Not only did they add new members, but they also <a href="https://forums.swift.org/t/november-29th-2018/18400">discussed some important topics</a> such as Docker updates, Crypto, HTTP Client improvements and more.</p>
<p><a href="https://twitter.com/inamiy">Yasuhiro Inami</a> announced <a href="https://github.com/inamiy/SwiftRewriter">SwiftRewriter</a>, a composable Swift code formatter on top of <a href="https://github.com/apple/swift-syntax">SwiftSyntax</a>.</p>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> explored <a href="https://swiftrocks.com/how-dynamicmemberlookup-works-internally-in-swift.html">how <code class="language-plaintext highlighter-rouge">@dynamicMemberLookup</code> Works Internally in Swift (+ Creating Custom Swift Attributes)</a></p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> investigated how to <a href="https://oleb.net/2018/sequence-head-tail/">split a Swift Sequence into head and tail</a> in Swift 4.2 and why it will break in Swift 5 because of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0234-remove-sequence-subsequence.md">SE-0234</a>.</p>
<p>Amazon has open sourced <a href="https://github.com/amzn/smoke-framework"><code class="language-plaintext highlighter-rouge">smoke-framework</code></a>, a lightweight server-side service framework written in Swift and using <a href="https://github.com/apple/swift-nio">SwiftNIO</a> for its networking layer.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/milseman">Michael Ilseman</a> merged <a href="https://github.com/apple/swift/pull/21178">a pull request</a> which allows to access the raw UTF-8 code units backing a String thanks to <code class="language-plaintext highlighter-rouge">String.UTF8View.withContiguousStorageIfAvailable</code> hook.</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/21155">a pull request</a> that fixes converting a metatype to a readable string when the metatype is for a function type with a single tuple type argument. Related to <a href="https://bugs.swift.org/browse/SR-8235">SR-8235</a>.</p>
<p><a href="https://github.com/jckarter">Joe Groff</a> merged <a href="https://github.com/apple/swift/pull/21102">a pull request</a> that provides ABI space for source location info in unconditional casts.</p>
<p><a href="https://github.com/harlanhaskins">Harlan Haskins</a> merged <a href="https://github.com/apple/swift/pull/21033">a pull request</a> that consolidates the functions used to check accessors versus other declarations, and makes sure we check setter access as well as regular declaration access. This also resolves <a href="https://bugs.swift.org/browse/SR-8969">SR-8969</a>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md">SE-0235</a>: <em>Add Result to the Standard Library</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0235-add-result-to-the-standard-library/18603">accepted with modifications</a>.</p>
<blockquote>
<p>The Core Team acknowledges the call from several reviewers to make a special effort to communicate how we think <code class="language-plaintext highlighter-rouge">Result</code> ought to be used in Swift. We absolutely agree that is an important part of adding <code class="language-plaintext highlighter-rouge">Result</code> to the language, and we intend to provide this guidance as part of the release.</p>
<p>Although we are revising the proposal again, the Core Team feels that these issues have already received adequate review, and there is no need for a third round of review. Accordingly, SE-0235 has been Accepted with Modifications.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0236-package-manager-platform-deployment-settings.md">SE-0236</a>: <em>Package Manager Platform Deployment Settings</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0236-package-manager-platform-deployment-settings/18420">accepted</a>.</p>
<blockquote>
<p>There was a lot of negative feedback about the platform restrictions part of the proposal, so the SwiftPM code owners decided to accept a revised version of the proposal which only handles customization of deployment targets. The topic of platform restrictions for packages can be revisited separately at a later time.</p>
<p>For specifying custom deployment versions, the original proposal mentions that an initializer will be provided. However, since that would be too verbose, a string overload will be provided instead. This makes the API <code class="language-plaintext highlighter-rouge">.macOS("10.13")</code> instead of <code class="language-plaintext highlighter-rouge">.macOS(MacOSVersion("10.13"))</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0238-package-manager-build-settings.md">SE-0238</a>: <em>Package Manager Target Specific Build Settings</em> was <a href="https://forums.swift.org/t/accepted-with-modifications-se-0238-package-manager-target-specific-build-settings/18590">accepted</a>.</p>
<blockquote>
<p>This is a proposal for adding support for declaring some commonly used target-specific build settings in the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest file. As the name suggests, target-specific build settings are only applied to a particular target. SwiftPM also aims to support cross-target build settings that go across the target boundary and impart certain settings on a target’s dependees, but this proposal is only concerned with the former type of build settings and the latter will be explored with a future proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0237-contiguous-collection.md">SE-0237</a> <em>Introduce <code class="language-plaintext highlighter-rouge">withContiguous{Mutable}StorageIfAvailable</code> methods</em> was <a href="https://forums.swift.org/t/review-2-of-se-0237-introduce-withunsafe-mutable-bufferpointerifsupported-methods/18418">returned for revision</a> and later <a href="https://forums.swift.org/t/accepted-with-modifications-se-0237-introduce-with-contiguous-mutable-storage-if-available-methods/18713">accepted with modifications</a>.</p>
<blockquote>
<p>The Core Team felt that the use of inout for the closure parameter of <code class="language-plaintext highlighter-rouge">withUnsafeMutableBufferPointer(IfSupported)</code> was the best available option, and noted that the library could verify that the <code class="language-plaintext highlighter-rouge">UnsafeMutableBufferPointer</code> itself wasn’t directly modified by checking for the expected base address / count after the call. This limits the chance of confusion without resorting to shadowing or excessive overloading of mutating operations.</p>
<p>The two proposed protocols (<code class="language-plaintext highlighter-rouge">ContiguousCollection</code> and <code class="language-plaintext highlighter-rouge">MutableContiguousCollection</code>) aren’t used in any algorithms within the library. It is not clear that they are important enough to introduce as protocols into the Standard Library at this time. The Core Team would like to consider a revised proposal that does not introduce these protocols.</p>
<p>There are use cases for a <code class="language-plaintext highlighter-rouge">Sequence</code> equivalent to the proposed <code class="language-plaintext highlighter-rouge">withUnsafeMutableBufferPointerIfSupported</code>, such as initializing a String from a <code class="language-plaintext highlighter-rouge">Sequence</code> of UTF-8 code points that are (e.g.) stored in a <code class="language-plaintext highlighter-rouge">Data</code>. The Core Team would like to see this addition to the <code class="language-plaintext highlighter-rouge">Sequence</code> protocol, which would allow <code class="language-plaintext highlighter-rouge">Sequence</code> clients to optimize for the contiguously-stored case without requiring a new protocol, much as the proposal already allows <code class="language-plaintext highlighter-rouge">MutableCollection</code> clients to optimize for the contiguously-stored mutable case.</p>
</blockquote>
<hr />
<blockquote>
<p>The revised proposal shows the changes, which are:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">Sequence</code> will have a new (defaulted) requirement <code class="language-plaintext highlighter-rouge">withContiguousStorageIfAvailable</code>, and</li>
<li><code class="language-plaintext highlighter-rouge">MutableCollection</code> will have a new (defaulted) requirement <code class="language-plaintext highlighter-rouge">withContiguousMutableStorageIfAvailable</code>.</li>
</ul>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Amazon recently introduced the Lambda Runtime API to use with any programming language. <a href="https://twitter.com/tkremenek">Ted Kremenek</a> agrees <a href="https://forums.swift.org/t/aws-lambda-runtime-api/18498/4">that this is a big step</a> for the Swift on the Server ecosystem.</p>
<p><code class="language-plaintext highlighter-rouge">Async</code>/<code class="language-plaintext highlighter-rouge">Await</code> is not yet implemented, but there’s already a few of <a href="https://forums.swift.org/t/proposal-to-add-cancellation-abilities-for-async-await/18419">ideas how to improve it</a> by adding cancellation abilities.</p>
<blockquote>
<p>The motivation is to provide a consistent and simple API to cancel asynchronous tasks. My theory (seemingly shared by some) is that supporting cancellation is too much trouble for many programmers, because it is a bit involved and the app may still basically work without it. But performance will likely suffer. With this proposal cancellation becomes a simple task so is much more likely to be implemented by app developers.</p>
</blockquote>
<p>The SwiftNIO team wants to change the <a href="https://forums.swift.org/t/rfc-moving-swiftnio-ssl-to-boringssl/18280">TLS implementation used by <code class="language-plaintext highlighter-rouge">swift-nio-ssl</code></a>.</p>
<blockquote>
<p>We propose to change <code class="language-plaintext highlighter-rouge">swift-nio-ssl</code> to stop linking against the system copy of <code class="language-plaintext highlighter-rouge">libssl</code>, and instead to provide a vendored copy of <code class="language-plaintext highlighter-rouge">BoringSSL</code>. This change would come with a number of subtle runtime behavioural changes, as well as a number of substantially more disruptive changes around application distribution and OS behavior.</p>
<p>The proposed change would drop support for <code class="language-plaintext highlighter-rouge">OpenSSL</code> and <code class="language-plaintext highlighter-rouge">LibreSSL</code>. The reasoning for this choice is discussed later in the proposal, and is not necessarily mandatory.</p>
<p>Note that for Apple platforms the recommended TLS solution will still be to use <code class="language-plaintext highlighter-rouge">swift-nio-transport-services</code>.</p>
</blockquote>
<p>Last week, <a href="https://twitter.com/simjp">JP Simard</a> wrote how slow SwiftSyntax is. The Swift team has <a href="https://forums.swift.org/t/speeding-up-swiftsyntax-by-using-the-parser-directly/18493">heard it</a>.</p>
<blockquote>
<p>Providing direct access to the parser speeds up SwiftSyntax 8x, and it becomes 2x faster than the legacy sourcekitd syntactic request</p>
</blockquote>
<p>We all know <a href="https://twitter.com/mattt">Mattt</a>’s <a href="https://www.youtube.com/watch?v=8pnHolNHD2Y">obsession of Strings</a>, this time pitching <a href="https://forums.swift.org/t/pitch-unicode-named-character-escape-sequence/18396">Unicode Named Character Escape Sequence</a>.</p>
<blockquote>
<p>This proposal adds a new <code class="language-plaintext highlighter-rouge">\N{name}</code> escape sequence to Swift string literals, where name is the name of a Unicode character.</p>
<p>Each Unicode character is assigned a unique code point, a number between <code class="language-plaintext highlighter-rouge">U+0000</code> — <code class="language-plaintext highlighter-rouge">U+10FFFF</code>, and a name, consisting of uppercase letters (A–Z), digits (0–9), hyphens, and spaces. For example, the Unicode character for the letter “A” used in English has the code point <code class="language-plaintext highlighter-rouge">U+0041</code> and the name <code class="language-plaintext highlighter-rouge">LATIN CAPITAL LETTER A</code>. The term scalar value defines the subset of Unicode code points that aren’t surrogate pairs.</p>
<p>In Swift, a string literal may include a character directly (“A”) or using the <code class="language-plaintext highlighter-rouge">\u{n}</code> escape sequence, where n is a 1–8 digit hexadecimal number corresponding to the scalar value (<code class="language-plaintext highlighter-rouge">"\u{0041}"</code>). A string literal may also include character by interpolation (<code class="language-plaintext highlighter-rouge">let letterA = "\u{0041}"; "\(letterA)"</code>).</p>
</blockquote>
<p>A discussion has arisen about <a href="https://forums.swift.org/t/keypaths-tuples-and-swift-5/18465">KeyPaths for Tuples in Swift 5</a>.</p>
<blockquote>
<p>.. finding out that <code class="language-plaintext highlighter-rouge">\SomeType.aTuple.0</code> does not work ..</p>
<p>I think this would be a great starter project. The runtime ABI for keypaths should not need any modification to handle tuple components, so there’s no rush to implement this. There’s an <a href="https://github.com/apple/swift/blob/master/docs/ABI/KeyPaths.md">ABI document</a> that describes the layout of key path objects; the details are somewhat out of date, but the high level structure is the same</p>
</blockquote>
<p>Very interesting discussion about <a href="https://forums.swift.org/t/after-abi-stability-will-diagnostics-and-type-inference-get-some-love/18685">Diagnostics and Type Inference after ABI stability</a>.</p>
<blockquote>
<p>Two things I really wish would improve are diagnostics and type inference, in particular when it comes to closures and generics. (I’m beginning to accept the limitations on protocols with associated types).</p>
<ol>
<li>What would be the process to fix such basic annoyances?</li>
<li>Was the focus on ABI stability the main reason for why these issues still exist?</li>
<li>What will be the Swift evolution focus after ABI stability?</li>
</ol>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Can we write poetry and haikus about Swift? <a href="https://twitter.com/twostraws/status/1070408833321836545">Yes we can</a>!</p>
Issue #123
https://swiftweeklybrief.com/issue-123
2018-11-29T00:00:00-08:00
2018-11-29T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Welcome to issue 123 of the Weekly Brief! Although winter is approaching fast,
that doesn’t stop the Swift team and community (yet). A lot of discussion has
taken place over the last two weeks, and below you’ll find an overview of that.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-9341">SR-9341</a> [Tooling] Add tests for update-checkout (Python)</li>
<li><a href="https://bugs.swift.org/browse/SR-9373">SR-9373</a> [Compiler] Clang importer should refuse to import arrays with excessive numbers of elements</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/BalestraPatrick">Patrick Balesta</a> wrote <a href="https://patrickbalestra.com/blog/2018/11/12/contributing-to-the-swift-benchmark-suite.html">a blog post</a> on contributing to the Swift Benchmark Suite!</p>
<p><a href="https://twitter.com/dmartincy">Daniel Martín</a> wrote <a href="https://pspdfkit.com/blog/2018/tips-for-contributing-to-the-swift-language/">a blog post</a> with tips and tricks for contributing to the Swift language!</p>
<p>My talk from try! Swift NYC on Swift’s history, “Taken for Granted”, <a href="https://www.youtube.com/watch?v=ePuOrCbIW-o">was posted</a>. Slides can be found <a href="https://speakerdeck.com/basthomas/taken-for-granted">here</a>.</p>
<p><a href="https://twitter.com/mattt">Mattt</a> wrote <a href="https://nshipster.com/vscode/">a blog post</a> on how to set up Visual Studio Code for Swift development. This is possible thanks to the <a href="https://github.com/apple/sourcekit-lsp">Language Server Protocol</a> that Apple has started working on.</p>
<p><a href="https://twitter.com/simjp">JP Simard</a> wrote <a href="https://jpsim.com/evaluating-swiftsyntax-for-use-in-swiftlint">a blog post</a> about implementing SwiftLint using SwiftSyntax… making it 20x (!) slower.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> merged <a href="https://github.com/apple/swift/pull/20848">a pull request</a> to speed up utf16 Strings!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0234-remove-sequence-subsequence.md">SE-0234</a>: <em>Remove <code class="language-plaintext highlighter-rouge">Sequence.SubSequence</code></em> was <a href="https://forums.swift.org/t/accepted-se-0234-remove-sequence-subsequence/18002">accepted</a>.</p>
<blockquote>
<p>Review feedback was pretty strongly positive. Several community members voiced their experience that attempting to implement the sub-sequence requirements had been an annoyance to them in the past. No-one seemed to feel that the requirements were actually valuable.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0237-contiguous-collection.md">SE-0237</a>: <em>Introduce Contiguous Collection Protocols</em> is <a href="https://forums.swift.org/t/review-of-se-0237-introduce-contiguous-collection-protocols/18069">under review</a>.</p>
<blockquote>
<p>This proposal introduces two new protocols, <code class="language-plaintext highlighter-rouge">ContiguousCollection</code>, and a
mutable version <code class="language-plaintext highlighter-rouge">MutableContiguousCollection</code>. These protocols will allow
generic code to make use of the <code class="language-plaintext highlighter-rouge">withUnsafe{Mutable}BufferPointer</code> idiom,
as well as provide fast paths in the standard library for adopting types.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0238-package-manager-build-settings.md">SE-0238</a>: <em>Package Manager Target Specific Build Settings</em> is <a href="https://forums.swift.org/t/se-0238-package-manager-target-specific-build-settings/18341">under review</a>.</p>
<blockquote>
<p>This is a proposal for adding support for declaring some commonly used target-specific build settings in the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest file. As the name suggests, target-specific build settings are only applied to a particular target.</p>
<p>SwiftPM currently has little facility for customizing how the build tools (compilers, linker, etc.) are invoked during a build. This causes a lot of friction for package authors who want to do some basic customizations in order to build their targets. They often have to resort to awkward workarounds like creating custom modulemaps for linking system libraries, symlinking private headers inside the include directory, changing the include statements, and so on.</p>
<p>We think most of these workarounds can be removed by providing support for some common build settings at the target level. This proposal will also set the stage for a richer build settings API in the future that has support for various conditional expressions, deployment options, inheritance of build settings, etc.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/rudkx">Mark Lacey</a> wrote <a href="https://forums.swift.org/t/pitch-making-expression-type-checking-of-operator-expressions-fast/18037">a proposal pitch</a> to extend operator declarations with designated types, which could address the infamous “expression too complex” problems with operators in Swift.</p>
<blockquote>
<p>Swift’s expression type checker is known to have cases where it is extremely slow in type checking expressions.</p>
<p>Some of these slow typechecking cases involve expressions that make use of operators (whereas others involve collections or chained single-expression closures).</p>
<p>This proposal addresses speeding up type checking for cases that are slow primarily due to the number of combinations of overloads of operators that are examined in the course of typechecking.</p>
</blockquote>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> wrote <a href="https://forums.swift.org/t/lifting-the-self-or-associated-type-constraint-on-existentials/18025">a proposal pitch</a> to lift the “Self or associated type” constraint on existentials.</p>
<blockquote>
<p>When the first seed of Swift came out many years ago, there were technical reasons for the “self or associated type” constraint on protocol existentials: at that time, protocol witness tables did not carry associated type information, so it was impossible to re-open the dynamic type in order to dispatch methods on an existential when a protocol had associated types. This was fixed a while ago in order to allow for recursive protocol constraints, but we held on to the restriction on existentials thinking it would help avoid confusion or design dead ends with people using protocols as existentials in ways that we couldn’t really fully support yet.</p>
<p>However, nowadays we also have protocol extensions, so even if a protocol doesn’t have any core requirements with contravariant Self or associated type arguments, contravariant protocol methods can be added by extensions, so the type system issues unavoidably exist already.</p>
</blockquote>
<p><a href="https://twitter.com/CodaFi_">Robert Widmann</a> wrote <a href="https://forums.swift.org/t/what-should-i-learn-if-i-want-to-contribute-to-the-swift-compiler/18144/4">a post</a> outlining how you can contribute to the Swift compiler.</p>
<blockquote>
<p>C++ is a notoriously dense language that can be a real pain to get a hold on. That said, LLVM-style projects have carved out their own subset of the language, and are very consistent about sticking to that subset. If you want to get a feel for the minutiae, the LLVM Coding Standards document is a great way to get a feel for the aesthetics. If you’re looking for a technical start, including programming patterns, data structures, algorithms, and more, look to the LLVM Programmer’s Manual.</p>
<p>I learn best by doing, so I’m sparse on book recommendations and such, but I think if you spend enough time with it that you can get up and working with LLVM-style structures pretty quickly.</p>
</blockquote>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> shared <a href="https://forums.swift.org/t/revised-se-0235-add-result-to-the-standard-library/18371">an update</a> on the <code class="language-plaintext highlighter-rouge">Result</code> proposal.</p>
<blockquote>
<p>Based on the first round of feedback, the core team agrees that this feature is worth adding to Swift, and we are now looking for feedback on our proposed revisions to the proposal, which are at times substantial.</p>
<p>Thank you for everyone who participated in the first phase of review. Feedback there was generally positive on the idea of standardizing the widely used and reimplemented type.</p>
</blockquote>
<p>The <a href="https://forums.swift.org/t/revised-se-0235-add-result-to-the-standard-library/18371">complete post</a> goes into more detail and is worth a read.</p>
<h3 id="finally">Finally</h3>
<p>Sometimes, Swift <a href="https://twitter.com/alexisgallagher/status/1066559309385883648">is really hard</a>.</p>
Issue #122
https://swiftweeklybrief.com/issue-122
2018-11-15T00:00:00-08:00
2018-11-15T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>We’re very happy to announce that thanks to <a href="https://twitter.com/wongzigii">Zigii Wong</a>, Swift Weekly Brief will be available in Chinese as well! You can go to the website <a href="https://swiftweekly.github.io/cn/">here</a>, and you can contribute in <a href="https://github.com/SwiftWeekly/cn">this repository</a>. 🎉</p>
<p>In other news, there’s a potentially highly anticipated proposal in review, namely one that introduces a <code class="language-plaintext highlighter-rouge">Result</code> type to the Standard Library. 😱</p>
<p>… so go ahead and read all about this and more exciting progress on Swift.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://try.instabug.com/swift-weekly?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_122" target="_blank">The Most Comprehensive Bug Reporting SDK for Swift Apps</a></h4>
<p>The top mobile companies like Lyft, Reddit, and PayPal rely on Instabug to iterate faster and enhance their app quality. Instabug’s lightweight SDK lets you receive detailed bug reports directly from testers and users. A screenshot is attached automatically along with screen recordings, device details and repro-steps with each report. Instabug takes just one line of code to integrate the SDK.<br />Get 20% off for 3 months when you signup and subscribe to any plan. Enter offer code InstabugLovesSwiftWeekly</p>
<p><small><a href="https://try.instabug.com/swift-weekly?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_122" target="_blank">try.instabug.com/swift-weekly</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-9201">SR-9201</a> [Compiler] Incorrect error message when using optional chaining</li>
<li><a href="https://bugs.swift.org/browse/SR-9216">SR-9216</a> [Compiler] Don’t honor SDKROOT in interpreter mode</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/222525">discussed</a> Opaque Result Types, as pitched by Doug Gregor on the forums.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/mattt">Mattt</a> wrote <a href="https://nshipster.com/language-server-protocol/">a blog post</a> about the Language Server Protocol, “arguably the most important decision Apple has made for Swift since releasing the language as open source in 2014”.</p>
<p>SwiftNIO is now available <a href="https://cocoapods.org/pods/SwiftNIO">as a CocoaPod</a>!</p>
<p>Vapor is working on splitting two new libraries out of their core library: <a href="https://github.com/vapor-community/nio-kit">NIOKit</a> and <a href="https://github.com/vapor-community/codable-kit">CodableKit</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/Catfish_Man/">David Smith</a> merged <a href="https://github.com/apple/swift/pull/20383">a pull request</a> that improves String bridging performance!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0233-additive-arithmetic-protocol.md">SE-0233</a>: <em>Make <code class="language-plaintext highlighter-rouge">Numeric</code> Refine a new <code class="language-plaintext highlighter-rouge">AdditiveArithmetic</code> Protocol</em> was <a href="https://forums.swift.org/t/se-0233-make-numeric-refine-a-new-additivearithmetic-protocol/17583">under review</a> and then <a href="https://forums.swift.org/t/accepted-se-0233-make-numeric-refine-a-new-additivearithmetic-protocol/17751/2">accepted</a>.</p>
<blockquote>
<p>This proposal introduces a weakening of the existing <code class="language-plaintext highlighter-rouge">Numeric</code> protocol named <code class="language-plaintext highlighter-rouge">AdditiveArithmetic</code> , which defines additive arithmetic operators and a zero, making conforming types roughly correspond to the mathematic notion of an <a href="https://en.wikipedia.org/wiki/Additive_group">additive group</a>. This makes it possible for vector types to share additive arithmetic operators with scalar types, which enables generic algorithms over <code class="language-plaintext highlighter-rouge">AdditiveArithmetic</code> to apply to both scalars and vectors.</p>
</blockquote>
<blockquote>
<p>Feedback on the proposal was light but all positive, and the proposal was accepted without modifications. The core team discussed moving the unary + member, but ended up agreeing with the proposal as written.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0229-simd.md">SE-0229</a>: <em>SIMD Vectors, Take 2</em> was <a href="https://forums.swift.org/t/se-0229-simd-vectors/16518/99">returned for revision</a>.</p>
<blockquote>
<p>The proposal and implementation have been updated.</p>
<p>To summarize how the proposal has changed:</p>
<ul>
<li>The primary working types are now spelled like <code class="language-plaintext highlighter-rouge">Vector3<T></code> instead of the earlier <code class="language-plaintext highlighter-rouge">T.Vector3</code>.</li>
<li>Initializers from any <code class="language-plaintext highlighter-rouge">Sequence</code> with the right element type are now provided.</li>
<li>All mask operations are <code class="language-plaintext highlighter-rouge">.</code>-prefixed</li>
<li><code class="language-plaintext highlighter-rouge">count</code> has been renamed <code class="language-plaintext highlighter-rouge">elementCount</code></li>
<li>The general swizzle / shuffle / permute operation <code class="language-plaintext highlighter-rouge">init(gathering: at:)</code> has been removed. We intend to restore it in a later proposal with a better name.</li>
<li>Users can make <code class="language-plaintext highlighter-rouge">VectorN<T></code> available for arbitrary types <code class="language-plaintext highlighter-rouge">T</code> by conforming <code class="language-plaintext highlighter-rouge">T</code> to a new <code class="language-plaintext highlighter-rouge">SIMDVectorizable</code> protocol, which has very basic requirements.</li>
<li>The any and all and <code class="language-plaintext highlighter-rouge">min</code>, <code class="language-plaintext highlighter-rouge">max</code>, and <code class="language-plaintext highlighter-rouge">clamp</code> free functions have been removed. We intend to re-introduce this functionality (possibly with different bindings) in a follow-on proposal.</li>
<li>The <code class="language-plaintext highlighter-rouge">IntegerVector</code> and <code class="language-plaintext highlighter-rouge">FloatingPointVector</code> protocols have been removed and replaced with conditional conformances.</li>
</ul>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0231-optional-iteration.md">SE-0231</a>: <em>Optional Iteration</em> was <a href="https://forums.swift.org/t/rejected-se-0231-optional-iteration/17805">rejected</a>.</p>
<blockquote>
<p>Although the core team agrees that iterating through collections wrapped in <code class="language-plaintext highlighter-rouge">Optional</code> is a common enough occurrence to be worth providing affordances in the language for, it has decided to reject the proposal as written.</p>
</blockquote>
<p>I’d encourage to read the <a href="https://forums.swift.org/t/rejected-se-0231-optional-iteration/17805">full rationale</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0235-add-result.md">SE-0235</a>: <em>Add Result to the Standard Library</em> is <a href="https://forums.swift.org/t/se-0235-add-result-to-the-standard-library/17752">under review</a>.</p>
<blockquote>
<p>Swift’s current error-handling, using <code class="language-plaintext highlighter-rouge">throws</code>, <code class="language-plaintext highlighter-rouge">try</code>, and <code class="language-plaintext highlighter-rouge">catch</code>, offers automatic and synchronous handling of errors through explicit syntax and runtime behavior. However, it lacks the flexibility needed to cover all error propagation and handling in the language. <code class="language-plaintext highlighter-rouge">Result</code> is a type commonly used for manual propagation and handling of errors in other languages and within the Swift community. Therefore this proposal seeks to add such a type to the Swift standard library.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0236-package-manager-platform-deployment-settings.md">SE-0236</a>: <em>Package Manager Platform Deployment Settings</em> is <a href="https://forums.swift.org/t/se-0236-package-manager-platform-deployment-settings/17992">under review</a>.</p>
<blockquote>
<p>This is a proposal for adding support for specifying a per-platform minimum required deployment target in the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest file.</p>
<p>Packages should be able to declare the minimum required platform deployment target version. SwiftPM currently uses a hardcoded value for the macOS deployment target. This creates friction for packages which want to use APIs that were introduced after the hardcoded deployment target version.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> shared <a href="https://forums.swift.org/t/string-s-abi-and-utf-8/17676">String’s proposed Application Binary Interface (ABI)</a> and that native Swift strings will be stored as UTF-8!</p>
<blockquote>
<p>We just landed String’s proposed final ABI on master. This ABI includes some significant changes, the primary one being that native Swift strings are stored as UTF-8 where they were previously stored either as ASCII or UTF-16 depending on their contents. <code class="language-plaintext highlighter-rouge">NSString</code>s are still lazily bridged in to String without copying.</p>
<p>This does not immediately surface in the API, but allows for some important performance wins and gives a more consistent basis for future APIs providing efficient and direct access to the underlying code units. UTF-8 is a one-byte Unicode encoding and is the preferred encoding for interoperating with C, systems programming, server-side programming, scripting, client-side programming, and tools that process source code and textual formats.</p>
</blockquote>
<p>With this change, the Standard Library’s binary is around 13% smaller as well!</p>
<p>Vapor is <a href="https://forums.swift.org/t/niokit-codablekit/17706">splitting out</a> two new libraries from its core library.</p>
<blockquote>
<p>We’re starting work on two new packages that will debut with Vapor 4. <a href="https://github.com/vapor-community/nio-kit">NIOKit</a> and <a href="https://github.com/vapor-community/codable-kit">CodableKit</a>. The goal of these packages is to break out a lot of utilities Vapor has developed over the past two years in our Core 1 repo. This repo has grown quite large and contains a lot of things we think would be useful to the Server community as a whole, not tied to Vapor.</p>
</blockquote>
<p><a href="https://twitter.com/johannesweiss/">Johannes Weiss</a> shared <a href="https://forums.swift.org/t/plan-for-nio-2-and-swift-5/17791">the plan</a> for SwiftNIO 2 and how that ties into Swift 5.</p>
<blockquote>
<p>As I’m sure you are aware, the first Swift 5 branches will be cut soon and needless to say SwiftNIO wants to be able to make full use of the new features/improvements upcoming in Swift 5 (for example native UTF8 <code class="language-plaintext highlighter-rouge">String</code>s). On top that, SwiftNIO already accumulated <a href="https://github.com/apple/swift-nio/issues?q=is%3Aopen+is%3Aissue+milestone%3A2.0.0">a number of issues/pull requests</a> that can only be addressed with a new major SwiftNIO 2.0.0 release.</p>
<p>Our plan is to therefore release SwiftNIO 2.0 together with Swift 5.0. NIO 2 will require Swift 5 and will be a breaking release. Don’t expect everything to break when you need to migrate from NIO 1 to NIO 2 but there will be likely a number of things that can hopefully be fixed mostly through search & replace. We will maintain a list of changes with strategies to resolve this.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/AirspeedSwift/status/1060266652326027264">I</a> love <a href="https://twitter.com/HarshilShah1910/status/1061528775337291776">this</a> <code class="language-plaintext highlighter-rouge">Result</code> type!</p>
Issue #121
https://swiftweeklybrief.com/issue-121
2018-11-01T00:00:00-07:00
2018-11-01T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It’s November! The days get shorter, and the end of year is creeping up. Swift 5 is drawing nearer.
This issue is also guaranteed not to be spooky.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8937">SR-8937</a> [Compiler] Switch over <code class="language-plaintext highlighter-rouge">T?</code> fixit does not use syntactic sugar</li>
<li><a href="https://bugs.swift.org/browse/SR-8960">SR-8960</a> [Compiler] Emit a symbol reference to ensure swiftrt.o is linked on Linux/Windows</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p>Apple released Xcode 10.1, along with <a href="https://developer.apple.com/documentation/xcode_release_notes/xcode_10_1_release_notes#3036305">Swift 4.2.1</a>. It includes an overview of what’s new in this Swift version.</p>
<p><a href="https://twitter.com/aciidb0mb3r/">Ankit Aggarwal</a> shared <a href="https://twitter.com/aciidb0mb3r/status/1055190174231973889">that SwiftPM can now generate code coverage data</a>!</p>
<p><a href="https://twitter.com/dgregor79/">Doug Gregor</a> and <a href="https://twitter.com/AirspeedSwift">Ben Cohen</a>’s talk <a href="https://developer.apple.com/videos/play/wwdc2018/406/">on generics</a> at WWDC has been expanded to include an all-new section on recursive constraints, associated type and protocol where clauses, and divide-and-conquer algorithms. It starts at around 33 minutes. Highly recommended; very insightful!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/19947">a pull request</a> that replaces one of the last remaining places where curry levels were still used by diagnostics.</p>
<p><a href="https://twitter.com/rintaro">Rintaro Ishizaki</a> merged <a href="https://github.com/apple/swift/pull/20066">a pull request</a> that improves completion for the index part of a subscript expression, allowing the compiler to help you use more complex subscripts.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0230-flatten-optional-try.md">SE-0230</a>: <em>Flatten nested optionals resulting from <code class="language-plaintext highlighter-rouge">try?</code></em> was <a href="https://forums.swift.org/t/accepted-se-230-flatten-nested-optionals-resulting-from-try/17376">accepted</a>.</p>
<blockquote>
<p>The Core Team does not want to make source-incompatible changes lightly, but we also want to leave room to improve the language for future users of Swift. We don’t have a bright-line rule for when a change crosses the line to become unacceptable, but the key consideration in our analysis is the change’s apparent impact in practice on existing code more than its hypothetical risks. In this case, we are convinced that the change leads to fairly inarguably better results.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0232-remove-customization-points.md">SE-0232</a>: <em>Remove Some Customization Points from the Standard Library’s <code class="language-plaintext highlighter-rouge">Collection</code> Hierarchy</em> was <a href="https://forums.swift.org/t/se-0232-remove-some-customization-points-from-the-standard-librarys-collection-hierarchy/17265">under review</a>.</p>
<blockquote>
<p>This proposal removes four customization points from protocols in the
standard library:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">map</code>, <code class="language-plaintext highlighter-rouge">filter</code>, and <code class="language-plaintext highlighter-rouge">forEach</code> from <code class="language-plaintext highlighter-rouge">Sequence</code></li>
<li><code class="language-plaintext highlighter-rouge">first</code>, <code class="language-plaintext highlighter-rouge">prefix(upTo:)</code>, <code class="language-plaintext highlighter-rouge">prefix(through:)</code>, and <code class="language-plaintext highlighter-rouge">suffix(from:)</code> from <code class="language-plaintext highlighter-rouge">Collection</code></li>
<li><code class="language-plaintext highlighter-rouge">last</code> on <code class="language-plaintext highlighter-rouge">BidirectionalCollection</code></li>
</ul>
<p>The default implementations of these symbols will remain, so sequences and
collections will continue to have the same operations available that they
do today.</p>
</blockquote>
<p>… and has been <a href="https://forums.swift.org/t/se-0232-remove-some-customization-points-from-the-standard-librarys-collection-hierarchy/17265/16">accepted</a>.</p>
<blockquote>
<p>The Core Team has decided to accept the proposal as written (with the refinements incorporated during the review).</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/jshier">Jon Shier</a> wrote <a href="https://forums.swift.org/t/adding-result-ii-unconstrained-boogaloo/17128">a second pitch</a> to add a <code class="language-plaintext highlighter-rouge">Result</code> type to the standard library.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">Result</code> is considered generally useful enough to be included in the standard library. However, in the past, strenuous disagreement between the typed and untyped-throws camps has prevented consensus on the exact form it should take.</p>
<p>To kick off another round of discussion, and before I update my proposal officially, I’d like to discuss the form that was brought up late in the last discussion:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">enum</span> <span class="kt">Result</span><span class="o"><</span><span class="kt">Value</span><span class="p">,</span> <span class="kt">Error</span><span class="o">></span> <span class="p">{</span>
<span class="k">case</span> <span class="nf">success</span><span class="p">(</span><span class="kt">Value</span><span class="p">),</span> <span class="nf">failure</span><span class="p">(</span><span class="kt">Error</span><span class="p">)</span>
<span class="p">}</span></code></pre></figure>
<p>The proposal can be found <a href="https://github.com/apple/swift-evolution/pull/937">here</a>.</p>
<h3 id="finally">Finally</h3>
<p>How to learn all about generics <a href="https://twitter.com/AirspeedSwift/status/1057357660792573952">with this one easy trick</a>!</p>
Issue #120
https://swiftweeklybrief.com/issue-120
2018-10-18T00:00:00-07:00
2018-10-18T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A packed week with some exciting announcements. And an Apple event coming up on October 30th. <em>And</em> Swift Unwrapped is back! Cool stuff.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8788">SR-8788</a> [Compiler] Rethrowing/convenience initializer does not compile</li>
<li><a href="https://bugs.swift.org/browse/SR-8811">SR-8811</a> [Compiler] Diagnosing Implicit Accessors for Uninhabited Types Should Be Smarter</li>
<li><a href="https://bugs.swift.org/browse/SR-8905">SR-8905</a> [Standard Library] Gaps in String benchmarking</li>
<li><a href="https://bugs.swift.org/browse/SR-8908">SR-8908</a> [Standard Library] Add <code class="language-plaintext highlighter-rouge">insert(_:Character)</code> benchmarks in <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code></li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Swift Unwrapped is back! In episode 67, Jesse and JP <a href="https://spec.fm/podcasts/swift-unwrapped/212093">discuss</a> Raw Strings.</p>
<h3 id="news-and-community">News and community</h3>
<p>FoundationDB has <a href="https://www.foundationdb.org/blog/official-swift-bindings-for-foundationdb/">announced</a> official Swift bindings!</p>
<p>Jetbrains added <a href="https://blog.jetbrains.com/objc/2018/10/spm-support-clion/">support</a> for the Swift Package Manager in their C IDE, CLion.</p>
<p><a href="https://twitter.com/aciidb0mb3r/">Ankit Aggarwal</a> wrote <a href="https://swift.org/blog/swiftpm-repl-support/">a blog post</a> now that Swift Packages have Read Evaluate Print Loop (REPL) support!</p>
<p><a href="https://github.com/rxwei">Richard Wei</a> wrote <a href="https://gist.github.com/rxwei/30ba75ce092ab3b0dce4bde1fc2c9f1d">a manifesto</a> on first-class automatic differentiation in Swift, written for both the machine learning community and the Swift programming language design community, with a strong focus on language design.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov/">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/19844">a pull request</a> that fixes crashes and allows both spellings for protocols with <code class="language-plaintext highlighter-rouge">where</code> clauses. If you would like to know more, see <a href="https://twitter.com/slava_pestov/status/1050571783026266118">this</a> thread.</p>
<p><a href="https://twitter.com/dgregor79/">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/19828">a pull request</a> replacing associated type metadata accessors with mangled strings, bringing both code size and runtime performance improvements!</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0229-simd.md">SE-0229</a>: <em>SIMD Vectors</em> is <a href="https://forums.swift.org/t/se-0229-simd-vectors/16518/97">intended to be accepted</a>.</p>
<blockquote>
<p>The core team feels this is an important addition to the language that will open up SIMD programming to a wide audience in an approachable way.</p>
<p>The majority of the feedback received during the thread was regarding the alternate “generic” spelling: <code class="language-plaintext highlighter-rouge">Vector3<Int8></code> rather than <code class="language-plaintext highlighter-rouge">Int8.Vector3</code>.</p>
<p>It is still unclear which is the better form. However, in order to better make the decision, the core team has asked the proposal author to implement a prototype showing the alternate form. Reviewers will then be able to try out either form in order to help make the decision.</p>
<p>In addition, the proposal should be revised to spell out more explicitly some of the details, for example, of what masks are and the role they play.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0231-optional-iteration.md">SE-0231</a>: <em>Optional Iteration</em> is <a href="https://forums.swift.org/t/se-0231-optional-iteration/16737">under review</a>.</p>
<blockquote>
<p>Optionals are a key feature of Swift and a powerful tool that seamlessly interacts with code. In particular, they serve a great means in expressing “act accordingly if there’s a value, skip otherwise”. Some vivid examples of such behavior are optional chaining, optional invocation <code class="language-plaintext highlighter-rouge">foo?()</code>, <code class="language-plaintext highlighter-rouge">if let</code>, <a href="https://docs.swift.org/swift-book/ReferenceManual/Patterns.html#grammar_optional-pattern">optional patterns</a>, optional assignments and <code class="language-plaintext highlighter-rouge">guard let</code>. This proposal considers further supporting this convenience in <code class="language-plaintext highlighter-rouge">for-in</code> loops.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/akyrtzi">Argyrios Kyrtzidis</a> announced <a href="https://forums.swift.org/t/new-lsp-language-service-supporting-swift-and-c-family-languages-for-any-editor-and-platform/17024">Language Service Protocol support</a> for Swift and C-family languages!</p>
<blockquote>
<p>At Apple we are making it a priority to support high-quality tooling for all Swift developers, including those working on non-Apple platforms. We want to collaborate with the open-source community and focus our efforts on building common infrastructure that can be shared by Xcode and other editors and platforms.</p>
<p>To that end, I’m excited to announce that we are going to start a new open-source project for a Swift and C-family language service based on the <a href="https://microsoft.github.io/language-server-protocol">Language Server Protocol</a>. We’ve chosen to adopt LSP so we can benefit from its active community and wide adoption across other editors and platforms. This means that Visual Studio Code, Atom, Sublime Text, or whatever your favorite editor happens to be, can use the same service as Xcode, and any improvements we make to the service will benefit them all.</p>
</blockquote>
<blockquote>
<p>To add to what Ben mentioned, the new service will be written in Swift so it could use SwiftSyntax and any other functionality written on top of SwiftSyntax, like formatting.</p>
</blockquote>
<p><a href="https://twitter.com/xge_apple">Xi Ge</a> announced <a href="https://forums.swift.org/t/abi-stability-checker-is-now-online-for-the-swift-standard-library">an ABI stability checker</a> for the Swift standard library.</p>
<blockquote>
<p>We’ve started testing the ABI stability of the Swift standard library as part of Swift regression testing.</p>
<p>[It] will check whether the change has broken the ABI stability of a previously checked-in <a href="https://github.com/apple/swift/blob/master/test/api-digester/Inputs/stdlib-stable-abi.json">baseline</a>. If it does, a test failure will occur in <a href="https://github.com/apple/swift/blob/master/test/api-digester/stability-stdlib-abi.swift"><code class="language-plaintext highlighter-rouge">stability-stdlib-abi.swift</code></a>. To resolve this test failure, we can either update the expected ABI breakage list in <a href="https://github.com/apple/swift/blob/master/test/api-digester/Outputs/stability-stdlib-abi.swift.expected"><code class="language-plaintext highlighter-rouge">stability-stdlib-abi.swift.expected</code></a> or update the PR to remedy those breakages.</p>
</blockquote>
<p><a href="https://twitter.com/stephentyrone">Steve Canon</a> pitched [a proposal(https://forums.swift.org/t/comparable-and-floatingpoint-types/16886) regarding comparability of Floating point types.</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">Comparable</code> and <code class="language-plaintext highlighter-rouge">Equatable</code> protocols want to imply a total order. This is mostly satisfied by <code class="language-plaintext highlighter-rouge">FloatingPoint</code> types, except for the behavior with <code class="language-plaintext highlighter-rouge">NaN</code>s. A total order requires that for any <code class="language-plaintext highlighter-rouge">a</code> and <code class="language-plaintext highlighter-rouge">b</code>, either <code class="language-plaintext highlighter-rouge">a ≤ b</code> or <code class="language-plaintext highlighter-rouge">a ≥ b</code> is true. But IEEE 754 requires that if either <code class="language-plaintext highlighter-rouge">a</code> or <code class="language-plaintext highlighter-rouge">b</code> is <code class="language-plaintext highlighter-rouge">NaN</code>, both of those comparisons are false.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>How to write <a href="https://twitter.com/AirspeedSwift/status/1051860332740661248">a proposal</a>.</p>
Issue #119
https://swiftweeklybrief.com/issue-119
2018-10-04T00:00:00-07:00
2018-10-04T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>We’re very happy to re-introduce the newsletter’s mail subscriptions, so that you can once again receive Swift Weekly Brief in your inbox. If you haven’t yet and are interested, you can subscribe <a href="https://swiftweeklybrief.com/subscribe/">here</a>.</p>
<p>Enjoy the newsletter and have a great weekend and week!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://do-ios.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_119" target="_blank">Do iOS conference in Amsterdam</a></h4>
<p>On November 2 come join us for Do iOS. This is its third edition. Now fully owned and ran by the Dutch CocoaHeads Foundation. Come and join 130 fellow iOS developers for a day filled with content. Come and meet your fellow iOS developers.<br /><br />There is also a University Day available on November 1.<br /><br />More info and tickets on</p>
<p><small><a href="https://do-ios.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_119" target="_blank">do-ios.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8703">SR-8703</a> [Tensorflow] Deabstraction should properly diagnose recursion</li>
<li><a href="https://bugs.swift.org/browse/SR-8706">SR-8706</a> [Compiler] Fix up <code class="language-plaintext highlighter-rouge">parseDependencyFile</code> to not crash on invalid YAML</li>
<li><a href="https://bugs.swift.org/browse/SR-8707">SR-8707</a> [Compiler] Write out swiftdeps files atomically</li>
<li><a href="https://bugs.swift.org/browse/SR-8720">SR-8720</a> [Package Manager] Add –hide-build option to <code class="language-plaintext highlighter-rouge">swift run</code></li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> has written <a href="https://swift.org/blog/5-0-release-process/">an overview</a> of the release process of Swift 5.0, including the goals and an estimated schedule.</p>
<p><a href="https://twitter.com/mikeash">Mike Ash</a> wrote <a href="https://swift.org/blog/how-mirror-works/">a blog post</a> on the Swift.org blog, explaining how <code class="language-plaintext highlighter-rouge">Mirror</code> works.</p>
<p><a href="https://twitter.com/timacfr">Timac</a> wrote <a href="https://blog.timac.org/2018/0924-state-of-swift-ios12/">a blog post</a> that measures Apple’s use of Swift in iOS 12. 66 binaries are now using Swift! 🎉</p>
<p><a href="https://twitter.com/rockthebruno">Bruno Rocha</a> wrote <a href="https://swiftrocks.com/how-caseiterable-works-internally-in-swift.html">a blog post</a> on how Swift 4.2’s <code class="language-plaintext highlighter-rouge">CaseIterable</code> works internally.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/millenomi">Lily Vulcano</a> opened <a href="https://github.com/apple/swift-corelibs-foundation/pull/1708">a pull request</a> that merges improvements from the Core Foundation version found in Mojave and iOS 12 into Swift Foundation.</p>
<p><a href="https://twitter.com/albert_keyj">Albert Aleksieiev</a> merged <a href="https://github.com/apple/swift-nio/pull/609">a pull request</a> that adds Android support to SwiftNIO! 💪</p>
<p><a href="https://twitter.com/gottesmang">Michael Gottesman</a> merged <a href="https://github.com/apple/swift/pull/19690">a pull request</a> bringing performance improvements to the standard library. 🏎</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0221-character-properties.md">SE-0221</a>: <em>Character Properties</em> was <a href="https://forums.swift.org/t/accepted-with-modification-se-0221-character-properties/14944/3">accepted with modifications</a>.</p>
<blockquote>
<p>The core team has resolved to change the status of this proposal to <strong>accepted</strong> with modification, deferring the <code class="language-plaintext highlighter-rouge">.isEmoji</code> property to a later proposal.</p>
<p>The core team still believe it is a useful feature for the standard library, but needs more investigation that should not hold up the rest of this proposal.</p>
<p>In addition, the proposal will drop the source-breaking change to the existing <code class="language-plaintext highlighter-rouge">FixedWidthInteger.init?</code>. While this would be the preferred naming for a newly proposed initializer, it doesn’t clear the bar for a source-breaking change for Swift 5.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0228-fix-expressiblebystringinterpolation.md">SE-0228</a>: <em>Fix <code class="language-plaintext highlighter-rouge">ExpressibleByStringInterpolation</code></em> was <a href="https://forums.swift.org/t/accepted-se-0228-fix-expressible-by-string-interpolation/16548">accepted with a small amendment</a>.</p>
<blockquote>
<p>Feedback was overwhelmingly positive, and the proposal is accepted with <a href="https://github.com/apple/swift-evolution/pull/909">one small amendment</a> to provide a default implementation of <code class="language-plaintext highlighter-rouge">init(stringLiteral:)</code> for types that conform to <code class="language-plaintext highlighter-rouge">ExpressibleByStringInterpolation</code>.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0229-simd.md">SE-0229</a>: <em><code class="language-plaintext highlighter-rouge">simd</code> vectors</em> is <a href="https://forums.swift.org/t/se-0229-simd-vectors/16518">under review</a>.</p>
<blockquote>
<p>This proposal would expose a common subset of operations on the SIMD types supported by most processors in the standard library. It is based on Apple’s <code class="language-plaintext highlighter-rouge"><simd/simd.h></code> module, which is used throughout Apple’s platforms as the common currency type for fixed-size vectors and matrices. It is not a complete re-implementation; rather it provides the low-level support needed to import any such library, and tries to make a number of things much nicer in Swift than they are in C or C++.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0230-flatten-optional-try.md">SE-0230</a>: <em>Flatten nested optionals resulting from <code class="language-plaintext highlighter-rouge">try?</code></em> is <a href="https://forums.swift.org/t/se-0230-flatten-nested-optionals-resulting-from-try/16570">under review</a>.</p>
<blockquote>
<p>Swift’s <code class="language-plaintext highlighter-rouge">try?</code> statement currently makes it easy to introduce a
nested optional. Nested optionals are difficult for users to reason
about, and Swift tries to avoid producing them in other common cases.</p>
<p>This document proposes giving <code class="language-plaintext highlighter-rouge">try?</code> the same optional-flattening
behavior found in other common Swift features, to avoid the common
occurrence of a nested optional.</p>
<p>It’s currently quite easy to end up with a nested <code class="language-plaintext highlighter-rouge">Optional</code> type when
using <code class="language-plaintext highlighter-rouge">try?</code>. Although it is valid to construct a nested optional, it
is usually not what the developer intended.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Alejandro Alonso pitched <a href="https://forums.swift.org/t/default-implementation-in-protocols/15794">a proposal</a> to make it easier to have default implementations in protocols, without the need of an extension.</p>
<blockquote>
<p>I’ve been working on implementing Default Implementation in Protocols and I have a working early implementation of the feature.</p>
<p>What this feature allows is that you can now declare a default implementation of a requirement from the protocol:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">protocol</span> <span class="kt">Animal</span> <span class="p">{</span>
<span class="kd">func</span> <span class="nf">makeNoise</span><span class="p">()</span> <span class="p">{</span>
<span class="nf">print</span><span class="p">(</span><span class="s">"Bark!"</span><span class="p">)</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="kd">struct</span> <span class="kt">Dog</span><span class="p">:</span> <span class="kt">Animal</span> <span class="p">{}</span>
<span class="k">let</span> <span class="nv">sparky</span> <span class="o">=</span> <span class="kt">Dog</span><span class="p">()</span>
<span class="n">sparky</span><span class="o">.</span><span class="nf">makeNoise</span><span class="p">()</span> <span class="c1">// Bark!</span></code></pre></figure>
<p>Peter Camb shared <a href="https://forums.swift.org/t/anyobject-parameter-cannot-assign-to-immutable-expression/16642">an issue</a>, which is a bug in Swift that can currently not be solved through Swift iself.</p>
<blockquote>
<p>I’m hitting this issue in my NSOpenSavePanelDelegate in a Sandboxed Mac app.</p>
<p>I need to get a reference to the sender as a Panel and set the directory.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="cm">/* NSSavePanel/NSOpenPanel: Gets and sets the directoryURL shown. */</span>
<span class="kd">@available</span><span class="p">(</span><span class="kt">OSX</span> <span class="mf">10.6</span><span class="p">,</span> <span class="o">*</span><span class="p">)</span>
<span class="kd">open</span> <span class="k">var</span> <span class="nv">directoryURL</span><span class="p">:</span> <span class="kt">URL</span><span class="p">?</span></code></pre></figure>
<blockquote>
<p>All of my <code class="language-plaintext highlighter-rouge">as?</code> casts fail because the Sandbox uses a private subclass for these items.</p>
</blockquote>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a>:</p>
<blockquote>
<p>This is a longstanding bug, but it looks like we don’t have a JIRA bug for it. [..] it’s very similar to SR-5475 (which is about optional properties of protocols). I don’t think we have a good workaround other than defining a little static inline function in Objective-C that will do the call for you without trying to check anything.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-objc" data-lang="objc"><span class="n">NS_SWIFT_NAME</span><span class="p">(</span><span class="n">setDirectoryURL</span><span class="p">(</span><span class="n">_</span><span class="o">:</span><span class="k">for</span><span class="o">:</span><span class="p">))</span>
<span class="k">static</span> <span class="kr">inline</span> <span class="kt">void</span> <span class="nf">setDirectoryURLForPanel</span><span class="p">(</span><span class="n">id</span> <span class="n">panel</span><span class="p">,</span> <span class="n">NSURL</span> <span class="o">*</span> <span class="n">_Nonnull</span> <span class="n">url</span><span class="p">)</span> <span class="p">{</span>
<span class="n">NSSavePanel</span> <span class="o">*</span><span class="n">realPanel</span> <span class="o">=</span> <span class="p">(</span><span class="n">NSSavePanel</span> <span class="o">*</span><span class="p">)</span><span class="n">panel</span><span class="p">;</span>
<span class="n">realPanel</span><span class="p">.</span><span class="n">directoryURL</span> <span class="o">=</span> <span class="n">url</span><span class="p">;</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>An alternate approach in this specific case would be to file a bug against Apple that the sender here is not an instance of <code class="language-plaintext highlighter-rouge">NSOpenPanel</code> or at least <code class="language-plaintext highlighter-rouge">NSSavePanel</code>.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Making all sorts of progress <a href="https://twitter.com/clattner_llvm/status/1044802613345218563">on variadic generics</a>. 🦄</p>
Issue #118
https://swiftweeklybrief.com/issue-118
2018-09-20T00:00:00-07:00
2018-09-20T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>So the lovely Greg took over last issue as I was at a conference, <a href="https://www.tryswift.co/events/2018/nyc/">try! Swift NYC</a>. I’ve had an amazing time at the conference (and New York) where I gave <a href="https://speakerdeck.com/basthomas/taken-for-granted">a talk</a> about the history of Swift. A video of that talk will be posted in the future.</p>
<p>A big thank you goes out to the organizers, the volunteers and all of those who I got to meet at the conference!</p>
<hr />
<p>We are also working on bringing back <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/410">subscriptions via email</a>. To cover the associated costs, we are looking for sponsors again.</p>
<p>We’re sharing more details soon. If you or your company are interested in sponsoring the newsletter, please send me a direct message <a href="https://twitter.com/basthomas">on Twitter</a>.</p>
<hr />
<p>That being said, and without further ado, here is an update on everything Swift from the past two weeks.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8625">SR-8625</a> [Compiler] Swift should warn if a closures is passed to an argument that is an <code class="language-plaintext highlighter-rouge">autoclosure</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8645">SR-8645</a> [Package Manager] BuildPlan error descriptions aren’t printed</li>
<li><a href="https://bugs.swift.org/browse/SR-8646">SR-8646</a> [Package Manager] <code class="language-plaintext highlighter-rouge">BuildPlan.Error.missingLinuxMain</code> description rephrasing</li>
<li><a href="https://bugs.swift.org/browse/SR-8671">SR-8671</a> [Package Manager] <code class="language-plaintext highlighter-rouge">ARG_MAX</code> limit exceeded when compiles huge project</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p>Xcode 10 has been released, and alongside came Swift 4.2. <a href="https://twitter.com/tkremenek">Ted Kremenek</a> wrote <a href="https://swift.org/blog/swift-4-2-released/">a blog post</a> describing the changes in detail.</p>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> did us all another huge favor by means of a What’s new in Swift 4.2 <a href="https://oleb.net/blog/2018/06/whats-new-in-swift-4-2-playground/">Playground</a>. You should definitely give this a try if you want a quick and interactive overview of the new features in Swift 4.2.</p>
<p>On a related note, <a href="https://twitter.com/twostraws">Paul Hudson</a> wrote about what’s new <a href="https://www.hackingwithswift.com/articles/126/whats-new-in-swift-5-0">in Swift 5</a>. Besides ABI stability, there are some other interesting new improvements and features expected in that release. Swift 5 is expected to be released early 2019.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/pyaskevich">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/19203">a pull request</a> making the constraint solver iterative rather than recursive, which should fix some stack overflow issues.</p>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> merged <a href="https://github.com/apple/swift/pull/19382">a pull request</a> that finishes up the implementation of SE-0227 (see below). “Now we’re just waiting for tuple keypaths so we can have full parity between member access syntax and keypath syntax.” 🎉</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0227-identity-keypath.md">SE-0227</a>: <em>Identity key path</em> was <a href="https://forums.swift.org/t/accepted-se-0227-identity-key-path/16278">accepted</a>.</p>
<blockquote>
<p>Feedback on the proposal was light but all positive, and the proposal was accepted without modifications.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0228-fix-expressiblebystringinterpolation.md">SE-0228</a>: <em>Fix <code class="language-plaintext highlighter-rouge">ExpressibleByStringInterpolation</code></em> is <a href="https://forums.swift.org/t/se-0228-fix-expressible-by-string-interpolation/16031">under review</a>.</p>
<blockquote>
<p>String interpolation is a simple and powerful feature for expressing complex, runtime-created strings, but the current version of the <code class="language-plaintext highlighter-rouge">ExpressibleByStringInterpolation</code> protocol has been deprecated since Swift 3. We propose a new design which improves its performance, clarity, and efficiency.</p>
<p>We see three general classes of types which might want to conform to <code class="language-plaintext highlighter-rouge">ExpressibleByStringInterpolation</code>:</p>
<ol>
<li>Simple textual data</li>
<li>Structured textual data</li>
<li>Machine-readable code fragments</li>
</ol>
<p>The current design handles simple textual data, but struggles to support structured textual data and machine-readable code fragments.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared <a href="https://forums.swift.org/t/next-steps-for-the-swift-server-work-group/15816">the next steps for the Swift Server work group</a>.</p>
<blockquote>
<p>As announced at try! Swift New York City, the Swift Server work group is now entering a new chapter in its evolution. With the release of SwiftNIO and it’s subsequent adoption by popular Swift web frameworks, Kitura and Vapor, the group is now ready to take on new tasks. It’s time to focus on defining and creating a set of libraries and tools that are focused on developing and deploying server applications written in Swift.</p>
<p>Read more about the new focus on the updated <a href="https://swift.org/server/">Swift Server work group page</a>.</p>
</blockquote>
<p><a href="https://github.com/tomerd">Tomer Doron</a> shared <a href="https://forums.swift.org/t/server-work-group-new-focus-areas/15969">new focus areas</a> for the Swift Server work group.</p>
<blockquote>
<p>[..] the work group came up with the following focus areas which we feel can make a real and immediate impact on the ecosystem. The list reflects what we previously heard from the community as well as our own personal experience writing server applications with Swift, and is designed to solve tangible needs that do not require new features from the language or core libraries.</p>
<ul>
<li>Database Drivers and Storage Clients</li>
<li>Tooling and Production Readiness</li>
<li>Distributed Systems, Microservices and Event Driven Architecture</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/xwu">Xiaodi Wu</a> shared news <a href="https://forums.swift.org/t/notes-on-numerics-in-swift/15746">about a number of blog posts</a> that go into detail of how numeric types work in Swift.</p>
<blockquote>
<p>A great number of questions are raised in these forums as to the functioning and design of numeric types and protocols in Swift. Sometimes, the answer can be found only by digging through the source code, and even then it’s hard to place what you learn there within a larger context. Therefore, I’ve compiled a series of articles that delve into these topics in more detail.</p>
</blockquote>
<p>You can find the blog posts <a href="https://numerics.diploid.ca">here</a>.</p>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> pitched <a href="https://forums.swift.org/t/allow-self-x-in-class-convenience-initializers/15924">a proposal</a> to allow <code class="language-plaintext highlighter-rouge">self = x</code> in class convenience initializers.</p>
<blockquote>
<p>In <a href="https://github.com/apple/swift/pull/19151">this pull request</a>, I’m changing code generation for class convenience initializers so that they only have “allocating” entry points, which are responsible for allocating and initializing the entire object. (See <a href="https://forums.swift.org/t/changing-class-convenience-initializers-to-perform-whole-object-allocation-and-objc-interop/15676">Changing class convenience initializers to perform whole object allocation and <code class="language-plaintext highlighter-rouge">@objc</code> interop</a> for more background.) With this change, convenience initializers are nearly identical to value or protocol extension initializers at the implementation level, since the <code class="language-plaintext highlighter-rouge">self.init</code> delegation within a convenience initializer is effectively initializing the self <em>reference</em> with a reference to the instance created by the <code class="language-plaintext highlighter-rouge">self.init</code> call rather than initializing the instance itself. At this point, it’s not that big of a leap to allow the <code class="language-plaintext highlighter-rouge">self</code> reference to also be initialized by assignment, as it can be in value and protocol extension initializers, like this:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">class</span> <span class="kt">Y</span> <span class="p">{</span>
<span class="kd">required</span> <span class="nf">init</span><span class="p">()</span> <span class="p">{}</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="nf">singletonInstance</span><span class="p">()</span> <span class="o">-></span> <span class="k">Self</span> <span class="p">{</span> <span class="k">return</span> <span class="k">self</span><span class="o">.</span><span class="nf">init</span><span class="p">()</span> <span class="p">}</span>
<span class="kd">convenience</span> <span class="nf">init</span><span class="p">(</span><span class="nv">pref</span><span class="p">:</span> <span class="kt">Y</span><span class="p">)</span> <span class="p">{</span>
<span class="k">self</span> <span class="o">=</span> <span class="nf">type</span><span class="p">(</span><span class="nv">of</span><span class="p">:</span> <span class="k">self</span><span class="p">)</span><span class="o">.</span><span class="nf">singletonInstance</span><span class="p">()</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>This opens the door to convenience initializers being able to use static factory methods or other <code class="language-plaintext highlighter-rouge">Self</code>-returning operations to produce their returned result, not only the result of other initializers. Swift’s own standard library and Foundation overlay hack around this missing functionality by making classes conform to dummy protocols and using protocol extension initializers where necessary to implement this functionality:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">protocol</span> <span class="kt">P</span> <span class="p">{</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="nf">instance</span><span class="p">()</span> <span class="o">-></span> <span class="k">Self</span>
<span class="p">}</span>
<span class="kd">extension</span> <span class="kt">P</span> <span class="p">{</span>
<span class="nf">init</span><span class="p">()</span> <span class="p">{</span>
<span class="k">self</span> <span class="o">=</span> <span class="k">Self</span><span class="o">.</span><span class="nf">instance</span><span class="p">()</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="kd">class</span> <span class="kt">C</span><span class="p">:</span> <span class="kt">P</span> <span class="p">{</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="nf">instance</span><span class="p">()</span> <span class="o">-></span> <span class="k">Self</span> <span class="p">{</span> <span class="o">...</span> <span class="p">}</span>
<span class="kd">convenience</span> <span class="nf">init</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="p">())</span> <span class="p">{</span>
<span class="k">self</span><span class="o">.</span><span class="nf">init</span><span class="p">()</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<h3 id="finally">Finally</h3>
<p>Swift can now even be found <a href="https://twitter.com/jckarter/status/1040297140822523904">in Apple Watch bands</a>. Who would’ve thought?!</p>
Issue #117
https://swiftweeklybrief.com/issue-117
2018-09-06T00:00:00-07:00
2018-09-06T00:00:00-07:00
Greg Heo
https://twitter.com/gregheo
https://github.com/gregheo.png?size=100
gregheo
<blockquote>
<p>Bikeshedding, literals, thinking raw strings;<br />
Swift on the server is earning its wings.<br /></p>
<p>Numbers are multiples, even or odd;<br />
Pull requests benchmarking faster, no fraud.<br /></p>
<p>September announcements are here once again;<br />
New phones and devices, and soon Xcode 10.</p>
</blockquote>
<p>September is here, and we’re closing out the Summer of Swift. We’ve almost made it through the beta period and now iOS 12, macOS Mojave, Xcode 10, and Swift 4.2 are upon us.</p>
<p>There’s been a flurry of activity on Swift Evolution and around the community; let’s get started with all the latest!</p>
<!--excerpt-->
<h3 id="news-and-community">News and community</h3>
<p>The LLVM Foundation <a href="http://blog.llvm.org/2018/08/announcing-program-for-2018-llvm.html">announced the program for the 2018 LLVM Developers’ Meeting</a> scheduled for October 17–18 in San Jose. Swift nerds will <a href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk15">recognize</a> several <a href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk13">names</a> on the <a href="https://llvm.org/devmtg/2018-10/talk-abstracts.html#talk12">program</a>.</p>
<p>The <a href="https://swift.org/server/">Swift Server Work Group</a> has a new stated goal:</p>
<blockquote>
<p>The main goal of the Swift Server work group is to eventually recommend libraries and tools for server application development with Swift.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-nio">SwiftNIO</a> is currently the sole recommended library, but you can stay on top of updates from the group in the <a href="https://forums.swift.org/c/development/server">Server category of the Swift forums</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> merged in some new <a href="https://twitter.com/dgregor79/status/1032774695039324160">“Request-Evaluator” infrastructure</a> around the type checker to help eliminate mutable state and track dependencies. See the <a href="https://github.com/apple/swift/blob/master/docs/RequestEvaluator.md">design document</a> and <a href="https://github.com/apple/swift/pull/18923">pull request</a> for all the details.</p>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> removed the now unneeded <a href="https://github.com/apple/swift/pull/18922">pinning built-ins and SIL instructions</a>. As <a href="https://twitter.com/slava_pestov/status/1032871154032111616">summarized in a tweet</a>: “Nice simplification of the Swift reference counting model - the entire concept of “pinning” is gone now, thanks to exclusivity enforcement”.</p>
<p>Great work by <a href="https://bugs.swift.org/secure/ViewProfile.jspa?name=palimondo">Pavol Vaskovic</a> on spotting a recent regression <a href="https://bugs.swift.org/browse/SR-8682">causing incorrect sorting</a> (!) from the standard library, and <a href="https://github.com/overlazy">Kirill Chibisov</a> for <a href="https://github.com/apple/swift/pull/19107">the bug fix</a>. Test your code and watch your variable names!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md">SE-0200</a>: <em>Enhancing String Literals Delimiters to Support Raw Text</em> <a href="https://forums.swift.org/t/accepted-se-0200-enhancing-string-literals-delimiters-to-support-raw-text/15822/1">was accepted</a>. With extra delimiting characters <code class="language-plaintext highlighter-rouge">#"like this"#</code>, you’ll be able to control how escaping works and have an easier time writing “raw” text.</p>
<p>This is one of the most well written Swift Evolution proposals in my opinion, and has an epic <strong>461</strong> <a href="https://forums.swift.org/t/pure-bikeshedding-raw-strings-why-yes-again/13866">forum posts</a> split <a href="https://forums.swift.org/t/se-0200-raw-mode-string-literals/11048">across</a> three <a href="https://forums.swift.org/t/se-0200-enhancing-string-literals-delimiters-to-support-raw-text/15420">threads</a> for your reading pleasure.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0225-binaryinteger-iseven-isodd-ismultiple.md">SE-0225</a>: <em>Adding <code class="language-plaintext highlighter-rouge">isMultiple</code> to <code class="language-plaintext highlighter-rouge">BinaryInteger</code></em> <a href="https://forums.swift.org/t/accepted-with-modifications-se-0225-adding-ismultiple-to-binaryinteger/15689">was accepted with modifications</a>. The <code class="language-plaintext highlighter-rouge">isMultiple(of:)</code> method made it in, but proposed computed properties <code class="language-plaintext highlighter-rouge">isEven</code> and <code class="language-plaintext highlighter-rouge">isOdd</code> were dropped.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0226-package-manager-target-based-dep-resolution.md">SE-0226</a>: <em>Package Manager Target Based Dependency Resolution</em>
was <a href="https://forums.swift.org/t/se-0226-package-manager-target-based-dependency-resolution/15404/16">accepted</a> with generally positive comments all around. This change will speed up package resolution by only resolving dependencies that are actually used rather than all declared dependencies.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md">SE-0223</a>: <em>Accessing an Array’s Uninitialized Buffer</em> <a href="https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194/40">was returned for revision</a>. This proposal would allow you to initialize and access arrays via raw buffer. The core team was looking for more usage experience and discussion around handling errors.</p>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md">SE-0132</a>: <em>Rationalizing Sequence end-operation names</em> <a href="https://github.com/apple/swift-evolution/pull/898">was rejected</a>. Although it would make sequence and collection operation naming more consistent (e.g. “first” vs “start” vs “prefix”), the core team decided the source compatibility hit would be too great.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0222-lazy-compactmap-sequence.md">SE-0222</a>: <em>Lazy CompactMap Sequence</em> <a href="https://forums.swift.org/t/se-0222-lazy-compactmap-sequence/14850/16">was rejected</a>. The proposal would have added a new <code class="language-plaintext highlighter-rouge">LazyCompactMapCollection</code> to represent a <code class="language-plaintext highlighter-rouge">compactMap</code> to more efficiently handle chains of <code class="language-plaintext highlighter-rouge">map</code> and <code class="language-plaintext highlighter-rouge">filter</code> operations.</p>
<p>The core team decided the performance benefits were negligible and not worth the increased complexity pointed out during the review discussion.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0227-identity-keypath.md">SE-0227</a>: <em>Identity key path</em> <a href="https://forums.swift.org/t/se-0227-identity-key-path/15830">is in review</a> through Friday September 14.</p>
<p>Swift values already have a <code class="language-plaintext highlighter-rouge">.self</code> pseudo-property to refer to the value itself, and this proposal would add a corresponding key path <code class="language-plaintext highlighter-rouge">\.self</code>.</p>
<h3 id="swift-forums">Swift Forums</h3>
<p>Containerization has officially reached the world of Swift: Haris Amin posted about plans to offer <a href="https://forums.swift.org/t/kickstarting-new-official-docker-support-for-swift/15487">an official Docker image</a> for the community.</p>
<p><a href="https://forums.swift.org/u/Douglas_Gregor">Doug Gregor</a> wrote a pitch for <a href="https://forums.swift.org/t/opaque-result-types/15645">Opaque result types</a> — the ability to hide a function’s exact return type and specify its capabilities instead.</p>
<p><a href="https://forums.swift.org/u/Erik_Eckstein">Erik Eckstein</a> wrote an update on <a href="https://forums.swift.org/t/improved-benchmarking-for-pull-requests/15461">improvements to running benchmarks on pull requests</a>. They are faster, less noisy, and have nicer reports — a great boost to developer productivity.</p>
<p><a href="https://forums.swift.org/u/ahoppen">Alex Hoppen</a> announced <a href="https://forums.swift.org/t/swiftsyntax-is-now-a-swiftpm-project/15691">SwiftSyntax is now in its own repository</a> and available to include via Swift Package Manager. <a href="https://github.com/apple/swift-syntax">SwiftSyntax</a> is a wrapper for <a href="https://github.com/apple/swift/tree/master/lib/Syntax">libSyntax</a> and lets you write tools to work with Swift code in Swift.</p>
<p><a href="https://twitter.com/daniel_duan/status/1035331454467796993">Daniel Duan highlighted</a> the <a href="https://forums.swift.org/t/accepted-with-modifications-se-0225-adding-ismultiple-to-binaryinteger/15689">approval post for SE-0225</a> mentioned above, where review manager <a href="https://forums.swift.org/u/John_McCall">John McCall</a> listed guidelines for what gets included in the standard library:</p>
<blockquote>
<p>To be considered for addition to the library, a proposed feature must satisfy two conditions: it must provide functionality that is useful to a substantial population of Swift programmers, and it must provide substantial advantages over the alternative ways of accomplishing that functionality.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Add this to the category of things I read all the time, but never had to say out loud and <a href="https://twitter.com/jckarter/status/1035568097535508480">don’t know how to pronounce</a>.</p>
Issue #116
https://swiftweeklybrief.com/issue-116
2018-08-23T00:00:00-07:00
2018-08-23T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>September is approaching swiftly, which means that we’ll be seeing new iPhones and all the new software before we know it.</p>
<p>And although that won’t yet bring Swift 5, we will get Swift 4.2 that comes with some awesome improvements as well, plus we’ll still have Swift 5 to look forward to!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8507">SR-8507</a> [Compiler] ‘foo bar’ could have fixit suggesting missing <code class="language-plaintext highlighter-rouge">.</code> rather than just <code class="language-plaintext highlighter-rouge">;</code> or <code class="language-plaintext highlighter-rouge">,</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8536">SR-8536</a> [Compiler] Warn on member assignments capturing <code class="language-plaintext highlighter-rouge">self</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8598">SR-8598</a> [Compiler] Deprecating then obsoleting can be error prone</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Swift Unwrapped is back from the summer break, and will take on <a href="https://twitter.com/simjp/status/1031547194594144257">a new format</a> with longer episodes once a month.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/184831">episode 66</a>, Jesse and JP discuss the plan for module stability, outlined by <a href="https://twitter.com/uint_min">Jordan Rose</a> on the <a href="https://forums.swift.org/t/plan-for-module-stability/14551">forums</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared that Swift 4.2 is <a href="https://forums.swift.org/t/swift-4-2-in-final-convergence-swift-4-2-branch-open-for-post-4-2-0-changes/15128/1">in final convergence</a>. Not much longer now!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/uint_min">Jordan Rose</a> merged <a href="https://github.com/apple/swift/pull/18579">a pull request</a> that adds default argument values in the generated interface view within Xcode. This also closes <a href="https://bugs.swift.org/browse/SR-2608">SR-2608</a>.</p>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/18539">a pull request</a> improving name lookup from declaration checking. “With the request evaluator, new function type representation, <code class="language-plaintext highlighter-rouge">SubstitutionMap</code> redesign and removal of curried parameter lists we’re finally paying off a lot of tech debt - the implementation is catching up to the language” 🎉</p>
<p><a href="https://twitter.com/gregtitus">Greg Titus</a> merged <a href="https://github.com/apple/swift/pull/18699">a pull request</a> that ports Optional unwrapping fixits to the new diagnostics framework.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0224-ifswift-lessthan-operator.md">SE-0224</a>: <em>Support ‘less than’ operator in compilation conditions</em> was <a href="https://forums.swift.org/t/se-0224-support-less-than-operator-in-compilation-conditions/15213/5">accepted</a>.</p>
<blockquote>
<p>The proposal text will be amended to include the mention of the change of behavior to <code class="language-plaintext highlighter-rouge">#if compiler</code>, which is also reflected in the implementation and logically fits in with this change:</p>
<blockquote>
<p>The proposal only mentions <code class="language-plaintext highlighter-rouge">#if swift(<4.2)</code> but the implementation also appears to support <code class="language-plaintext highlighter-rouge">#if compiler(<4.2)</code> from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0212-compiler-version-directive.md">SE-0212</a>.</p>
</blockquote>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md">SE-0200</a>: <em>Enhancing String Literals Delimiters to Support Raw Text</em> was <a href="https://forums.swift.org/t/se-0200-enhancing-string-literals-delimiters-to-support-raw-text/15420">returned for revision</a>.</p>
<blockquote>
<p>Like many computer languages, Swift uses an escape character (<code class="language-plaintext highlighter-rouge">\</code>) to create a special interpretation of subsequent characters within a string literal. Escape character sequences represent a set of predefined, non-printing characters as well as string delimiters (the double quote), the escape character (the backslash itself), and (uniquely in Swift) to allow in-string expression interpolation.</p>
<p>Escape characters provide useful and necessary capabilities but strings containing many escape sequences are difficult to read. Other languages have solved this problem by providing an alternate “raw” string literal syntax which does not process escape sequences. As the name suggests, raw string literals allow you to use “raw” text, incorporating backslashes and double quotes without escaping.</p>
<p>We propose to alter Swift’s string literal design to do the same, using a new design which we believe fits Swift’s simple and clean syntax. This design supports both single-line and multi-line string literals, and can contain any content whatsoever.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0223-array-uninitialized-initializer.md">SE-0223</a>: <em>Accessing an Array’s Uninitialized Buffer</em> is <a href="https://forums.swift.org/t/se-0223-accessing-an-arrays-uninitialized-buffer/15194">under review</a>.</p>
<blockquote>
<p>This proposal suggests a new initializer and method for <code class="language-plaintext highlighter-rouge">Array</code> and <code class="language-plaintext highlighter-rouge">ContiguousArray</code> that provide access to an array’s uninitialized storage buffer.</p>
<p>Some collection operations require working on a fixed-size buffer of uninitialized memory. For example, one O(<em>n</em>) algorithm for performing a stable partition of an array is as follows:</p>
<ol>
<li>Create a new array the same size as the original array.</li>
<li>Iterate over the original array, copying matching elements to the beginning of the new array and non-matching elements to the end.</li>
<li>When finished iterating, reverse the slice of non-matching elements.</li>
</ol>
<p>Unfortunately, the standard library provides no way to create an array of a particular size without allocating every element, or to copy elements to the end of an array’s buffer without initializing every preceding element.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0225-binaryinteger-iseven-isodd-ismultiple.md">SE-0225</a>: <em>Adding <code class="language-plaintext highlighter-rouge">isEven</code>, <code class="language-plaintext highlighter-rouge">isOdd</code>, <code class="language-plaintext highlighter-rouge">isMultiple</code> to <code class="language-plaintext highlighter-rouge">BinaryInteger</code></em> is <a href="https://forums.swift.org/t/se-0225-adding-iseven-isodd-ismultiple-to-binaryinteger/15382">under review</a>.</p>
<blockquote>
<p>This proposal adds <code class="language-plaintext highlighter-rouge">var isEven: Bool</code>, <code class="language-plaintext highlighter-rouge">var isOdd: Bool</code>, and <code class="language-plaintext highlighter-rouge">func isMultiple(of other: Self) -> Bool</code> to the <code class="language-plaintext highlighter-rouge">BinaryInteger</code> protocol. <code class="language-plaintext highlighter-rouge">isEven</code> and <code class="language-plaintext highlighter-rouge">isOdd</code> are convenience properties for querying the <a href="https://en.wikipedia.org/wiki/Parity_(mathematics)">parity</a> of the integer and <code class="language-plaintext highlighter-rouge">isMultiple</code> is a more general function to determine whether an integer is a multiple of another integer.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0226-package-manager-target-based-dep-resolution.md">SE-0226</a>: <em>Package Manager Target Based Dependency Resolution</em> is <a href="https://forums.swift.org/t/se-0226-package-manager-target-based-dependency-resolution/15404">under review</a>.</p>
<blockquote>
<p>This is a proposal for enhancing the package resolution process to resolve the minimal set of dependencies that are used in a package graph.</p>
<p>The current package resolution process resolves all declared dependencies in the package graph. Some of the declared dependencies may not be required by the products that are being used in the package graph. For e.g., a package may be using some additional dependencies for its test targets. The packages that depend on this package doesn’t need to resolve such additional dependencies. These dependencies increase the overall constraint in the dependency resolution process that can otherwise be avoided. It can cause more cases of dependency hell if two packages want to use incompatible versions of a dependency that they only use for their unexported products. Cloning unnecessary dependencies also impacts the performance of the resolution process.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/aciidb0mb3r">Ankit Aggarwal</a> shared <a href="https://forums.swift.org/t/rfc-swift-package-publish-precheck/15398">a small proposal</a> regarding tagging and publishing of Swift packages.</p>
<blockquote>
<p>Swift packages can be in a bunch of states which makes them inappropriate for tagging or publishing. I think having a command to detect such states would be valuable for Swift package authors. In the future, this can even evolve into a larger tag-and-publish workflow feature.</p>
</blockquote>
<p><a href="https://twitter.com/gregtitus">Greg Titus</a> shared <a href="https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10764/102">an update</a> on the much improved fixits for Optional chaining and force unwrapping.</p>
<blockquote>
<p>[..] The force unwrap fixit still exists, but it is now never the only or preferred fixit offered, and hopefully the explanations of the errors are a lot more beginner-friendly now.</p>
</blockquote>
<p>These error messages have been much-improved. I recommend <a href="https://forums.swift.org/t/resolved-insert-is-a-bad-fixit/10764/102">taking a look</a> at the changes yourself.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared <a href="https://forums.swift.org/t/crowdfunding-world-domination/13655/113">they are evaluating implementing the Language Server Protocol in Swift</a>.</p>
<blockquote>
<p>[We] have also been recently discussing offline LSP and evaluating potential strategies. We’ll start a thread soon once we’ve put those thoughts in order; should be soon.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/ryzokuken/status/1030367978691260416">Old but <del>gold</del> green</a>.</p>
Issue #115
https://swiftweeklybrief.com/issue-115
2018-08-09T00:00:00-07:00
2018-08-09T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A calm week during these warm two summer weeks. Nevertheless, here is a quick update on what has happened these weeks.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8467">SR-8467</a> [Compiler] Invalid read when calling <code class="language-plaintext highlighter-rouge">swift::AnyFunctionType::getExtInfo</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8464">SR-8464</a> [Compiler] Attempting to print a function should require the use of <code class="language-plaintext highlighter-rouge">String(describing:)</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8453">SR-8453</a> [Compiler] Warn when redundant access modifier is added in an extension</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>While Jesse and JP are on a holiday break from the podcast, you can find all previous episodes <a href="https://spec.fm/podcasts/swift-unwrapped">here</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://forums.swift.org/u/nicole_jacque/summary">Nicole Jacque</a> shared that <a href="https://forums.swift.org/t/swift-4-1-3-is-released-linux-only/14847">Swift 4.1.3</a>, with a <a href="https://bugs.swift.org/browse/SR-7650">Linux-only fix</a>, has been released.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/18145">a pull request</a> getting rid of redundancy in protocol derivation.</p>
<p><a href="https://github.com/phausler">Philippe Hausler</a> merged <a href="https://github.com/apple/swift/pull/18469">a pull request</a> to fix ambiguous mapping to <code class="language-plaintext highlighter-rouge">Data</code> from a byte sequence in Swift 4.2.</p>
<p><a href="https://twitter.com/dhartbit">David Hart</a> merged <a href="https://github.com/apple/swift-package-manager/pull/1537">a pull request</a> that allows SwiftPM to use <code class="language-plaintext highlighter-rouge">llbuild</code> as a library, which will “enable great new features and enhancements in the future”.</p>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/18484">a pull request</a> to emit diagnostics directly from the constraint solver, moving away from re-type checking sub-expressions after a failure, which has been a source of misleading diagnostics and crashes.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0221-character-properties.md">SE-0221</a>: <em>Character Properties</em> was <a href="https://forums.swift.org/t/accepted-with-pending-discussion-se-0221-character-properties/14944">accepted with pending discussion</a>.</p>
<blockquote>
<p>SE-0221 has been accepted, with the exception of the <code class="language-plaintext highlighter-rouge">.isEmoji</code> property.</p>
<p>The core team accepts the principle for the <code class="language-plaintext highlighter-rouge">isEmoji</code> property, but wants to continue the discussion of exactly how it should work. Therefore the thread will remain open for this specific topic through <strong>August 10th</strong>. The other functionality can be merged into master in the meantime.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0220-count-where.md">SE-0220</a>: <em><code class="language-plaintext highlighter-rouge">count(where:)</code></em> is <a href="https://forums.swift.org/t/se-0220-count-where/15048">under review</a>.</p>
<blockquote>
<p>While Swift’s <code class="language-plaintext highlighter-rouge">Sequence</code> models brings a lot of niceties that we didn’t have access to in Objective-C, like <code class="language-plaintext highlighter-rouge">map</code> and <code class="language-plaintext highlighter-rouge">filter</code>, there are other useful operations on sequences that the standard library doesn’t support yet. One current missing operation is <code class="language-plaintext highlighter-rouge">count(where:)</code>, which counts the number of elements in a <code class="language-plaintext highlighter-rouge">Sequence</code> that pass some test.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0222-lazy-compactmap-sequence.md">SE-0222</a>: <em>Lazy CompactMap Sequence</em> is <a href="https://forums.swift.org/t/se-0222-lazy-compactmap-sequence/14850">under review</a>.</p>
<blockquote>
<p>Chaining multiple <code class="language-plaintext highlighter-rouge">.map()</code>s and <code class="language-plaintext highlighter-rouge">.filter()</code>s on a lazy collection leads to suboptimal codegen, as well as large, painful type names.</p>
<p>To improve this, we propose adding a <code class="language-plaintext highlighter-rouge">LazyCompactMap{Sequence, Collection}</code> type along with some overloads on the other lazy collection types’ <code class="language-plaintext highlighter-rouge">.map(_:)</code> and <code class="language-plaintext highlighter-rouge">.filter(_:)</code> functions which return this type to get better codegen and shorter type names.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="http://twitter.com/beccadax">Becca Royal-Gordon</a> pitched <a href="https://forums.swift.org/t/draft-fix-string-interpolation-swift-5-edition/14786">a proposal</a> to fix String interpolation in Swift 5.</p>
<blockquote>
<p>String interpolation is a simple and powerful feature for expressing complex, runtime-created strings, but the current version of the <code class="language-plaintext highlighter-rouge">ExpressibleByStringInterpolation</code> protocol has been deprecated since Swift 3. We propose a new design which improves its performance, clarity, and efficiency.</p>
</blockquote>
<p><a href="http://twitter.com/ericasadun/status/970754573609484288">Erica Sadun</a> pitched <a href="https://forums.swift.org/t/support-repeating-initializers-with-closures-not-just-values/14666">a proposal</a> to support repeating initializers with closures.</p>
<blockquote>
<p>I’d like to pitch a protocol that supports repeated initializers, both for a repeated element and for <code class="language-plaintext highlighter-rouge">() -> Element</code>. The goal is to ensure that any type that conforms to the protocol guarantees that if you can initialize with <em>n</em> copies of a value type, then you can initialize with <em>n</em> instances of a reference type or <em>n</em> applications of a closure:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">protocol</span> <span class="kt">RepeatingInitializable</span><span class="p">:</span> <span class="kt">Collection</span> <span class="p">{</span>
<span class="c1">/// See also: `Repeat.swift`: A collection whose elements are all identical.</span>
<span class="c1">/// https://github.com/apple/swift/blob/master/stdlib/public/core/Repeat.swift</span>
<span class="kd">public</span> <span class="nf">init</span><span class="p">(</span><span class="n">repeating</span> <span class="nv">repeatedValue</span><span class="p">:</span> <span class="kt">Element</span><span class="p">,</span> <span class="nv">count</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span>
<span class="c1">/// Allow reference types to generate new instances and value types</span>
<span class="c1">/// to use a closure to create potentially distinct values</span>
<span class="c1">///</span>
<span class="c1">/// A collection whose elements are all created by an identical generator</span>
<span class="kd">public</span> <span class="nf">init</span><span class="p">(</span><span class="n">repeating</span> <span class="nv">repeatedGenerator</span><span class="p">:</span> <span class="kd">@autoclosure</span> <span class="p">()</span> <span class="o">-></span> <span class="kt">Element</span><span class="p">,</span> <span class="nv">count</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span>
<span class="p">}</span></code></pre></figure>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/aciidb0mb3r/status/1026241132848537600">When you try to run Swift locally</a>…</p>
Issue #114
https://swiftweeklybrief.com/issue-114
2018-07-26T00:00:00-07:00
2018-07-26T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Not only did the Swift repository pass <a href="https://twitter.com/jckarter/status/1019623101921804288">18,000</a> pull requests (after the internal repository had 18,000 SVN revisions after four years), it also celebrated its <a href="https://twitter.com/slava_pestov/status/1021627717228220417">8th birthday</a>! Impressive numbers, and may many more follow.</p>
<p>Apart from that, I hope many of you are enjoying an awesome summer!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8252">SR-8252</a> [Compiler] Consolidate and Fix <code class="language-plaintext highlighter-rouge">-debug-crash-*</code> Flags</li>
<li><a href="https://bugs.swift.org/browse/SR-8253">SR-8253</a> [Compiler] <code class="language-plaintext highlighter-rouge">catch</code> clause should allow multiple patterns</li>
<li><a href="https://bugs.swift.org/browse/SR-8327">SR-8327</a> [Package Manager] Improve error message when bootstrapping SwiftPM without cmake or ninja</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Jesse and JP are taking <a href="https://twitter.com/swift_unwrapped/status/1016334803648434176">a well deserved summer break</a>. ☀️🏖</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://github.com/Lukasa">Cory Benfield</a> announced the release of <a href="https://forums.swift.org/t/niotransportservices-swiftnio-and-network-framework/14567"><code class="language-plaintext highlighter-rouge">NIOTransportServices</code></a> to help users use Network.framework with a SwiftNIO API.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/slava_pestov/">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/18082">a pull request</a> that continues the work of SE-0002 (!), removing multiple parameter lists from the Abstract Syntax Tree (AST).</p>
<p><a href="https://twitter.com/AirspeedSwift/">Ben Cohen</a> merged <a href="https://github.com/apple/swift/pull/18098">a pull request</a> that refactors some code making use of conditional conformances. The result? +276, -2,694 lines of code. Impressive!</p>
<p><a href="https://twitter.com/dgregor79/">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/18163">a pull request</a> involving protocol metadata. This is also part of ABI stability and improving reflection. According to Slava, “This all lays the groundwork for powerful metaprogramming capabilities that go far beyond the standard library’s <code class="language-plaintext highlighter-rouge">Mirror</code> type”. 🎉</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0215-conform-never-to-hashable-and-equatable.md">SE-0215</a>: <em>Conform <code class="language-plaintext highlighter-rouge">Never</code> to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code></em> was <a href="https://forums.swift.org/t/se-0215-conform-never-to-equatable-and-hashable/13586/45">accepted</a>.</p>
<blockquote>
<p>The Core Team discussed the review, and reached the following conclusions:</p>
<ul>
<li>
<p>The proposal should be accepted with the new explicit conformances to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> be added to <code class="language-plaintext highlighter-rouge">Never</code>. This addresses a real point of friction users are experiencing with the use of <code class="language-plaintext highlighter-rouge">Never</code>.</p>
</li>
<li>
<p>For the same reasons conformances to <code class="language-plaintext highlighter-rouge">Hashable</code> and <code class="language-plaintext highlighter-rouge">Equatable</code> are being added to <code class="language-plaintext highlighter-rouge">Never</code>, the Core Team felt that conformances to <code class="language-plaintext highlighter-rouge">Error</code> and <code class="language-plaintext highlighter-rouge">Comparable</code> should also be added to <code class="language-plaintext highlighter-rouge">Never</code> as part of accepting this proposal. Both of these additional protocol conformances were brought up during the review.</p>
</li>
<li>
<p><code class="language-plaintext highlighter-rouge">Never</code> should become a blessed bottom type in the language. This matches with semantics in other languages and its intended role in Swift.</p>
</li>
</ul>
<p>With respect to the latter, the Core Team discussed what Never being a bottom type actually meant. From that discussion we reached the following conclusions:</p>
<ul>
<li>Semantically, as a bottom type, it would mean that Never should be implicitly convertible to any other type. This composes well in the type system because of the fact that instances of <code class="language-plaintext highlighter-rouge">Never</code> cannot be instantiated.</li>
</ul>
<p>However, being a bottom type does not imply that <code class="language-plaintext highlighter-rouge">Never</code> should implicitly conform to all protocols. Instead, convenient protocol conformances for Never should be added as deemed useful or necessary.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0218-introduce-compact-map-values.md">SE-0218</a>: <em>Introduce <code class="language-plaintext highlighter-rouge">compactMapValues</code> to Dictionary</em> was <a href="https://forums.swift.org/t/accepted-se-0218-introduce-compactmapvalues-to-dictionary/14448">accepted</a>.</p>
<blockquote>
<p>Feedback on the proposal was very positive – the main concern being with the name, but this falls naturally out of our existing method names so is consistent, if clunky.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0219-package-manager-dependency-mirroring.md">SE-0219</a>: <em>Package Manager Dependency Mirroring</em> was <a href="https://forums.swift.org/t/se-0219-package-manager-dependency-mirroring/14371/8">accepted with revisions</a>.</p>
<blockquote>
<p>The review of SE-0219 “Package Manager Dependency Mirroring” ran from July 10…17. Feedback was positive, and the proposal is accepted with revisions (adding a <code class="language-plaintext highlighter-rouge">swift package config get-mirror</code> command). Thanks to everyone who participated!</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0217-bangbang.md">SE-0217</a>: <em>Introducing the <code class="language-plaintext highlighter-rouge">!!</code> “Unwrap or Die” operator to the Swift Standard Library</em> was <a href="https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/222">rejected</a>.</p>
<blockquote>
<p>The core team has decided to reject this proposal as written. However, the core team concurs that the motivating problems posed by the proposal are important to solve, as did an overwhelming majority of commenters who participated in the public review. The fact that the only fixit the compiler offers to unwrap an Optional is to use the <code class="language-plaintext highlighter-rouge">!</code> operator is an unfortunate legacy of the Swift 1.0 days, before anything in the SDKs Swift was designed to work with had been audited for nullability, so force-unwrapping was far more of a necessity. Nowadays this legacy is actively harmful, and encourages bad habits in new Swift programmers, as the proposal and review discussion highlight extensively. It is clear too that <code class="language-plaintext highlighter-rouge">!</code> giving inadequate runtime feedback is a major problem, since a large contingent of the Swift community follows style guides that flat-out ban it, and the <code class="language-plaintext highlighter-rouge">guard ... else { fatalError("message") }</code> idiom is widespread as a way of more thoughtfully crashing on nil with an actionable error message.</p>
</blockquote>
<p>I’d encourage you to read <a href="https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107/222">the rest of the rationale</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0221-character-properties.md">SE-0221</a>: <em>Character Properties</em> is <a href="https://forums.swift.org/t/se-0221-character-properties/14686">under review</a>.</p>
<blockquote>
<p><a href="https://github.com/allevato">Tony Allevato</a> (a co-author here) proposed <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0211-unicode-scalar-properties.md">Add Unicode Properties to <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code></a>, which exposes Unicode properties from the <a href="http://unicode.org/reports/tr44/">Unicode Character Database</a>. These are Unicode expert/enthusiast oriented properties that give a finer granularity of control and answer highly-technical and specific Unicody enquiries.</p>
<p>However, they are not ergonomic and Swift makes no attempt to clarify their interpretation or usage: meaning and proper interpretation is directly tied to the Unicode Standard and the version of Unicode available at run time. There’s some low-hanging ergo-fruit ripe for picking by exposing properties directly on <code class="language-plaintext highlighter-rouge">Character</code>.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/aciidb0mb3r">Ankit Aggarwal</a> shared news about some <a href="https://forums.swift.org/t/package-manifest-caching-landed/14624">recently added features</a> in SwiftPM, namely the caching of manifests.</p>
<blockquote>
<p>[..] SwiftPM will now cache the loaded manifests for effectively all operations except dependency resolution. This provides great performance improvements during iterative development. Commands like <code class="language-plaintext highlighter-rouge">swift build</code>, <code class="language-plaintext highlighter-rouge">swift test</code>, <code class="language-plaintext highlighter-rouge">swift package edit</code>, <code class="language-plaintext highlighter-rouge">swift package generate-xcodeproj</code> should start significantly faster once the cache is created. For e.g., time spent to load all manifests of Vapor reduces from 3.7s to 64ms!</p>
</blockquote>
<p><a href="https://twitter.com/UINT_MIN">Jordan Rose</a> shared <a href="https://forums.swift.org/t/plan-for-module-stability/14551">an update on module stability</a>, which he will be working on in “the next year or so”.</p>
<blockquote>
<p><em>ABI stability</em> means that an executable compiled against Swift 5 will work with the Swift 6 libraries, and that an executable compiled against Swift 6 will work with the Swift 5 libraries. A related concept is module stability, which says that the <em>interface</em> for a Swift 5 library will work with the Swift 6 compiler. (The opposite direction is less interesting.) More generally, <em>the interface for a library should be forward-compatible with future versions of the compiler</em>. This is useful in a number of ways:</p>
<ul>
<li>Can test a new compiler without rebuilding all of an app’s dependencies.</li>
<li>May overlap with work to make the debugger work across Swift versions.</li>
<li>May help reduce incremental build time by better tracking cross-target dependencies.</li>
<li>Support for general <em>non-resilient</em> binary frameworks.</li>
</ul>
</blockquote>
<p>If you’re interested in this, I would recommend reading the <a href="https://forums.swift.org/t/plan-for-module-stability/14551">full post</a>.</p>
<p><a href="">Nate Cook</a> pitched <a href="https://forums.swift.org/t/array-initializer-with-access-to-uninitialized-buffer/13689">a proposal</a> to expose the internal array initializer that has access to an uninitialized buffer.</p>
<blockquote>
<p>There is currently no way to work with a buffer of uninitialized memory that then becomes a fully memory-managed <code class="language-plaintext highlighter-rouge">Array</code>. This limitation means that operations that don’t know the final size of their data in advance, or that need to access noncontiguous parts of an array, are less efficient than necessary, often requiring an extra copy. This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">Array</code> and <code class="language-plaintext highlighter-rouge">ContiguousArray</code> that would provide access to a newly created array’s entire storage buffer.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/1018224486477279233">Index out of bounds</a>. 💥</p>
Issue #113
https://swiftweeklybrief.com/issue-113
2018-07-12T00:00:00-07:00
2018-07-12T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Welcome to the 113th issue of Swift Weekly Brief! This week was more calm, no news explosions. The repositories and Swift.org discussions had their usual activity.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-8135">SR-8135</a> [Package Manager] SwiftPM should only check for <code class="language-plaintext highlighter-rouge">clang</code> if it is needed</li>
<li><a href="https://bugs.swift.org/browse/SR-8137">SR-8137</a> [Package Manager] Provide mechanism to disable color diagnostics from commands</li>
<li><a href="https://bugs.swift.org/browse/SR-8138">SR-8138</a> [Package Manager] Mechanism to limit the parallelism of <code class="language-plaintext highlighter-rouge">swift test --parallel</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8139">SR-8139</a> [Package Manager] Executable init template is broken when there is a dash in package name</li>
<li><a href="https://bugs.swift.org/browse/SR-8172">SR-8173</a> [Tooling] <code class="language-plaintext highlighter-rouge">(T)</code> Reported as Single-Element Tuple Rather Than <code class="language-plaintext highlighter-rouge">T</code></li>
<li><a href="https://bugs.swift.org/browse/SR-8190">SR-8190</a> [Standard Library] Introduce a RingBuffer to the Standard Library</li>
<li><a href="https://bugs.swift.org/browse/SR-8204">SR-8204</a> [Package Manager] Sort targets in SwiftPM generated Xcode project</li>
<li><a href="https://bugs.swift.org/browse/SR-8222">SR-8222</a> [Swift for TensorFlow] <code class="language-plaintext highlighter-rouge">PartitionCloner::visitCondBranchInst()</code> should be generalized to handle <code class="language-plaintext highlighter-rouge">TensorHandle<Bool></code> in addition to <code class="language-plaintext highlighter-rouge">TensorHandle<Builtin.i1></code></li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/160476">episode 65</a>, Jesse and JP discuss the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0213-literal-init-via-coercion.md">SE-0213: Literal initialization via coercion</a> proposal and its implementation.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/aciidb0mb3r">Ankit Aggarwal</a> noticed the right thing: when <code class="language-plaintext highlighter-rouge">Codable</code> is awesome, it requires <a href="https://github.com/apple/swift-package-manager/pull/1655/files#diff-31d171cad93e680d3ffc6cb3c4fc6848R13">so much boilerplate</a> to support enums. It would be great if the compiler could synthesize it, like with <code class="language-plaintext highlighter-rouge">Hashable</code> and <code class="language-plaintext highlighter-rouge">Equatable</code>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/rudkx">Mark Lacey</a> opened <a href="https://github.com/apple/swift/pull/17691">a pull request</a> to remove Swift 3 from the type checker. “Goodbye, Swift 3”</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged several pull requests: <a href="https://github.com/apple/swift/pull/17611">#17611</a>, <a href="https://github.com/apple/swift/pull/17651">#17651</a> and <a href="https://github.com/apple/swift/pull/17816">#17816</a> - great additions to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156: Class and Subtype existentials</a> to add support for protocols with superclass constraints.</p>
<p><a href="https://github.com/allevato">Tony Allevato</a> merged <a href="https://github.com/apple/swift/pull/15593">a pull request</a> to add Unicode properties to <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code>. This implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0211-unicode-scalar-properties.md">SE-0211</a>, <em>Add Unicode Properties to <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code></em>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>An amendment to <a href="https://github.com/jckarter/swift-evolution/blob/master/proposals/0202-random-unification.md">SE-0202</a>: <em>Random Unification</em> was <a href="https://forums.swift.org/t/amendment-to-se-0202-removing-collection-randomelement-as-a-customization-point/14101">accepted</a>.</p>
<blockquote>
<p>We decided to accept the proposed amendment to remove <code class="language-plaintext highlighter-rouge">randomElement</code> as a customization point.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md">SE-0216</a>: <em>User-defined dynamically callable types</em> was <a href="https://forums.swift.org/t/accepted-se-216-user-defined-dynamically-callable-types/14110">accepted</a>.</p>
<blockquote>
<p>Feedback on the proposal was almost entirely positive on both the idea of supporting dynamically-typed calls and the proposal’s specific approach to providing that support.</p>
<p>Therefore, the proposal was accepted without modifications.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0217-bangbang.md">SE-0217</a>: <em>Introducing the <code class="language-plaintext highlighter-rouge">!!</code> “Unwrap or Die” operator to the Swift Standard Library</em> is <a href="https://forums.swift.org/t/se-0217-the-unwrap-or-die-operator/14107">under review</a>.</p>
<blockquote>
<p>This proposal introduces an annotating forced-unwrapping operator to the Swift standard library. It augments the <code class="language-plaintext highlighter-rouge">?</code>, <code class="language-plaintext highlighter-rouge">??</code>, and <code class="language-plaintext highlighter-rouge">!</code> family, adding <code class="language-plaintext highlighter-rouge">!!</code>. This “unwrap or die” operator provides code-sourced rationales for failed unwraps, supporting self-documentation and safer development. The <code class="language-plaintext highlighter-rouge">!!</code> operator is commonly implemented in the wider Swift Community and should be considered for official adoption.</p>
<p>The new operator benefits both experienced and new Swift users. It takes this form:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">value</span> <span class="o">=</span> <span class="n">wrappedValue</span> <span class="o">!!</span> <span class="o"><</span><span class="err">#</span> <span class="s">"Explanation why lhs cannot be nil."</span> <span class="err">#</span><span class="o">></span></code></pre></figure>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0218-introduce-compact-map-values.md">SE-0218</a>: <em>Introduce <code class="language-plaintext highlighter-rouge">compactMapValues</code> to <code class="language-plaintext highlighter-rouge">Dictionary</code></em> is <a href="https://forums.swift.org/t/se-0218-introduce-compactmapvalues-to-dictionary/14266">under review</a>.</p>
<blockquote>
<p>This proposal adds a combined <code class="language-plaintext highlighter-rouge">filter</code>/<code class="language-plaintext highlighter-rouge">map</code> operation to <code class="language-plaintext highlighter-rouge">Dictionary</code>, as a companion to the <code class="language-plaintext highlighter-rouge">mapValues</code> and <code class="language-plaintext highlighter-rouge">filter</code> methods introduced by <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md">SE-0165</a>. The new <code class="language-plaintext highlighter-rouge">compactMapValues</code> operation corresponds to <code class="language-plaintext highlighter-rouge">compactMap</code> on <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0219-package-manager-dependency-mirroring.md">SE-0219</a>: <em>Package Manager Dependency Mirroring</em> is <a href="https://forums.swift.org/t/se-0219-package-manager-dependency-mirroring/14371">under review</a>.</p>
<blockquote>
<p>A dependency mirror refers to an alternate source location which exactly replicates the contents of the original source.</p>
<p>Dependency mirroring is useful for several reasons:</p>
<ul>
<li><strong>Availability</strong>: Mirrors can ensure that a dependency can be always fetched, in case the original source is unavailable or even deleted.</li>
<li><strong>Cache</strong>: Access to the original source location could be slow or forbidden in the current environment.</li>
<li><strong>Validation</strong>: Mirrors can help with screening the upstream updates before making them available internally within a company.</li>
</ul>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="">Tony Parker</a> started <a href="https://forums.swift.org/t/pitch-move-urlsession-to-new-foundationnetworking-module/14002">a pitch</a> to move <code class="language-plaintext highlighter-rouge">URLSession</code> and related types to a new library.</p>
<blockquote>
<p>Some of the feedback we’ve received from the SwiftNIO team is that Foundation’s dependency on <code class="language-plaintext highlighter-rouge">libcurl</code> brings in too many other libraries.</p>
<p>I propose moving the networking types (except <code class="language-plaintext highlighter-rouge">URL</code> and <code class="language-plaintext highlighter-rouge">URLComponents</code>) into another library, with a working name of <code class="language-plaintext highlighter-rouge">swift-corelibs-foundation-networking</code>.</p>
<p>Benefits:</p>
<ul>
<li>SwiftNIO would be able to use core Foundation types.</li>
<li><code class="language-plaintext highlighter-rouge">swift-corelibs-foundation-networking</code> could use SwiftPM to build itself.</li>
<li>Other projects that wish to maintain a minimum set of dependencies and do not need networking support can reduce their footprint.</li>
</ul>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/slava_pestov/status/1016534163988496384">I wonder if it runs Swift?</a> 🤔</p>
Issue #112
https://swiftweeklybrief.com/issue-112
2018-06-28T00:00:00-07:00
2018-06-28T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I am back! I had the most wonderful time at WWDC, learning a lot of and meeting awesome people.
I want to specifically thank all those that have shown their gratitude for the weekly brief, it’s much appreciated!</p>
<p>Without further ado, here’s this week’s news on the Swift.org open source projects.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7984">SR-7984</a> [Compiler] Constraint to concrete type using <code class="language-plaintext highlighter-rouge">:</code> should offer a fixit</li>
<li><a href="https://bugs.swift.org/browse/SR-8012">SR-8012</a> [Standard Library] Remove <code class="language-plaintext highlighter-rouge">Indexable</code> aliases</li>
<li><a href="https://bugs.swift.org/browse/SR-8049">SR-8049</a> [Swift for TensorFlow] Open source S4TF unit testing with a remote TF session</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/147483">episode 63</a>, Jesse and JP discuss Swift algorithms and data structures with <a href="https://twitter.com/KelvinlauKl">Kelvin Lau</a> and <a href="https://twitter.com/VincentNgo2">Vincent Ngo</a>.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/160151">episode 64</a>, Jesse and JP discuss <code class="language-plaintext highlighter-rouge">Never</code>, the <a href="https://developer.apple.com/documentation/swift/never">return type of functions that do not return normally</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/olebegemann">Ole Begemann</a> wrote <a href="https://oleb.net/blog/2018/06/dynamic-member-lookup/">a blog post</a> with thoughts on <code class="language-plaintext highlighter-rouge">@dynamicMemberLookup</code>, which was introduced in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md">SE-0195</a>.</p>
<p><a href="https://twitter.com/johnsundell">John Sundell</a> discussed the Swift Package Manager with <a href="https://twitter.com/dhartbit">David Hart</a> in his <a href="https://www.swiftbysundell.com/podcast/26">podcast</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/17227">a pull request</a> to fix a corner case for source compatibility. As it appears, using an enum case called <code class="language-plaintext highlighter-rouge">init</code> could cause some trouble.</p>
<p><a href="https://twitter.com/aciidb0mb3r/">Ankit Aggarwal</a> merged <a href="https://github.com/apple/swift-evolution/pull/828">a pull request</a> that adds a new, SwiftPM specific proposal template that better reflects the expectations and nuances of this project.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0211-unicode-scalar-properties.md">SE-0211</a>: <em>Add Unicode Properties to <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code></em> has been <a href="https://forums.swift.org/t/accepted-se-0211-add-unicode-properties-to-unicode-scalar/13857/1">accepted with revisions</a>.</p>
<blockquote>
<p>The core team has accepted this proposal, with one revision:</p>
<ul>
<li>the <code class="language-plaintext highlighter-rouge">numericValue</code> property should be a <code class="language-plaintext highlighter-rouge">Double?</code> rather than a <code class="language-plaintext highlighter-rouge">Double</code>, with <code class="language-plaintext highlighter-rouge">nil</code> for non-numeric values rather than <code class="language-plaintext highlighter-rouge">NaN</code>.</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0214-DictionaryLiteral.md">SE-0214</a>: <em>Renaming the <code class="language-plaintext highlighter-rouge">DictionaryLiteral</code> type to <code class="language-plaintext highlighter-rouge">KeyValuePairs</code></em> has been <a href="https://forums.swift.org/t/accepted-with-revision-se-0214-renaming-the-dictionaryliteral-type-to-keyvaluepairs/13661">accepted with revisions</a>.</p>
<blockquote>
<p>In the review thread discussion, many names were considered, and the core team agreed that <code class="language-plaintext highlighter-rouge">KeyValuePairs</code> (initially <code class="language-plaintext highlighter-rouge">KeyValueList</code> was proposed) is a best name suggested on the thread for this type.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/aciidb0mb3r/">Ankit Aggarwal</a> shared some <a href="https://forums.swift.org/t/recent-swiftpm-features-and-enhancements/13807">features and enhancements</a> that have been brought to SwiftPM recently.</p>
<blockquote>
<ul>
<li>Improved scheme generation logic</li>
<li>Local dependencies</li>
<li>Automatic Xcode project generation</li>
<li>System library targets</li>
<li>Embeddable Xcode projects</li>
</ul>
</blockquote>
<p><a href="https://twitter.com/davedelong">Dave DeLong</a> and <a href="https://twitter.com/ericasadun">Erica Sadun</a> pitched <a href="https://forums.swift.org/t/introducing-namespacing-for-common-swift-error-scenarios/10773">a proposal</a> to introduce namespacing for common Swift error scenarios.</p>
<blockquote>
<p>This proposal introduces namespacing for fatal errors. It provides an umbrella for common exit scenarios, modernizing a holdover from C-like languages.</p>
<p>Swift’s <code class="language-plaintext highlighter-rouge">fatalError</code> is arguably insufficient for a multitude of real world uses including discoverability, extensibility, and significance. Swift lacks a modern extensible solution that differentiates fatal error scenarios.</p>
</blockquote>
<p>Awesome stuff!</p>
<p><a href="https://forums.swift.org/u/scanon/summary">Steve Canon</a> pitched <a href="https://forums.swift.org/t/comparable-and-floatingpoint/13931">a proposal</a> that aims to solve some issues around floating points and their <code class="language-plaintext highlighter-rouge">min</code> and <code class="language-plaintext highlighter-rouge">max</code> operations.</p>
<blockquote>
<p>There is a small but important tangle of issues around the interaction between <code class="language-plaintext highlighter-rouge">min</code> and <code class="language-plaintext highlighter-rouge">max</code> operations and <code class="language-plaintext highlighter-rouge">Comparable</code> and <code class="language-plaintext highlighter-rouge">FloatingPoint</code> protocols and the IEEE 754 standard that I would like to attempt to resolve.</p>
</blockquote>
<p><a href="https://twitter.com/aciidb0mb3r/">Ankit Aggarwal</a> shared <a href="https://forums.swift.org/t/swift-package-manager-evolution-ideas/13940">a list of SwiftPM evolution ideas</a> that could use some help to get proposals off the ground.</p>
<blockquote>
<p>This is a list of some evolution ideas for the package manager. Once the details of an idea are fleshed out and there is a full proposal, it can be scheduled for the swift-evolution process. It is important to note that not every idea on this list is guaranteed to become an official feature, and it all depends on where the design discussion leads us. Also, this is not meant to be an exhaustive feature list, if you have an idea for a feature that you think will be a valuable addition to the package manager, feel free to start a discussion about it.</p>
<p>If you’re interested in participating in a particular evolution idea, please familarize yourself with the existing discussion on that topic and start participating in the discussion thread of that idea.</p>
</blockquote>
<p><a href="https://twitter.com/nnnnnnnn">Nate Cook</a> pitched <a href="https://forums.swift.org/t/array-initializer-with-access-to-uninitialized-buffer/13689">a proposal</a> to add an <code class="language-plaintext highlighter-rouge">Array</code> initializer with access to its unitialized buffer.</p>
<blockquote>
<p>I’ve been thinking about a way of creating an array that would let us access the buffer of uninitialized memory, so that we could implement algorithms that don’t necessarily know the size in advance or need access to noncontiguous parts of an array.</p>
<p>There is currently no way to work with a buffer of uninitialized memory that then becomes a fully memory-managed <code class="language-plaintext highlighter-rouge">Array</code>. This limitation means that operations that don’t know the final size of their data in advance, or that need to access noncontiguous parts of an array, are less efficient than necessary, often requiring an extra copy. This proposal suggests a new initializer for <code class="language-plaintext highlighter-rouge">Array</code> and <code class="language-plaintext highlighter-rouge">ContiguousArray</code> that would provide access to a newly created array’s entire storage buffer.</p>
</blockquote>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a> pitched <a href="https://forums.swift.org/t/pitch-deprecate-strange-interpolations-in-swift-4-2/13694">a proposal</a> that aims to clean up some of the lesser known rough edges in String interpolation.</p>
<blockquote>
<p>So, everyone knows what a string interpolation looks like:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="nf">print</span><span class="p">(</span><span class="s">"Hello, </span><span class="se">\(</span><span class="n">firstName</span><span class="se">)</span><span class="s">!"</span><span class="p">)</span></code></pre></figure>
<blockquote>
<p>But let’s talk about some other things you might write, perhaps because you hate compiler engineers. What do you think these do?</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="nf">print</span><span class="p">(</span><span class="s">"Hello, </span><span class="se">\()</span><span class="s">!"</span><span class="p">)</span> <span class="c1">// #1</span>
<span class="nf">print</span><span class="p">(</span><span class="s">"Hello, </span><span class="se">\(</span><span class="nv">first</span><span class="p">:</span> <span class="n">firstName</span><span class="se">)</span><span class="s">!"</span><span class="p">)</span> <span class="c1">// #2</span>
<span class="nf">print</span><span class="p">(</span><span class="s">"Hello, </span><span class="se">\(</span><span class="n">firstName</span><span class="p">,</span> <span class="n">lastName</span><span class="se">)</span><span class="s">!"</span><span class="p">)</span> <span class="c1">// #3</span>
<span class="nf">print</span><span class="p">(</span><span class="s">"Hello, </span><span class="se">\(</span><span class="nv">first</span><span class="p">:</span> <span class="n">firstName</span><span class="p">,</span> <span class="nv">last</span><span class="p">:</span> <span class="n">lastName</span><span class="se">)</span><span class="s">!"</span><span class="p">)</span> <span class="c1">// #4</span></code></pre></figure>
<blockquote>
<p>Most people I’ve spoken to say “produce an error message”, and they’re right about #1—it produces the error “expected expression in list of expressions”. Maybe not the clearest message, but it’s not technically wrong.</p>
<p>But the other three? They actually compile without complaint and form a tuple.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/slava_pestov/status/1010043445203701760">Do you wish to take a leap of faith?</a></p>
Issue #111
https://swiftweeklybrief.com/issue-111
2018-06-14T00:00:00-07:00
2018-06-14T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Hi there SwiftWeekly readers! The last two weeks were full of exciting news with WWDC, interesting discussions on the Swift Unwrapped podcast and there’s plenty of new starter tasks for you, especially for SPM. Enjoy!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7823">SR-7823</a> [Package Manager] swift run intermingles SwiftPM status with tool output on stdout</li>
<li><a href="https://bugs.swift.org/browse/SR-7824">SR-7824</a> [Package Manager] SwiftPM ignores missing source symlinks</li>
<li><a href="https://bugs.swift.org/browse/SR-7825">SR-7825</a> [Package Manager] SwiftPM should consider a target with header files but no sources as a ClangTarget</li>
<li><a href="https://bugs.swift.org/browse/SR-7826">SR-7826</a> [Package Manager] SwiftPM should warn if it skips traversing a symlink which would contain sources in it</li>
<li><a href="https://bugs.swift.org/browse/SR-7829">SR-7829</a> [Package Manager] Bad error message when a tag doesn’t exist</li>
<li><a href="https://bugs.swift.org/browse/SR-7904">SR-7904</a> [Compiler] AST dump - can’t distinguish files</li>
<li><a href="https://bugs.swift.org/browse/SR-7933">SR-7933</a> [Tooling] SourceKit double-counts escaping and autoclosure attributes</li>
<li><a href="https://bugs.swift.org/browse/SR-7979">SR-7979</a> [Package Manager] Circular Dependency in SwiftPM Causes Segfault</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/154581">episode 61</a>, Jesse and JP with special guest <a href="https://twitter.com/gregheo">Greg Heo</a> discussed general announcements from WWDC 2018, not just limited to the Swift language.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/154699">episode 62</a>, Jesse and JP talk with <a href="https://twitter.com/tkremenek">Ted Kremenek</a>, the Swift Project Lead and manager of the Languages and Runtimes team at Apple.</p>
<h3 id="news-and-community">News and community</h3>
<p>The biggest news from the past two weeks is, of course, WWDC. There are plenty of videos to watch, but take a closer look into these Swift related videos:</p>
<ul>
<li><a href="https://developer.apple.com/videos/play/wwdc2018/401">What’s New in Swift</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2018/406/">Swift Generics</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2018/411/">Getting to Know Swift Package Manager</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2018/415/">Behind the Scenes of the Xcode Build Process</a></li>
</ul>
<p><a href="https://github.com/ole">Ole Begemann</a> made an easy-to-use <a href="https://github.com/ole/whats-new-in-swift-4-2">playground</a> that you can use to test the new features in Swift 4.2. If you prefer to read about it, check out Cosmin Pupăză’s article <a href="https://www.raywenderlich.com/194066/whats-new-in-swift-4-2">What’s New in Swift 4.2?</a>.</p>
<p>Greg Heo wrote a new post on Swift Unboxed, <a href="https://swiftunboxed.com/internals/diagnostics-warning-error/">Swift Diagnostics: #warning and #error</a>, about the new <code class="language-plaintext highlighter-rouge">#warning</code> and <code class="language-plaintext highlighter-rouge">#error</code> directive implementations.</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> wrote the second part of a <a href="https://modocache.io/swift-compiler-diagnostics-part-2">great article</a> about the interaction between the Swift frontend and LLVM in terms of emitting diagnostics.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> <a href="https://github.com/apple/swift/pull/17014">merged</a> optimizations for generation of optimal code for static String constants.</p>
<p>Xcode 10 Beta is now required to build <code class="language-plaintext highlighter-rouge">master</code> and <code class="language-plaintext highlighter-rouge">swift-4.2-branch</code>: <a href="https://github.com/apple/swift/pull/17000">#17000</a> and <a href="https://github.com/apple/swift/pull/17001">#17001</a>.</p>
<p><a href="https://github.com/adrian-prantl">Adrian Prantl</a> <a href="https://github.com/apple/swift/pull/16937">merged</a> “Use depth and index to lookup type metadata artificial variables”. The general purpose: “debug info support for generics is about to get a whole lot better”.</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> <a href="https://github.com/apple/swift/pull/17080">fixed</a> availability of inherited designated initializers.</p>
<blockquote>
<p>Inherited designated initializers got the same availability as the corresponding initialier in the superclass. However if the superclass was more available than the subclass, we would generate a diagnostic that a member cannot be more available than its containing type. This diagnostic had an unknown source location, since the location was for a synthesized declaration, causing confusion.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0215-conform-never-to-hashable-and-equatable.md">SE-0215</a>: <em>Conform <code class="language-plaintext highlighter-rouge">Never</code> to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code></em> is <a href="https://forums.swift.org/t/se-0215-conform-never-to-equatable-and-hashable/13586">under review</a>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">Never</code> is very useful for representing impossible code. Most people are familiar with it as the return type of functions like <code class="language-plaintext highlighter-rouge">fatalError</code>, but <code class="language-plaintext highlighter-rouge">Never</code> is also useful when working with generic classes.</p>
<p>For example, a <code class="language-plaintext highlighter-rouge">Result</code> type might use <code class="language-plaintext highlighter-rouge">Never</code> for its <code class="language-plaintext highlighter-rouge">Value</code> to represent something that <em>always</em> errors or use <code class="language-plaintext highlighter-rouge">Never</code> for its <code class="language-plaintext highlighter-rouge">Error</code> to represent something that <em>never</em> errors.</p>
<p>Conditional conformances to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> are also very useful when working with <code class="language-plaintext highlighter-rouge">enum</code>s so you can test easily or work with collections.</p>
<p>But those don’t play well together. Without conformance to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code>, <code class="language-plaintext highlighter-rouge">Never</code> disqualifies your generic type from being <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0216-dynamic-callable.md">SE-0216</a> <em>Introduce user-defined dynamically “callable” types</em> is <a href="https://forums.swift.org/t/se-0216-user-defined-dynamically-callable-types/13615">under review</a>.</p>
<blockquote>
<p>This proposal is a follow-on to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md">SE-0195 - Introduce User-defined “Dynamic Member
Lookup” Types</a>
which shipped in Swift 4.2. It introduces a new <code class="language-plaintext highlighter-rouge">@dynamicCallable</code> attribute, which marks
a type as being “callable” with normal syntax.</p>
<p>[…]</p>
<p>Swift is exceptional at interworking with existing C and Objective-C APIs and we would like to extend this interoperability to dynamic languages like Python, JavaScript, Perl, and Ruby. We explored this overall goal in a long design process wherein the Swift evolution community evaluated multiple different implementation approaches. The conclusion was that the best approach was to put most of the complexity into dynamic language specific bindings written as pure-Swift libraries, but add small hooks in Swift to allow these bindings to provide a natural experience to their clients.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/1005500623175815168">time to get some rest</a>!</p>
Issue #110
https://swiftweeklybrief.com/issue-110
2018-05-31T00:00:00-07:00
2018-05-31T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>With WWDC around the corner (it starts in four days!), it is not that big of a surprise that these last two weeks have been pretty quiet when it comes to Swift.</p>
<p>Also, come and say hi at WWDC!</p>
<!--excerpt-->
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/144991">episode 59</a>, Jesse and JP discuss implicit escaping of closures, explaining in how they (should) work.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/144992">episode 60</a>, Jesse and JP discuss Character Properties, a proposal pitch that aims to increase the usefulness of <code class="language-plaintext highlighter-rouge">Character</code> and approachability of programming in Swift.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/Ilseman">Michael Ilseman</a> has <a href="https://twitter.com/beccadax/status/1001351681370542080">improved</a> string interpolation in Swift 4.2 to be at least twice as fast! 🏎💨</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/ahoppen">Alex Hoppen</a> merged <a href="https://github.com/apple/swift/pull/16340">a pull request</a> that adds <a href="https://gist.github.com/ahoppen/3ae1a6cd64e558710a4afcd372e8fdc4">incremental syntax parsing</a> to the Swift compiler. Cool!</p>
<p><a href="https://github.com/millenomi">Lily Vulcano</a> merged <a href="https://github.com/apple/swift/pull/16022">a pull request</a> to bridge <code class="language-plaintext highlighter-rouge">as</code>, <code class="language-plaintext highlighter-rouge">as?</code>, and <code class="language-plaintext highlighter-rouge">as!</code> to Linux. 🎉</p>
<p><a href="https://github.com/gottesmm">Michael Gottesman</a> opened <a href="https://github.com/apple/swift/pull/16882">a pull request</a> to allow for benchmark testing on Linux.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0214-DictionaryLiteral.md">SE-0214</a>: <em>Renaming the <code class="language-plaintext highlighter-rouge">DictionaryLiteral</code> type to <code class="language-plaintext highlighter-rouge">KeyValueList</code></em> is <a href="https://forums.swift.org/t/se-0214-renaming-the-dictionaryliteral-type-to-keyvaluelist/12817">under review</a>.</p>
<blockquote>
<p>This proposal renames the confusing and misnamed <a href="https://github.com/apple/swift/blob/c25188bafd1c775d4ceecc4a795f614f00451bf9/stdlib/public/core/Mirror.swift#L646"><code class="language-plaintext highlighter-rouge">DictionaryLiteral</code></a> type to <code class="language-plaintext highlighter-rouge">KeyValueList</code>. This type is neither a dictionary nor a literal. It is a list of key-value pairs.</p>
<p>There is no strong motivation to deprecate. The type does not produce active harm. Instead, it adds measurable (if small) utility and will be part of the ABI. A sensible renaming mitigates the most problematic issue with the type.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/airspeedswift">Ben Cohen</a> started <a href="https://forums.swift.org/t/se-0202-amendment-proposal-rename-random-to-defaultrandomnumbergenerator/12942">a discussion</a> to change part of SE-0202, renaming <code class="language-plaintext highlighter-rouge">Random</code> to <code class="language-plaintext highlighter-rouge">DefaultRandomNumberGenerator</code>.</p>
<blockquote>
<p>SE-0202, as accepted, introduces a type, <code class="language-plaintext highlighter-rouge">Random</code>, as the default source of random numbers on each platform.</p>
<p>[..] the name <code class="language-plaintext highlighter-rouge">Random</code> for this default source is misleading, and would probably be better named <code class="language-plaintext highlighter-rouge">DefaultRandomNumberGenerator</code>.</p>
<p>One open question is the naming of the getter for an instance of the type. Currently it is <code class="language-plaintext highlighter-rouge">Random.default</code>. However, renaming <code class="language-plaintext highlighter-rouge">Random</code> leads to the rather clunky <code class="language-plaintext highlighter-rouge">DefaultRandomNumberGenerator.default</code>. Benjamin suggests <code class="language-plaintext highlighter-rouge">.shared</code>. However, in all current implementations, this is not strictly speaking a shared instance – it is instead a getter/setter for a fresh instance each time. This doesn’t actually have a cost, since the type has no actual size (the type is just a vehicle for calling an OS function), but needs to be done this way because <code class="language-plaintext highlighter-rouge">using:</code> is taken <code class="language-plaintext highlighter-rouge">inout</code>.</p>
<p>Any suggestions for better naming gratefully received.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/999040485309140992">Although not all may agree</a>…</p>
Issue #109
https://swiftweeklybrief.com/issue-109
2018-05-17T00:00:00-07:00
2018-05-17T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>I’m starting to get more excited about WWDC by the day right now. Looking forward to meeting people and learning about all new technologies and APIs that we will be seeing. It feels so long ago since last year’s WWDC!</p>
<p>Also, if you’re there too, feel free to say hi! 👋</p>
<p>That being said, here is another two weeks of interesting Open Source Swift news, including another few awesome proposals (I am not complaining, but what happened with that <a href="https://github.com/apple/swift-evolution#evolution-process-for-swift-5">March 1 “deadline”</a>?) and interesting announcements.</p>
<p>Enjoy!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7562">SR-7562</a> [Compiler] <code class="language-plaintext highlighter-rouge">@discardableResult</code> is disregarded for a required init method</li>
<li><a href="https://bugs.swift.org/browse/SR-7574">SR-7574</a> [Compiler] Use libfuzzer on the demangler</li>
<li><a href="https://bugs.swift.org/browse/SR-7624">SR-7624</a> [Compiler] Fixits for ‘Argument passed to call that takes no arguments’</li>
<li><a href="https://bugs.swift.org/browse/SR-7629">SR-7629</a> [Compiler] Wrong fixit when the type doesn’t conform to a public protocol</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/141585">episode 57</a>, Jesse and JP discuss the Swift for TensorFlow Design Overview that we mentioned two weeks ago.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/144196">episode 58</a>, Jesse and JP discuss the reimplentation of Implicitly Unwrapped Optionals (IUOs) in Swift, and what that brings us.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://github.com/najacque/">Nicole Jacque</a> and <a href="https://twitter.com/mishaldshah/">Mishal Shah</a> announced <a href="https://twitter.com/SwiftLang/status/992166029613674497">a community hosted Swift continuous integration</a> to make it easier to support more platforms for Swift.</p>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> announced that Swift for TensorFlow <a href="https://forums.swift.org/t/swift-for-tensorflow-to-be-developed-on-tensorflow-branch-on-apple-swift-on-github/12595">will be developed</a> on a <code class="language-plaintext highlighter-rouge">tensorflow</code> branch on apple/swift, allowing closer collaborations among the Swift and TensorFlow teams.</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> wrote <a href="https://modocache.io/llvm-memory-buffer">an article</a> on how Swift and Clang use LLVM to read files into memory.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/16563">a pull request</a> that eliminates more of <code class="language-plaintext highlighter-rouge">SubstitutionList</code>. In a followup <a href="https://github.com/apple/swift/pull/16568">pull request</a> all remaining <code class="language-plaintext highlighter-rouge">SubstitutionList</code>s have been removed.</p>
<blockquote>
<p>Introduced during the bring-up of the generics system in July, 2012, <code class="language-plaintext highlighter-rouge">Substitution</code> (and <code class="language-plaintext highlighter-rouge">SubstitutionList</code>) have been completely superseded by <code class="language-plaintext highlighter-rouge">SubstitutionMap</code>.</p>
</blockquote>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/16560">a pull request</a> that speeds up type checking for large array literals.</p>
<p><a href="https://github.com/atrick">Andrew Trick</a> merged <a href="https://github.com/apple/swift/pull/16595">a pull request</a> to speed up dynamic exclusivity checks in optimized builds.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0207-containsOnly.md">SE-0207</a>: <em>Add an <code class="language-plaintext highlighter-rouge">allSatisfy</code> algorithm to <code class="language-plaintext highlighter-rouge">Sequence</code></em> was <a href="https://forums.swift.org/t/accepted-with-revision-se-0207-add-a-containsonly-algorithm-to-sequence/12062">accepted with revisions</a>.</p>
<blockquote>
<p>The core team accepted one of the two proposed Sequence extensions, with a different name than was proposed:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">Sequence</span> <span class="p">{</span>
<span class="c1">/// Returns a Boolean value indicating whether every element of the sequence</span>
<span class="c1">/// satisfies the given predicate.</span>
<span class="kd">func</span> <span class="nf">allSatisfy</span><span class="p">(</span><span class="n">_</span> <span class="nv">predicate</span><span class="p">:</span> <span class="p">(</span><span class="kt">Element</span><span class="p">)</span> <span class="k">throws</span> <span class="o">-></span> <span class="kt">Bool</span><span class="p">)</span> <span class="k">rethrows</span> <span class="o">-></span> <span class="kt">Bool</span>
<span class="p">}</span></code></pre></figure>
<p>You can find more details about the decision behind the new name in the announcement.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0210-key-path-offset.md">SE-0210</a>: <em>Add an <code class="language-plaintext highlighter-rouge">offset(of:)</code> method to <code class="language-plaintext highlighter-rouge">MemoryLayout</code></em> was <a href="https://forums.swift.org/t/accepted-se-0210-add-an-offset-of-method-to-memorylayout/12531/2">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted as written. Thanks to everyone who participated in the review.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0212-compiler-version-directive.md">SE-0212</a>: <em>Compiler Version Directive</em> was <a href="https://forums.swift.org/t/accepted-se-0212-compiler-version-directive/12661">accepted</a>.</p>
<blockquote>
<p>SE-0212 — Compiler Version Directive has been accepted. There was no major concerns about the proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0213-literal-init-via-coercion.md">SE-0213</a>: <em>Literal initialization via coercion</em> was <a href="https://forums.swift.org/t/se-0213-literal-initialization-via-coercion/12540">under review</a> and consequently <a href="https://forums.swift.org/t/se-0213-literal-initialization-via-coercion/12540/18">accepted</a>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">T(literal)</code> should construct <code class="language-plaintext highlighter-rouge">T</code> using the appropriate literal protocol if possible.</p>
<p>Currently types conforming to literal protocols are type-checked using regular initializer rules, which means that for expressions like <code class="language-plaintext highlighter-rouge">UInt32(42)</code> the type-checker is going to look up a set of available initializer choices and attempt them one-by-one trying to deduce the best solution.</p>
</blockquote>
<hr />
<blockquote>
<p>The core team discussed this today. A line has to be drawn somewhere between this special syntactic rule and a general higher-order use of initializers as functions; <code class="language-plaintext highlighter-rouge">let f = T.init</code> is not going to preserve the special rule.</p>
<p>In that light, it makes sense to the core team to tie the special behavior to the existing special syntactic rule of type construction: currently, a “call” of <code class="language-plaintext highlighter-rouge">T</code> directly is recognized as always meaning a call to an initializer, whereas this syntax simply adjusts that to sometimes construct a literal.</p>
<p><code class="language-plaintext highlighter-rouge">T.init</code> is then reserved to always mean a higher-order use of the overloaded initializer set.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/tkremenek/">Ted Kremenek</a> announced support for <a href="https://swift.org/blog/related-projects/">related Swift projects</a> to be discussable on the Swift Forums.</p>
<blockquote>
<p>The number of projects in the Swift ecosystem keeps expanding and developers are using them more and more to help build their apps. While not officially a part of the language, they exist to provide a leg up on development with optimizations to accomplish specific sets of tasks.</p>
<p>Related Projects includes access to specific sub-categories that are dedicated to projects within the Swift community and are separate from the Swift language itself. This new section of Swift Forums is launching today with support for a number of projects, including:</p>
<ul>
<li>Kitura</li>
<li>SourceKitten</li>
<li>SwiftLint</li>
<li>SwiftNIO</li>
<li>SwiftProtobuf</li>
<li>Vapor</li>
</ul>
</blockquote>
<p><a href="https://github.com/milseman">Michael Ilseman</a> pitched <a href="https://forums.swift.org/t/pitch-character-and-string-properties/11620">a proposal</a> to increase the usefulness of <code class="language-plaintext highlighter-rouge">Character</code> and approachability of programming in Swift.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">String</code> is a collection whose element is <code class="language-plaintext highlighter-rouge">Character</code>, which represents an <a href="https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries">extended grapheme cluster</a> (commonly just called “grapheme”). This makes <code class="language-plaintext highlighter-rouge">Character</code> one of the first types encountered both by newcomers to Swift as well as by experienced Swift developers playing around in new domains (e.g. scripting). Yet <code class="language-plaintext highlighter-rouge">Character</code> exposes little functionality other than the ability to order it with respect to other characters, and a way to access the raw <a href="https://unicode.org/glossary/#unicode_scalar_value">Unicode scalar values</a> that comprise it.</p>
</blockquote>
<p><a href="https://github.com/devincoughlin">Devin Coughlin</a> announced that <a href="https://forums.swift.org/t/upgrading-exclusive-access-warning-to-be-an-error-in-swift-4-2/12704">exclusive access warnings will be treated as errors</a> in Swift 4.2.</p>
<blockquote>
<p>In the recent Swift 4.2 branch, the existing Swift 4.1 warning about ‘overlapping accesses’ is now an error in Swift 4 mode. This means that projects with this warning will fail to build with the Swift 4.2 compiler.</p>
<p>The warning typically arises when a mutating method that modifies a variable is passed a non-escaping closure that reads from the same variable.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/AirspeedSwift/status/996246070723133440">API design is hard</a>.</p>
<p><img src="https://camo.githubusercontent.com/071af844c09bcf65509e23de8516b251972c074e/68747470733a2f2f6d656469612e67697068792e636f6d2f6d656469612f54454f4546657679576c6558362f67697068792e676966" alt="gif" /></p>
Issue #108
https://swiftweeklybrief.com/issue-108
2018-05-03T00:00:00-07:00
2018-05-03T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Another two weeks have passed since the last issue, and its now May. How time flies! WWDC is creeping up, while the Swift team is still hard at work on Swift 4.2 and Swift 5.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7559">SR-7559</a> [Package Manager] Building <code class="language-plaintext highlighter-rouge">swiftpm</code> requires <code class="language-plaintext highlighter-rouge">rsync</code>, and crashes with an obscure message if not found</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/136613">episode 55</a>, Jesse and JP discuss <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md">SE-0202</a>, <em>Random Unification</em>.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/136614">episode 56</a>, Jesse and JP discuss <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0206-hashable-enhancements.md">SE-0206</a>, <em>Hashable Enhancements</em>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/twostraws">Paul Hudson</a> created <a href="https://www.whatsnewinswift.com/">a website</a> to show a nice overview of what’s new in Swift, browsable by version!</p>
<p><a href="https://github.com/rudkx">Mark Lacey</a> wrote a <a href="https://swift.org/blog/iuo/">blog post</a> on the official Swift blog, dicussing the reimplementation of Implicitly Unwrapped Optionals.</p>
<p>Google <a href="https://github.com/tensorflow/swift">announced</a> Tensorflow for Swift. To learn more about it, check out <a href="https://github.com/tensorflow/swift/blob/master/docs/DesignOverview.md">the Design Overview</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/milseman">Michael Ilseman</a> merged <a href="https://github.com/apple/swift/pull/16226">a pull request</a> that removes some <code class="language-plaintext highlighter-rouge">@inline</code> annotations, speeding up the compiler.</p>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> merged <a href="https://github.com/apple/swift/pull/16249">a pull request</a> that lays the groudwork to eliminate <code class="language-plaintext highlighter-rouge">SubstitutionList</code>, the old representation for a mapping of generic parameters to concrete types. To learn more about this, check out this <a href="https://twitter.com/slava_pestov/status/991148638683381760">Twitter thread</a>.</p>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/16300">a pull request</a> that improves exhaustiveness checking in <code class="language-plaintext highlighter-rouge">switch</code>es.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md">SE-0202</a>: <em>Random Unification</em> was <a href="https://forums.swift.org/t/accepted-se-202-random-unification/12040">accepted with revisions</a>.</p>
<blockquote>
<p>The core team has accepted this proposal, with the following revisions:</p>
<ul>
<li>
<p>The method to get a random element from a collection should be named <code class="language-plaintext highlighter-rouge">Collection.randomElement() -> Element?</code></p>
</li>
<li>
<p>Since not all platforms will be able to provide an implementation of random that’s a cryptographically secure source of randomness, and that different platforms and users have different priorities, the decision of exactly which implementation to use for the default random number generator will be left to that platform’s implementation of Swift.</p>
</li>
<li>
<p>The core team decided to keep the proposal’s use of static methods.</p>
</li>
<li>
<p>The random number generator argument should be taken <code class="language-plaintext highlighter-rouge">inout</code>.</p>
</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0207-containsOnly.md">SE-0207</a>: <em>Add a <code class="language-plaintext highlighter-rouge">containsOnly</code> algorithm to <code class="language-plaintext highlighter-rouge">Sequence</code></em> was <a href="https://forums.swift.org/t/se-0207-add-a-containsonly-algorithm-to-sequence/11686/102">accepted with revisions</a></p>
<blockquote>
<p>The core team accepted one of the two proposed Sequence extensions, with a different name than was proposed:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">Sequence</span> <span class="p">{</span>
<span class="c1">/// Returns a Boolean value indicating whether every element of the sequence</span>
<span class="c1">/// satisfies the given predicate.</span>
<span class="kd">func</span> <span class="nf">allSatisfy</span><span class="p">(</span><span class="n">_</span> <span class="nv">predicate</span><span class="p">:</span> <span class="p">(</span><span class="kt">Element</span><span class="p">)</span> <span class="k">throws</span> <span class="o">-></span> <span class="kt">Bool</span><span class="p">)</span> <span class="k">rethrows</span> <span class="o">-></span> <span class="kt">Bool</span>
<span class="p">}</span></code></pre></figure>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0210-key-path-offset.md">SE-0210</a>: <em>Add an <code class="language-plaintext highlighter-rouge">offset(of:)</code> method to <code class="language-plaintext highlighter-rouge">MemoryLayout</code></em> is <a href="https://forums.swift.org/t/review-se-0210-add-an-offset-of-method-to-memorylayout/12023">under review</a>.</p>
<blockquote>
<p>This proposal introduces the ability for Swift code to query the in-memory layout of stored properties in aggregates using key paths. Like the <code class="language-plaintext highlighter-rouge">offsetof</code> macro in C, <code class="language-plaintext highlighter-rouge">MemoryLayout<T>.offset(of:)</code> returns the distance in bytes between a pointer to a value and a pointer to one of its fields.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0211-unicode-scalar-properties.md">SE-0211</a>: <em>Add Unicode Properties to <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code></em> is <a href="https://forums.swift.org/t/se-0211-add-unicode-properties-to-unicode-scalar/12121">under review</a>.</p>
<blockquote>
<p>We propose adding a number of properties to the <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code> type to support both common and advanced text processing use cases, filling in a number of gaps in Swift’s text support compared to other programming languages.</p>
<p>The Swift String type, and related types like <code class="language-plaintext highlighter-rouge">Character</code> and <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code>, provide very rich support for Unicode-correct operations. String comparisons are normalized, grapheme cluster boundaries are automatically detected, and string contents can be easily accessed in terms of grapheme clusters, code points, and UTF-8 and -16 code units.</p>
<p>However, when drilling down to lower levels, like individual code points (i.e., <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code> elements), the current APIs are missing a number of fundamental features available in other programming languages. <code class="language-plaintext highlighter-rouge">Unicode.Scalar</code> lacks the ability to ask whether a scalar is upper/lowercase or what its upper/lowercase mapping is, if it is a whitespace character, and so forth.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0212-compiler-version-directive.md">SE-0212</a>: <em>Compiler Version Directive</em> is <a href="https://forums.swift.org/t/se-0212-compiler-version-directive/12267">under review</a>.</p>
<blockquote>
<p>This proposal introduces a <code class="language-plaintext highlighter-rouge">compiler</code> directive that is syntactically equivalent to the <code class="language-plaintext highlighter-rouge">#if swift</code> version check but checks against the version of the compiler, regardless of which compatibility mode it’s currently running in.</p>
<p>The <code class="language-plaintext highlighter-rouge">#if swift</code> check allows conditionally compiling code depending on the version of the language. Prior to Swift 4, the version of the compiler and the language were one and the same. But since Swift 4, the compiler can run in a compatibility mode for previous Swift versions, introducing an new version dimension. To support code across multiple compiler versions and compatibility modes, extra language versions are regularly introduced to represent old language versions running under compatibility mode.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://github.com/khanlou">Soroush Khanlou</a> pitched <a href="https://forums.swift.org/t/count-where-on-sequence/11186">a proposal</a> to add <code class="language-plaintext highlighter-rouge">count(where:)</code> to <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
<blockquote>
<p>While Swift’s <code class="language-plaintext highlighter-rouge">Sequence</code> models brings a lot of niceties that we didn’t have access to in Objective-C, like map and filter, there are other useful operations on <code class="language-plaintext highlighter-rouge">Sequence</code>s that the standard library doesn’t support yet. I’d like to pitch one today: <code class="language-plaintext highlighter-rouge">count(where:)</code>, which counts the number of objects in a Sequence that passes some test.</p>
</blockquote>
<p>You can read the proposal <a href="https://github.com/khanlou/swift-evolution/blob/count-where/proposals/XXXX-count-where.md">here</a>.</p>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> wrote <a href="https://forums.swift.org/t/implicit-escaping-of-closures-via-objective-c/12025">a request for discussion</a> regarding an issue with non-escaping closure parameters can escape through Objective-C.</p>
<blockquote>
<p>The easiest way to see the problem is to define an <code class="language-plaintext highlighter-rouge">@objc</code> protocol with a closure-taking method:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">@objc</span> <span class="kd">protocol</span> <span class="kt">Fooable</span> <span class="p">{</span>
<span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">completion</span><span class="p">:</span> <span class="p">()</span> <span class="o">-></span> <span class="kt">Void</span><span class="p">)</span> <span class="c1">// note: closure parameter is implicitly '@noescape'</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">useFooable</span><span class="p">(</span><span class="nv">fooable</span><span class="p">:</span> <span class="kt">Fooable</span><span class="p">,</span> <span class="nv">completion</span><span class="p">:</span> <span class="p">()</span> <span class="o">-></span> <span class="kt">Void</span><span class="p">)</span> <span class="p">{</span>
<span class="n">fooable</span><span class="o">.</span><span class="nf">foo</span><span class="p">(</span><span class="nv">completion</span><span class="p">:</span> <span class="n">completion</span><span class="p">)</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>And then implement that protocol in Objective-C</p>
</blockquote>
<figure class="highlight"><pre><code class="language-objc" data-lang="objc"><span class="k">@interface</span> <span class="nc">MyClass</span> <span class="p">:</span> <span class="nc">NSObject</span> <span class="o"><</span><span class="n">Fooable</span><span class="o">></span>
<span class="k">@end</span>
<span class="k">@implementation</span> <span class="nc">MyClass</span>
<span class="k">-</span> <span class="p">(</span><span class="kt">void</span><span class="p">)</span><span class="nf">fooWithCompletion</span><span class="p">:(</span><span class="kt">void</span> <span class="p">(</span><span class="o">^</span><span class="p">)(</span><span class="kt">void</span><span class="p">))</span><span class="nv">completion</span> <span class="p">{</span>
<span class="n">dispatch_async</span><span class="p">(</span><span class="n">dispatch_get_main_queue</span><span class="p">(),</span> <span class="n">completion</span><span class="p">);</span> <span class="c1">// oops, we escaped a no-escape block!</span>
<span class="p">}</span>
<span class="k">@end</span></code></pre></figure>
<blockquote>
<p>[..] I see a couple of potential solutions here, which aren’t mutually exclusive:</p>
<ul>
<li>Implicitly use <code class="language-plaintext highlighter-rouge">withoutActuallyEscaping</code> when calling an <code class="language-plaintext highlighter-rouge">@objc</code> API from Swift</li>
<li>Warn about non-escaping closure parameters in <code class="language-plaintext highlighter-rouge">@objc</code> entry points that can be implemented in Objective-C</li>
</ul>
<p>Thoughts?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Lets open the wound <a href="https://twitter.com/jckarter/status/988828156386684928">on access control</a> again, shall we? 😂</p>
Issue #107
https://swiftweeklybrief.com/issue-107
2018-04-19T00:00:00-07:00
2018-04-19T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Over the last two weeks we have seen a lot of proposals that have been discussed (and accepted), and it is likely we will see many of these proposals being released in either Swift 4.2 or Swift 5.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7445">SR-7445</a> [Compiler] Call Expressions Need Better Assignment Diagnostics</li>
<li><a href="https://bugs.swift.org/browse/SR-7398">SR-7398</a> [Compiler] Preserve availability on ObjC subscript getters and setters</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/130955">Episode 53</a> Jesse and JP discuss Swift for Tensorflow, which was announced in a talk by Chris Lattner at TensorFlow Dev Summit 2019.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/130967">Episode 54</a> Jesse and JP discuss some of the recent proposals on <code class="language-plaintext highlighter-rouge">Collection</code> and <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> wrote <a href="https://medium.com/@slavapestov/behind-the-scenes-improvements-in-swift-4-1-269dd56e30c2">a blog post</a> on some of the less-visible improvements in Swift 4.1.</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> wrote <a href="https://modocache.io/swift-compiler-diagnostics-part-1">a blog post</a> on how the Swift compiler emits diagnostics.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> merged <a href="https://github.com/apple/swift/pull/15843">a pull request</a> that makes progresson fully implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a>: <em>Distinguish between single-tuple and multiple-argument function types</em>.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> merged <a href="https://github.com/apple/swift/pull/15894">a pull request</a> to improve the Swift Intermediate Language (<a href="https://github.com/apple/swift/blob/master/docs/SIL.rst">SIL</a>)’s deserialization in <code class="language-plaintext highlighter-rouge">-Onone</code> mode — by 25% on a large project with batch mode! 👏</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0201-package-manager-local-dependencies.md">SE-0201</a>: <em>Package Manager Local Dependencies</em> was <a href="https://forums.swift.org/t/se-0201-package-manager-local-dependencies/11286/17">accepted</a>.</p>
<blockquote>
<p>Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0205-withUnsafePointer-for-lets.md">SE-0205</a>: <em><code class="language-plaintext highlighter-rouge">withUnsafePointer(to:_:)</code> and <code class="language-plaintext highlighter-rouge">withUnsafeBytes(of:_:)</code> for immutable values</em> was <a href="https://forums.swift.org/t/accepted-se-0205-withunsafepointer-to-and-withunsafebytes-of-for-immutable-values/11966">accepted</a>.</p>
<blockquote>
<p>The review of this proposal is now over and the proposal has been accepted.</p>
<p>Thanks for everyone for participating in the review.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0206-hashable-enhancements.md">SE-0206</a>: <em>Hashable Enhancements</em> was <a href="https://forums.swift.org/t/accepted-se-0206-hashable-enhancements/11675/115">accepted with revisions</a>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">init(seed:)</code>’s behavior may be misleading to users who expect it to enable deterministic hashing, and has no real benefit over a collection implementation seeding the hasher directly with combine calls.</p>
<p>[..] the many <code class="language-plaintext highlighter-rouge">combine(bits:)</code>overloads on <code class="language-plaintext highlighter-rouge">Hasher</code> that take fixed-sized integers don’t need to be public API.</p>
<p>The core team recommends that <code class="language-plaintext highlighter-rouge">Hasher.finalize()</code> be made a <code class="language-plaintext highlighter-rouge">__consuming</code> nonmutating method instead of a mutating method that invalidates the <code class="language-plaintext highlighter-rouge">Hasher</code> value.</p>
<p>Thanks again to everyone for participating in the review!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0208-package-manager-system-library-targets.md">SE-0208</a>: <em>Package Manager System Library Targets</em> was <a href="https://forums.swift.org/t/se-0208-package-manager-system-library-targets/11735">under review</a> and consequently <a href="https://forums.swift.org/t/se-0208-package-manager-system-library-targets/11735/16">accepted</a>.</p>
<blockquote>
<p>This proposal introduces a new type of target “system library target”, which moves the current system-module packages feature from package to target level.</p>
<p>The package manager currently supports “system-module packages” which are intended to adapt a system installed dependency to work with the package manager. However, this feature is only supported on package declarations, which mean libraries that need it often need to create a separate repository containing the system package and refer to it as a dependency.</p>
<p>Our original motivation in forcing system packages to be declared as standalone packages was to encourage the ecosystem to standardize on them, their names, their repository locations, and their owners. In practice, this effort did not work out and it only made the package manager harder to use.</p>
</blockquote>
<hr />
<blockquote>
<p>Feedback was positive, and the proposal is accepted. Thanks to everyone who participated!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0209-package-manager-swift-lang-version-update.md">SE-0209</a>: <em>Package Manager Swift Language Version API Update</em> was <a href="https://forums.swift.org/t/se-0209-package-manager-swift-language-version-api-update/11815">under review</a> and consequently <a href="https://forums.swift.org/t/accepted-se-0209-package-manager-swift-language-version-api-update/11962">accepted with revisions</a>.</p>
<blockquote>
<p>This proposal changes the current <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest API for declaring for Swift language versions from freeform Integer array to a new <code class="language-plaintext highlighter-rouge">SwiftVersion</code> enum array.</p>
<p>The Swift compiler now allows <code class="language-plaintext highlighter-rouge">4.2</code> as an accepted value of Swift version flag (<code class="language-plaintext highlighter-rouge">-swift-version</code>). The <code class="language-plaintext highlighter-rouge">swiftLanguageVersions</code> API in <code class="language-plaintext highlighter-rouge">Package.swift</code> currently accepts an integer array and we need to update this API in order for packages to declare this language version if required.</p>
</blockquote>
<hr />
<blockquote>
<p>Feedback was positive, and the proposal is accepted with revisions. Thanks to everyone who participated!</p>
<p>We considered making <code class="language-plaintext highlighter-rouge">SwiftVersion</code> a struct which conforms to <code class="language-plaintext highlighter-rouge">ExpressibleByIntegerLiteral</code> and <code class="language-plaintext highlighter-rouge">ExpressibleByStringLiteral</code>. However, we think the enum approach is better for several reasons:</p>
<ul>
<li>It is consistent with the C/C++ language version settings.</li>
<li>The package authors can easily tell which versions are available.</li>
<li>The package authors don’t need to concern themselves with how to spell a valid version.</li>
</ul>
</blockquote>
<h3 id="extended-proposals">Extended proposals</h3>
<p>The review of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md">SE-0202</a>: <em>Random Unification</em> was <a href="https://forums.swift.org/t/se-0202-random-unification/11313/149">extended</a> to get feedback on its design.</p>
<blockquote>
<p>The nature of the generator API implies that the generators must be reference-y, since they aren’t passed inout to functions like <code class="language-plaintext highlighter-rouge">shuffle</code>, but aren’t <em>required</em> to be reference types.</p>
<p>The team thinks making the <code class="language-plaintext highlighter-rouge">random(in: Range<T>)</code> family free functions, rather than static methods on <code class="language-plaintext highlighter-rouge">T</code>, may help with discoverability.</p>
<p>The team felt that <code class="language-plaintext highlighter-rouge">Collection.randomElement</code> would work better than <code class="language-plaintext highlighter-rouge">Collection.random</code>. Unlike <code class="language-plaintext highlighter-rouge">.first</code> or <code class="language-plaintext highlighter-rouge">.max</code>, the word “random” doesn’t noun well, so adding “Element” improves readability.</p>
<p>The core team believes it would be better to leave implementation details of the default source to the individual platforms, rather than defining the implementation for each platform as part of the proposal.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="http://twitter.com/ericasadun/status/970754573609484288">Erica Sadun</a> pitched <a href="https://forums.swift.org/t/introducing-role-keywords-to-reduce-hard-to-find-bugs/6113">a proposal</a> to introduce keywords in protocols that help eliminate bugs.</p>
<blockquote>
<p>We’d love to know what you think of our idea, which is to introduce “role” keywords. Roles allow the compiler to automatically check the intended use of a extension member definition against its protocol declarations, and emit errors, warnings, and fixits as needed.</p>
</blockquote>
<p>Erica also <a href="https://forums.swift.org/t/rfd-countedset/11792">shared some thoughts</a> about adding a <code class="language-plaintext highlighter-rouge">CountedSet</code> to Swift.</p>
<blockquote>
<p>I’m looking to take the community temperature about adding <code class="language-plaintext highlighter-rouge">CountedSet</code> to Swift Foundation/Standard Library.</p>
</blockquote>
<p><a href="https://github.com/JoeyKL">Joey KL</a> pitched <a href="https://forums.swift.org/t/rename-protocols-that-use-self-or-associated-types-to-constraints-and-declare-them-as-such/11944">a proposal</a> to rename protocols that use <code class="language-plaintext highlighter-rouge">Self</code> or associated types to “constraints”.</p>
<blockquote>
<p>There are two different types of protocols in Swift and they behave completely differently. Normal protocols are like any other type, use dynamic dispatch and allow for heterogenous mixtures of different implementations (similar to objects that inherit from the same base class). On the other hand, constraint protocols (distinguished only by having an <code class="language-plaintext highlighter-rouge">associatedtype</code>, or even more subtle, just using <code class="language-plaintext highlighter-rouge">Self</code>) use static dispatch, can never be used like a type, and can only be used to restrict which real types can be used for a generic function or new concrete type.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Swift’s goal <a href="https://twitter.com/Javi/status/985563399533686786">really is world domination</a>… 🏎</p>
Issue #106
https://swiftweeklybrief.com/issue-106
2018-04-05T00:00:00-07:00
2018-04-05T00:00:00-07:00
Greg Heo
https://twitter.com/gregheo
https://github.com/gregheo.png?size=100
gregheo
<blockquote>
<p>Lo! The forum posts and pitches fly on by<br />
What rants and revelations there await?<br />
Swift 5 remains a glimmer in the sky<br />
As compactMap arrives to disorientate.<br />
<br />
New Xcode versions, filled with all-new fix-its<br />
And random numbers, ascribing golden tickets.<br /></p>
</blockquote>
<p>There’s been plenty of news to make developers experience the full range of emotions: <a href="https://developer.apple.com/news/releases/?id=03292018d">Xcode 9.3</a> with <a href="https://swift.org/blog/swift-4-1-released/">Swift 4.1</a> made it out of the gate, the WWDC ticket lottery smiled on some and caused gnashing of teeth in others.</p>
<p>Meanwhile, Swift 4.2 and beyond await us. As a reminder, the final merge into the Swift 4.2 branch before the soak period is <a href="https://swift.org/blog/4-2-release-process/">coming up in two weeks, on April 20</a>.</p>
<p>What’s new in the world of Swift? Read on!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7323">SR-7323</a>: SPM can’t handle spaces in path to Xcode</li>
<li><a href="https://bugs.swift.org/browse/SR-7307">SR-7307</a>: Warn when a block contains nothing but a defer statement</li>
<li><a href="https://bugs.swift.org/browse/SR-7301">SR-7301</a>: Bad fixit suggested for protocol extension implementation for inherited objc protocol</li>
<li><a href="https://bugs.swift.org/browse/SR-7292">SR-7292</a>: Swift local refactoring: adding field-wise initializers automatically</li>
<li><a href="https://bugs.swift.org/browse/SR-7266">SR-7266</a>: <code class="language-plaintext highlighter-rouge">reversed()</code> applied multiple times should not nest <code class="language-plaintext highlighter-rouge">ReversedCollection</code> into itself</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/125760">Episode 51</a> is the long-awaited Part 2 of Doug Gregor and Ben Cohen discussing Swift 4.1.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/129738">Episode 52</a>, JP and Jesse cover two new pitches regarding Swift Package Manager.</p>
<h3 id="news-and-community">News and community</h3>
<p>Languages & Runtime manager <a href="https://twitter.com/tkremenek">Ted Kremenek</a> shared photos of some <a href="https://twitter.com/tkremenek/status/977268865066450944">new office decorations over at Swift HQ</a>. 🤖</p>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> announced <a href="https://groups.google.com/a/tensorflow.org/forum/#!topic/swift/xtXCEvtDe5Q">Swift for TensorFlow</a>, bringing first-class compiler and language support for the machine learning framework. Aside from the post, you can also <a href="https://www.youtube.com/watch?list=PLQY2H8rRoyvxjVx3zfw4vA4cvlKogyLNN&v=Yze693W4MaU">watch the video announcement</a> presented at the TensorFlow Dev Summit 2018 by Chris and Richard Wei.</p>
<p><a href="https://www.tryswift.co/events/2018/sanjose/">try! Swift San Jose</a> was announced, with a focus on Swift Evolution and all the other Swift open source projects.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/gregomni">Greg Titus</a> fixed a <a href="https://github.com/apple/swift/pull/15488">compiler crash</a> that happened when a <code class="language-plaintext highlighter-rouge">case</code> statement had both <code class="language-plaintext highlighter-rouge">let</code> and <code class="language-plaintext highlighter-rouge">var</code> <a href="https://bugs.swift.org/browse/SR-7261">bindings for the same name</a>.</p>
<p><a href="https://github.com/stephentyrone">Stephen Canon</a> merged a change to how <code class="language-plaintext highlighter-rouge">description</code> and <code class="language-plaintext highlighter-rouge">debugDescription</code> <a href="https://github.com/apple/swift/pull/15474">display floating-point values</a>. The diff is a fascinating read into a fast and simple algorithm, and be sure to check out the chart showing the performance gains! 😍</p>
<p><a href="https://github.com/lorentey">Karoy Lorentey</a> merged his pull request to add <a href="https://github.com/apple/swift/pull/15382">conditional conformance to <code class="language-plaintext highlighter-rouge">Hashable</code> in more standard library types</a>. Optionals, arrays, dictionaries, and ranges (among other types) can now participate in <a href="https://forums.swift.org/t/amendment-se-0143-conditional-conformance-add-hashable-conformance-to-std-lib-types/11401">synthesized <code class="language-plaintext highlighter-rouge">Hashable</code> conformance</a>.</p>
<p><a href="https://github.com/rudkx">Mark Lacey</a> landed a change to <a href="https://github.com/apple/swift/pull/15419">fix type checking going exponential</a> for tuple literals. One fewer case of Xcode complaining that a type check took too long? ⏱</p>
<p><a href="https://github.com/milseman">Michael Ilseman</a> added the <a href="https://github.com/apple/swift/pull/14755">new <code class="language-plaintext highlighter-rouge">SmallString</code> type to the standard library</a>. The type is supported on 64-bit architectures and offers optimizations specific for (you guessed it) small strings.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a>: <em>Non-Exhaustive Enums</em> is <a href="https://forums.swift.org/t/se-0192-non-exhaustive-enums-review-2/11043/62">out of re-review and has been accepted with revisions</a>.</p>
<p>This proposal introduces <em>frozen</em> vs <em>non-frozen</em> enumerations, and the final revisions add the new <code class="language-plaintext highlighter-rouge">@unknown</code> attribute.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0201-package-manager-local-dependencies.md">SE-0201</a>: <em>Package Manager Local Dependencies</em> by <a href="https://github.com/aciidb0mb3r">Ankit Aggarwal</a> was <a href="https://forums.swift.org/t/accepted-se-0201-package-manager-local-dependencies/11629">accepted</a>.</p>
<p>This proposal allows you to declare a package dependency via a local path rather than a remote URL.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0200-raw-string-escaping.md">SE-0200</a>: <em>“Raw” mode string literals</em> by <a href="https://github.com/johnno1962">John Holdsworth</a> was <a href="https://forums.swift.org/t/returned-for-revision-se-0200-raw-mode-string-literals/11630">returned for revision</a>.</p>
<p>This proposal had a ton of discussion in the thread. The two main reasons for returning the proposal for revision were:</p>
<blockquote>
<ul>
<li>The proposed <code class="language-plaintext highlighter-rouge">r"..."</code> syntax didn’t fit well with the rest of the language.</li>
<li>The proposal itself leans heavily on regular expressions as a use case for raw string literals… a revised proposal will need additional motivating examples in other domains.</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0202-random-unification.md">SE-0202</a>: <em>Random Unification</em> by <a href="https://github.com/Azoy">Alejandro Alonso</a> is just out of review, <a href="https://forums.swift.org/t/se-0202-random-unification/11313">awaiting results</a>.</p>
<p>This proposal adds <code class="language-plaintext highlighter-rouge">random()</code> static function to numeric types and collections, a <code class="language-plaintext highlighter-rouge">shuffled()</code> method to sequences, as well as a <code class="language-plaintext highlighter-rouge">shuffle()</code> method to mutable collections.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0203-rename-sequence-elements-equal.md">SE-0203</a>: <em>Rename Sequence.elementsEqual</em> by <a href="https://github.com/xwu">Xiaodi Wu</a> is <a href="https://forums.swift.org/t/se-0203-rename-sequence-elementsequal/11482">in review</a>.</p>
<p>This proposal would remove a point of confusion where <code class="language-plaintext highlighter-rouge">==</code> and <code class="language-plaintext highlighter-rouge">elementsEqual(_:)</code> could return different results.</p>
<blockquote>
<p>Having surveyed alternative solutions to this problem, it is proposed that the method be renamed to <code class="language-plaintext highlighter-rouge">Sequence.elementsEqualInIterationOrder</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0204-add-last-methods.md">SE-0204</a>: <em>Add last(where:) and lastIndex(where:) Methods</em> by <a href="https://github.com/natecook1000">Nate Cook</a> is <a href="https://forums.swift.org/t/se-0204-add-last-where-and-lastindex-where-methods/11486">in review</a>.</p>
<p>We already have methods <code class="language-plaintext highlighter-rouge">first(where:)</code> and <code class="language-plaintext highlighter-rouge">index(where:)</code>, and this proposal would add similar methods to search from the end rather than from the beginning.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/78332d211d00abac286c47609ce1a88a03c6e9bf/proposals/0206-hashable-enhancements.md">SE-0206</a>: <em>Hashable Enhancements</em> by Karoy Lorentey and Vincent Esche is <a href="https://forums.swift.org/t/se-0206-hashable-enhancements/11675">in review until April 13</a>.</p>
<blockquote>
<p>This proposal introduces a new <code class="language-plaintext highlighter-rouge">Hasher</code> type representing the standard library’s universal hash function, and it extends the <code class="language-plaintext highlighter-rouge">Hashable</code> protocol with a new <code class="language-plaintext highlighter-rouge">hash(into:)</code> requirement that expresses hashing in terms of <code class="language-plaintext highlighter-rouge">Hasher</code>. […] Standardizing on a single, high-quality hash function greatly improves the reliability of <code class="language-plaintext highlighter-rouge">Set</code> and <code class="language-plaintext highlighter-rouge">Dictionary</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0207-containsOnly.md">SE-0207</a>: <em>Add a <code class="language-plaintext highlighter-rouge">containsOnly</code> algorithm to <code class="language-plaintext highlighter-rouge">Sequence</code></em> by Ben Cohen is <a href="https://forums.swift.org/t/se-0207-add-a-containsonly-algorithm-to-sequence/11686">under review</a>.</p>
<blockquote>
<p>It is common to want to confirm that every element of a sequence equals a value, or matches a certain criteria. Many implementations of this can be found in use on GitHub. This proposal adds such a method to <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
</blockquote>
<p>Instead of this:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// every element is 9</span>
<span class="o">!</span><span class="n">nums</span><span class="o">.</span><span class="n">contains</span> <span class="p">{</span> <span class="nv">$0</span> <span class="o">!=</span> <span class="mi">9</span> <span class="p">}</span></code></pre></figure>
<p>You’ll be able to do this:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="n">nums</span><span class="o">.</span><span class="nf">containsOnly</span><span class="p">(</span><span class="mi">9</span><span class="p">)</span></code></pre></figure>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> <a href="https://github.com/apple/swift-evolution/pull/818/files?diff=unified">suggested a proposal to add <code class="language-plaintext highlighter-rouge">offset(of:)</code> to <code class="language-plaintext highlighter-rouge">MemoryLayout</code></a>.</p>
<blockquote>
<p>This proposal introduces the ability for Swift code to query the in-memory layout of stored properties in aggregates using key paths.</p>
<p><code class="language-plaintext highlighter-rouge">MemoryLayout<Rect>.offset(of: \.origin.x) // => 0</code></p>
<p><code class="language-plaintext highlighter-rouge">MemoryLayout<Rect>.offset(of: \.origin.y) // => 8</code></p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/khanlou">Soroush Khanlou</a> <a href="https://forums.swift.org/t/count-where-on-sequence/11186">pitched an addition to <code class="language-plaintext highlighter-rouge">Sequence</code></a> to provide <code class="language-plaintext highlighter-rouge">count(where:)</code>:</p>
<blockquote>
<p>While Swift’s Sequence models brings a lot of niceties that we didn’t have access to in Objective-C, like <code class="language-plaintext highlighter-rouge">map</code> and <code class="language-plaintext highlighter-rouge">filter</code>, there are other useful operations on Sequences that the standard library doesn’t support yet. I’d like to pitch one today: <code class="language-plaintext highlighter-rouge">count(where:)</code>, which counts the number of objects in a Sequence that passes some test.</p>
<p><code class="language-plaintext highlighter-rouge">[1, 2, 3, -1, -2].count(where: { $0 > 0 }) // => 3</code></p>
</blockquote>
<p><a href="https://twitter.com/ilseman">Michael Ilseman</a> wrote a pitch for <a href="https://forums.swift.org/t/pitch-character-and-string-properties/11620">character and string properties</a>. This would add support for some handy computed properties such as <code class="language-plaintext highlighter-rouge">isWhitespace</code> and <code class="language-plaintext highlighter-rouge">isAscii</code> on characters, and helper structs and methods on strings to split lines and words.</p>
<p>Why not reach into string and character properties and do all this yourself? Short answer: Unicode is hard. 😓</p>
<blockquote>
<p>[There] is potential harm in developers reaching for these properties to solve common tasks without understanding their deep implications in Unicode. Whenever possible, we believe the best form of harm-reduction is providing more ergonomic APIs with more appropriate semantics for these common tasks.</p>
</blockquote>
<p>A few weeks ago, <a href="https://twitter.com/graydon_pub">Graydon Hoare</a> posted about the new <a href="https://forums.swift.org/t/compilation-speed-help-test-batch-mode/10964">compiler batch mode</a> that could speed up your Swift compile times. The thread has a lot of real-world results from people trying things out on their own code bases; have a look if you’re interested in what might be coming up in future releases.</p>
<h3 id="o-rly">O RLY?</h3>
<p>Finally: I can’t wait for <code class="language-plaintext highlighter-rouge">#error</code> and <code class="language-plaintext highlighter-rouge">#warning</code> to land in Swift 4.2, but in the meantime <a href="https://github.com/CodaFi/swift/blob/72f19c9565ae7da1fe8bb7a4d02ff51cec9caa54/test/Interpreter/lolcode.swift">at least there’s Swift support for <code class="language-plaintext highlighter-rouge">#lolcode</code></a>. 😹</p>
Issue #105
https://swiftweeklybrief.com/issue-105
2018-03-23T00:00:00-07:00
2018-03-23T00:00:00-07:00
Tapan Thaker
https://twitter.com/tapthaker
https://github.com/tapthaker.png?size=100
tapthaker
<p>Hello again! 👋 This week Apple announced the <a href="https://developer.apple.com/wwdc/">WWDC 2018</a> which will be held from June 4-8 in San Jose, CA. Doug Gregor and Ben Cohen discussed some insights on the Swift 4.1 release on Swift Unwrapped.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-7083">SR-7083</a> [Compiler] <code class="language-plaintext highlighter-rouge">lazy</code> properties can’t have observers</li>
<li><a href="https://bugs.swift.org/browse/SR-7053">SR-7053</a> [Package Manager] SwiftPM command line autocompletion script for <code class="language-plaintext highlighter-rouge">zsh</code> produces error: “invalid option definition:…” on completion</li>
<li><a href="https://bugs.swift.org/browse/SR-7015">SR-7015</a> [Compiler] The CoreFoundation conditional downcast diagnostic is not as helpful as it should be</li>
<li><a href="https://bugs.swift.org/browse/SR-6982">SR-6982</a> [Compiler] Improve internal compiler consistency</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/125759">50: Swift 4.1 with Doug and Ben (part 1)</a>: Jesse and JP discuss Swift 4.1 with Ben Cohen and Doug Gregor from the Swift team.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/tkremenek">Ted Kremenek</a> <a href="https://twitter.com/tkremenek/status/972519788386836480">shared</a> some insights on the release plan for Swift 5: the expected release date right now is Late 2018.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> <a href="https://twitter.com/slava_pestov/status/975100888007114752">shared</a> how seemingly similar code (<code class="language-plaintext highlighter-rouge">nil</code> versus <code class="language-plaintext highlighter-rouge">.none</code>) can have a big effect under the hood when it comes to code generation.</p>
<p><a href="https://twitter.com/ericasadun">Erica Sadun</a> wrote a <a href="http://ericasadun.com/2018/03/09/swift-evolution-and-civility/">blog post</a> on “Swift Evolution and Civility” regarding the controversy of accepting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md">SE-0199</a>: <em>Adding <code class="language-plaintext highlighter-rouge">toggle</code> to <code class="language-plaintext highlighter-rouge">Bool</code></em>. Be nice!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/lorentey">Karoy Lorentey</a> merged a <a href="https://github.com/apple/swift/pull/14913">pull request</a> which made Swift use a much higher-quality hashing with random seeding. You can read about this change on the <a href="https://forums.swift.org/t/psa-the-stdlib-now-uses-randomly-seeded-hash-values/10789">Swift Forums</a>.</p>
<blockquote>
<p>“Random seeding” means that <code class="language-plaintext highlighter-rouge">hashValue</code> properties will return different values on each execution of a Swift program. This is an important tool for improving the reliability of the Standard Library’s hashing collections, <code class="language-plaintext highlighter-rouge">Set</code> and <code class="language-plaintext highlighter-rouge">Dictionary</code>. In particular, random seeding enables better protection against (accidental or deliberate) <a href="https://arstechnica.com/information-technology/2011/12/huge-portions-of-web-vulnerable-to-hashing-denial-of-service-attack/">hash-flooding attacks</a>.</p>
</blockquote>
<p><a href="https://github.com/jckarter">Joe Groff</a> merged a <a href="https://github.com/apple/swift/pull/15145/">pull request</a> that made generic parameter counts in context descriptors 16-bit from 32-bit, reducing the metadata.</p>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> opened a <a href="https://github.com/apple/swift/pull/15416">pull request</a> that further implement generic <code class="language-plaintext highlighter-rouge">typealias</code>es. It will be completed once <a href="https://github.com/slavapestov">Slava Pestov</a>’s <a href="https://github.com/apple/swift/pull/9866">pull request</a> has been merged too.</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> merged a <a href="https://github.com/apple/swift/pull/15313">pull request</a> that cleans up the <code class="language-plaintext highlighter-rouge">@noescape</code> closure implementation in the Swift Intermediate Language (SIL).</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md">SE-0194</a> <em>Derived Collection of Enum Cases</em> was <a href="https://forums.swift.org/t/accepted-se-0194-derived-collection-of-enum-cases/10723">accepted</a> with revisions.</p>
<blockquote>
<p>The proposal is accepted with revisions. The specific changes to the proposal as reviewed are:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">@objc</code> enums defined in Swift will receive automatic synthesis of the list of all cases. […]</li>
<li>Unavailable cases will not be listed, because values of an unavailable case cannot exist in a well-typed Swift program (in breaks the availability model).</li>
<li>Automatic synthesis is only provided when the conformance is stated on the enum definition (not an extension) [… ]</li>
<li>The protocol, associated type, and property are named <code class="language-plaintext highlighter-rouge">CaseIterable</code>, <code class="language-plaintext highlighter-rouge">AllCases</code>, and <code class="language-plaintext highlighter-rouge">allCases</code>, respectively. The core team felt that these names reflect the primary use case of this protocol, promoting better clarity for most code that iterates over all of the cases. We chose <code class="language-plaintext highlighter-rouge">Iterable</code> over <code class="language-plaintext highlighter-rouge">Enumerable</code> because <code class="language-plaintext highlighter-rouge">Enumerable</code> has some incorrect connotations (e.g., the <code class="language-plaintext highlighter-rouge">enumerated()</code> method).</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md">SE-0193</a>: <em>Cross-module inlining and specialization</em> is <a href="https://forums.swift.org/t/se-0193-cross-module-inlining-and-specialization/7310/59">under extended review</a>.</p>
<blockquote>
<p>This proposal will essentially be accepted as is — except for the name for <code class="language-plaintext highlighter-rouge">@abiPublic</code>. Many people voiced concern for this name. While it technically is accurate, it exposes the term “abi” which will be foreign to many. It also doesn’t connote the full implications and value of adding the attribute.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a>: <em>Non-Exhaustive Enums</em> is in <a href="https://forums.swift.org/t/se-0192-non-exhaustive-enums/7291">re-review</a>.</p>
<blockquote>
<p>The second review is a follow up to the <a href="https://forums.swift.org/t/se-0192-non-exhaustive-enums/7291">original review</a> based on feedback on the thread and from the Core Team.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> <a href="https://forums.swift.org/t/adding-result-to-the-standard-library/6932/55">shared</a> some insights on the plans to standardize the <code class="language-plaintext highlighter-rouge">Result</code> type in Swift — and why it may still take some time.</p>
<blockquote>
<p>I personally think it is time to standardize Result, and I believe that several other core team members feel the same way. The major problem with doing so is that is blocked by an unresolved disagreement (in both the core team and community): whether Swift should support typed errors.</p>
</blockquote>
<p><a href="https://github.com/aciidb0mb3r">Ankit Aggarwal</a> & <a href="https://github.com/ddunbar">Daniel Dunbar</a> proposed <a href="https://github.com/aciidb0mb3r/swift-evolution/blob/extensible-tool/proposals/NNNN-package-manager-extensible-tools.md"><em>Package Manager Extensible Build Tools</em></a>. This will allow community build tools (<a href="https://github.com/krzysztofzablocki/Sourcery">Sourcery</a>, <a href="https://github.com/realm/SwiftLint">SwiftLint</a>, <a href="https://github.com/realm/jazzy">Jazzy</a>, etcetera) to integrate with the Swift Package Manager. You can contribute & follow the discussion on the <a href="https://forums.swift.org/t/package-manager-extensible-build-tools/10900">Swift Forums</a>.</p>
<blockquote>
<p>This is a proposal for adding package manager support for extensible build tools, i.e. executing tools at build time which were themselves produced by some other package, and whose behavior the package manager does not understood directly, but rather interacts through a well-defined, Swift, protocol.</p>
<p>We expect this behavior to greatly enhance our capacity for building complex software packages.</p>
</blockquote>
<p><a href="https://github.com/graydon">Graydon Hoare</a> <a href="https://forums.swift.org/t/compilation-speed-help-test-batch-mode/10964">wrote</a> about a new compilation mode called “batch” or “multiple file” mode. There are instructions to try it out in the post.</p>
<blockquote>
<p>This new mode takes the set of files that would normally be (incrementally) compiled with individual subprocesses, and assigns them dynamically to multiple batches (one per core), compiling each batch with a single process. This means that incremental mode is still operative, and compilation makes use of multiple cores, but the benefits of whole-module mode (fewer processes, less redundant work) also apply.</p>
</blockquote>
<p><a href="https://github.com/erica">Erica Sadun</a> <a href="https://forums.swift.org/t/pitch-introducing-the-unwrap-or-die-operator-to-the-standard-library/6207">pitched</a> and opened a <a href="https://github.com/apple/swift-evolution/pull/811">pull request</a> to propose an “Unwrap-or-Die operator”.</p>
<blockquote>
<p>Using an operator to provide feedback on the context of a failed unwrap has become a commonly implemented approach in the Swift developer Community. What are your thoughts about adopting this widely-used operator into the standard library?</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">guard</span> <span class="o">!</span><span class="n">lastItem</span><span class="o">.</span><span class="n">isEmpty</span> <span class="k">else</span> <span class="p">{</span> <span class="k">return</span> <span class="p">}</span>
<span class="k">let</span> <span class="nv">lastItem</span> <span class="o">=</span> <span class="n">array</span><span class="o">.</span><span class="n">last</span> <span class="o">!!</span> <span class="s">"Array must be non-empty"</span></code></pre></figure>
<p><a href="https://twitter.com/stephencelis">Stephen Celis</a> <a href="https://forums.swift.org/t/when-should-standard-library-functions-crash/10661">shared</a> some thoughts on when a function can/should crash.</p>
<blockquote>
<p>For example: <code class="language-plaintext highlighter-rouge">Dictionary.init(uniqueKeysAndValues😃</code> crashes on duplicate keys. While I can understand the reasoning to throw somehow on a collision, nothing about the name makes it feel “unsafe.” I’d hope the type system would have my back and use <code class="language-plaintext highlighter-rouge">throws</code> for these kinds of things.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/cocoawithlove/status/974680586966233088">How big can a view controller get?</a> 😆</p>
Issue #104
https://swiftweeklybrief.com/issue-104
2018-03-08T00:00:00-08:00
2018-03-08T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A lot has happened in the past two weeks. Apple introduced a new open source framework, a new Xcode beta was released (with improved compile-times!) and Swift 4.2 was announced. And of course, Swift 5 has seen another two weeks of progress.</p>
<p>So, without further ado…</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-6979">SR-6979</a> [Compiler] <code class="language-plaintext highlighter-rouge">thin_to_thick_function</code> derived pointers do not need to be retained/released</li>
<li><a href="https://bugs.swift.org/browse/SR-6960">SR-6960</a> [Standard Library] Floating-point <code class="language-plaintext highlighter-rouge">nextUp</code> and <code class="language-plaintext highlighter-rouge">nextDown</code> are unnecessarily slow for concrete types</li>
<li><a href="https://bugs.swift.org/browse/SR-6889">SR-6889</a> [Compiler] Use <code class="language-plaintext highlighter-rouge">ArgMemOnly</code> for runtime functions</li>
<li><a href="https://bugs.swift.org/browse/SR-6789">SR-6789</a> [Foundation] <code class="language-plaintext highlighter-rouge">IndexPath</code> needs benchmarks</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/117689">episode 48</a>, Jesse and JP discuss the Google Summer Of Code 2018 and Swift’s participation in the project. In <a href="https://spec.fm/podcasts/swift-unwrapped/117707">episode 49</a>, they discuss <a href="https://twitter.com/davedelong">Dave DeLong</a>’s Swift Protocol Wishlist, looking at the possibilities of Swift Protocols without boundaries.</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple <a href="https://download.developer.apple.com/Developer_Tools/Xcode_9.3_beta_4/Release_Notes_for_Xcode_9.3_beta_4.pdf">released</a> Xcode 9.3 beta 4. Erica Sadun <a href="http://ericasadun.com/2018/03/05/new-to-swift-in-xcode-9-3-beta-4-se-0075-and-se-0190-allow-better-configuration-testing/">wrote</a> about some of the included Swift changes (<code class="language-plaintext highlighter-rouge">canImport</code> and <code class="language-plaintext highlighter-rouge">targetEnvironment</code>).</p>
<p>Ted Kremenek <a href="https://swift.org/blog/4-2-release-process/">announced</a> Swift 4.2 and its planned release process. Swift 4.2 “is meant to be a waypoint towards achieving ABI stability in Swift 5 [..] as well as have a goal of some focused improvements on compile-time performance”. 🎉</p>
<p>Jordan Rose <a href="http://belkadan.com/blog/2018/02/Many-to-Many-Protocols/">wrote</a> a blog post exploring types with multiple <code class="language-plaintext highlighter-rouge">RawValue</code>s.</p>
<p>Ben Asher <a href="https://twitter.com/benasher44/status/968905975724892160">shared</a> their clean build times (with the “old” build system) decreased by 4 minutes compared to Xcode 9.2; from 11 minutes to 7 minutes, that’s a 36% speedup!</p>
<p>Alfredo Delli Bovi <a href="https://twitter.com/adellibovi/status/969012500682477568">shared</a> similar results, going from 7 and a half minutes to 5. 🏎</p>
<p>At try! Swift, Norman Maurer introduced <a href="https://github.com/apple/swift-nio">SwiftNIO</a>, “a cross-platform asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients”.
Interesting to note is that they are using <a href="https://github.com/apple/swift-nio/issues">GitHub Issues</a>; no JIRA!</p>
<p>Vapor then <a href="https://twitter.com/codevapor/status/970012673852178432">integrated</a> with SwiftNIO mere days after the announcement. They were able to delete nearly 15.000 lines of code! 😮</p>
<p>Marcin Krzyżanowski <a href="https://pspdfkit.com/blog/2018/first-class-swift-api-for-objective-c-frameworks/">wrote</a> how they created a first-class Swift API for an Objective-C framework, using all the amazing bridging and attributes available.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/lorentey">Karoy Lorentey</a> worked on a <a href="https://github.com/apple/swift/pull/14913">pull request</a> to use <code class="language-plaintext highlighter-rouge">SipHash-1-3</code> for all hashing.</p>
<blockquote>
<p>This PR intends to improve matters by standardizing on a high quality hash function, SipHash, for use inside the standard library and inside compiler-synthesized <code class="language-plaintext highlighter-rouge">Hashable</code> implementations. (SipHash is already implemented in the Standard Library, but so far it has been sitting there largely unused.)</p>
<p>This pull request does not introduce a public API to help with manual <code class="language-plaintext highlighter-rouge">Hashable</code> implementations — but it provides the first step towards providing one.</p>
</blockquote>
<p><a href="https://github.com/harlanhaskins">Harlan Haskins</a> created a <a href="https://github.com/apple/swift/pull/14854">pull request</a> that makes <code class="language-plaintext highlighter-rouge">SwiftSyntax</code> build on Linux.</p>
<p><a href="https://github.com/milseman">Michael Ilseman</a> worked on a <a href="https://github.com/apple/swift/pull/14755">pull request</a> that could speedup ObjC bridging 2.5 times. 😱</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0198-playground-quicklook-api-revamp.md">SE-0198</a>: <em>Playground QuickLook API Revamp</em> was <a href="https://forums.swift.org/t/se-0198-playground-quicklook-api-revamp/9448/16">accepted</a> with a minor revision.</p>
<blockquote>
<p>The new API for customizing playground display will be adopted, and the previous API deprecated, as described in the proposal. However, the new protocol will remain part of the standard library rather than moving to the playground support library, in order to facilitate frameworks that want to ship with built-in custom playground display capability.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md">SE-0199</a>: <em>Adding toggle to Bool</em> was <a href="https://forums.swift.org/t/accepted-se-199-add-toggle-to-bool/10681">accepted</a>.</p>
<blockquote>
<p>The review of SE-199 has ended, and the proposal has been accepted as-is. There was some discussion during the review of alternative names, but the team felt that <code class="language-plaintext highlighter-rouge">toggle()</code> was the best one offered.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Jordan Rose <a href="https://forums.swift.org/t/se-0192-non-exhaustive-enums/7291/337">shared</a> an update on <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a>:</p>
<blockquote>
<p>Over the last few weeks I’ve been discussing this with the core team, who pretty much all agreed that <strong>this is not the right direction for third-party libraries.</strong></p>
<p>I’m working on cutting down the proposal text (and the implementation) to match this feedback from the core team.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Did you know that <code class="language-plaintext highlighter-rouge">enum</code> was once called <a href="https://twitter.com/dgregor79/status/970857272724172800"><code class="language-plaintext highlighter-rouge">oneof</code></a> — and <a href="https://github.com/apple/swift/blob/master/CHANGELOG.md#2013-09-24"><code class="language-plaintext highlighter-rouge">union</code></a>?</p>
Issue #103
https://swiftweeklybrief.com/issue-103
2018-02-22T00:00:00-08:00
2018-02-22T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>The last two weeks have brought us some exciting progress on Swift 5 and Xcode 9.3 (which brings us Swift 4.1). Regarding Xcode, we’re now on <a href="https://download.developer.apple.com/Developer_Tools/Xcode_9.3_beta_3/Release_Notes_for_Xcode_9.3_beta_3.pdf">beta 3</a>.</p>
<p>We can also expected some news on WWDC soon - last year, Apple announced WWDC on February 16th.</p>
<p>That being said, I don’t want to distract you from all the topics discussed in the newsletter. Thanks for reading!</p>
<!--excerpt-->
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/111543">46: Restricting cross-module struct initializers</a>: Jesse and JP discuss the accepted <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md">SE-0189</a> proposal, which makes structs less source-breaking.</p>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/111551">47: Revamping QuickLook Playground APIs</a>, they discuss <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0198-playground-quicklook-api-revamp.md">SE-0198</a> which, well, revamps the Quicklook Playground APIs.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ted Kremenek <a href="https://forums.swift.org/t/swift-to-participate-in-gsoc-2018/10147">announced</a> that Swift will participate in Google Summer of Code this year!</p>
<p>With Xcode 9.3 beta 3 came a new <a href="https://twitter.com/SmileyKeith/status/966089848904810496">tool for parsing code coverage output</a>, <code class="language-plaintext highlighter-rouge">xccov</code>.</p>
<p>Erik Eckstein <a href="https://swift.org/blog/osize/">wrote</a> a blog post on the official Swift.org blog on a new code size optimization mode in Swift 4.1. If you are already testing projects in Xcode 9.3, feel free to give this a try!</p>
<p>Joe Groff <a href="http://duriansoftware.com/joe/Optimizing-global-constant-data-structures-using-relative-references.html">wrote</a> a blog post on optimizing global constant data structures.</p>
<p>Paul Hudson <a href="https://www.hackingwithswift.com/articles/55/how-to-use-dynamic-member-lookup-in-swift">gives on overview</a> of what <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md">SE-0195</a>: <em>Introduce User-defined “Dynamic Member Lookup” Types</em> brings to the table to make Swift more dynamic.</p>
<p>Keith Harrison <a href="https://useyourloaf.com/blog/replacing-flatmap-with-compactmap/">explains</a> why one of <code class="language-plaintext highlighter-rouge">flatMap</code>’s implementations is now called <code class="language-plaintext highlighter-rouge">compactMap</code>, as per <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md">SE-0187</a>: <em>Introduce <code class="language-plaintext highlighter-rouge">Sequence.compactMap(_:)</code></em>.</p>
<p>Ben Cohen <a href="https://www.dotconferences.com/2018/01/ben-cohen-extending-the-standard-library">gave a talk</a> on “Extending the Standard Library”.</p>
<p>Dave DeLong <a href="https://davedelong.com/blog/2018/02/08/swift-protocols-wishlist/">wrote</a> a blog post about how he’d want to change how Swift deals with protocols.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Xiaodi Wu <a href="https://github.com/apple/swift/pull/14502">merged</a> a pull request that improves the performance of floating-point constants after Jens Persson <a href="http://forums.swift.org/t/is-floats-nextup-really-50-times-slower-than-necessary/9716">discovered</a> performance issues for <code class="language-plaintext highlighter-rouge">Float</code>s.</p>
<p>Takeru Chuganji <a href="https://github.com/apple/swift/pull/13272">merged</a> a pull request with an improvement to Swift diagnostics, offering fix-its to insert numeric conversions when needed.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md">SE-0195</a>: <em>Introduce User-defined “Dynamic Member Lookup” Types</em> was <a href="https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/160">accepted</a>.</p>
<blockquote>
<p>On February 8 2018, the Core Team decided to accept this proposal.</p>
<p>After reviewing the feedback from the community, the Core Team felt the spelling of the attribute should remain as proposed — <code class="language-plaintext highlighter-rouge">@dynamicMemberLookup</code>. The alternative of <code class="language-plaintext highlighter-rouge">@dynamic(...)</code> was also considered, but the Core Team felt that spelling to be too close to the dynamic keyword and a potential source of confusion.</p>
<p>The rationale for the marker being an attribute instead of a protocol (as in the original proposal) was <a href="https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/159">well-articulated</a> by Chris Lattner in the review thread in that the marker protocol would not provide the expected affordances of a normal protocol.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0199-bool-toggle.md">SE-0199</a>: <em>Adding <code class="language-plaintext highlighter-rouge">toggle</code> to <code class="language-plaintext highlighter-rouge">Bool</code></em> is <a href="http://forums.swift.org/t/se-0199-adding-toggle-method-to-bool/9841">under review</a>.</p>
<blockquote>
<p>For <code class="language-plaintext highlighter-rouge">Bool</code> variables, it is common to want to toggle the state of the variable. In larger (nested) structs, the duplication involved can become especially annoying:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="n">myVar</span><span class="o">.</span><span class="n">prop1</span><span class="o">.</span><span class="n">prop2</span><span class="o">.</span><span class="n">enabled</span> <span class="o">=</span> <span class="o">!</span><span class="n">myVar</span><span class="o">.</span><span class="n">prop1</span><span class="o">.</span><span class="n">prop2</span><span class="o">.</span><span class="n">enabled</span></code></pre></figure>
<blockquote>
<p>It’s also easy to make a mistake in the code above if there are multiple <code class="language-plaintext highlighter-rouge">Bool</code> vars.
[The proposed solution is to] add a method toggle on <code class="language-plaintext highlighter-rouge">Bool</code>:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">Bool</span> <span class="p">{</span>
<span class="k">mutating</span> <span class="kd">func</span> <span class="nf">toggle</span><span class="p">()</span> <span class="p">{</span>
<span class="k">self</span> <span class="o">=</span> <span class="o">!</span><span class="k">self</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>This allows us to write the example above without duplication:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="n">myVar</span><span class="o">.</span><span class="n">prop1</span><span class="o">.</span><span class="n">prop2</span><span class="o">.</span><span class="n">enabled</span><span class="o">.</span><span class="nf">toggle</span><span class="p">()</span></code></pre></figure>
<h3 id="swift-forums">Swift Forums</h3>
<p>Max Moiseev <a href="https://forums.swift.org/t/proposal-to-improve-the-standard-library-stride-types/9675">pitched</a> a <a href="https://github.com/moiseev/swift-evolution/blob/strides/proposals/0199-strides-revamp.md">proposal</a> to improve the Standard Library’s <code class="language-plaintext highlighter-rouge">Stride</code> types.</p>
<blockquote>
<p>With the addition of conditional conformances to the language, the result of <code class="language-plaintext highlighter-rouge">zip(_:_:)</code> can now be a <code class="language-plaintext highlighter-rouge">Collection</code> <a href="https://github.com/apple/swift/pull/13941">if both containers being zipped conform to <code class="language-plaintext highlighter-rouge">Collection</code></a>.</p>
<p>Unfortunately, without <code class="language-plaintext highlighter-rouge">StrideTo</code> conforming to <code class="language-plaintext highlighter-rouge">Collection</code> as proposed, expressions such as the following do not take advantage of zip’s conditional conformance.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="nf">zip</span><span class="p">([</span><span class="mi">1</span><span class="p">,</span><span class="mi">2</span><span class="p">,</span><span class="mi">3</span><span class="p">],</span> <span class="nf">stride</span><span class="p">(</span><span class="nv">from</span><span class="p">:</span> <span class="mi">2</span><span class="p">,</span> <span class="nv">to</span><span class="p">:</span> <span class="mi">42</span><span class="p">,</span> <span class="nv">by</span><span class="p">:</span> <span class="mi">2</span><span class="p">))</span></code></pre></figure>
<blockquote>
<p>The result of this expression only conforms to <code class="language-plaintext highlighter-rouge">Sequence</code> and as such provides none of the <code class="language-plaintext highlighter-rouge">Collection</code> APIs.</p>
</blockquote>
<p>Daiki Matsudate <a href="https://forums.swift.org/t/add-compactmapvalues-to-dictionary/8741">pitched</a> a <a href="https://github.com/d-date/swift-evolution/blob/compact-map-values/proposals/0000-introduce-compact-map-values.md">proposal</a> to introduce <code class="language-plaintext highlighter-rouge">compactMapValue</code> to <code class="language-plaintext highlighter-rouge">Dictionary</code>.</p>
<blockquote>
<p>This proposal adds a combined <code class="language-plaintext highlighter-rouge">filter</code>/<code class="language-plaintext highlighter-rouge">map</code> operation to <code class="language-plaintext highlighter-rouge">Dictionary</code>, as a companion to the <code class="language-plaintext highlighter-rouge">mapValues</code> and <code class="language-plaintext highlighter-rouge">filter</code> methods introduced by <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md">SE-0165</a>. The new <code class="language-plaintext highlighter-rouge">compactMapValues</code> operation corresponds to <code class="language-plaintext highlighter-rouge">compactMap</code> on <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
<p>We sometimes need to transform and filter values of a <code class="language-plaintext highlighter-rouge">Dictionary</code> at the same time, and <code class="language-plaintext highlighter-rouge">Dictionary</code> does not currently provide an operation that directly supports this.</p>
</blockquote>
<p>Doug Gregor <a href="https://forums.swift.org/t/c-interoperability-import-struct-incomplete-as-unsafe-mutable-rawpointer-rather-than-opaquepointer/9927">pitched</a> a <a href="">proposal</a> to replace <code class="language-plaintext highlighter-rouge">OpaquePointer</code>.</p>
<blockquote>
<p>I propose to replace the <code class="language-plaintext highlighter-rouge">OpaquePointer</code> struct with a deprecated typealias for <code class="language-plaintext highlighter-rouge">UnsafeRawPointer</code>. Then, change the import of C pointers-to-incomplete-types to produce <code class="language-plaintext highlighter-rouge">UnsafeMutableRawPointer</code> or <code class="language-plaintext highlighter-rouge">UnsafeRawPointer</code>, depending on whether the pointee <code class="language-plaintext highlighter-rouge">const</code>.</p>
</blockquote>
<p>Doug also <a href="https://forums.swift.org/t/objective-c-interoperability-eliminate-nsobjectprotocol/9947">pitched</a> eliminating <code class="language-plaintext highlighter-rouge">NSObjectProtocol</code>.</p>
<blockquote>
<p>I propose to completely eliminate the <code class="language-plaintext highlighter-rouge">NSObject</code> protocol (called <code class="language-plaintext highlighter-rouge">NSObjectProtocol</code>) from Swift, leaving only a deprecated typealias (to <code class="language-plaintext highlighter-rouge">AnyObject</code>) as a backward-compatibility shim.</p>
</blockquote>
<p>Dave DeLong <a href="https://forums.swift.org/t/supplement-file-line-and-function-with-context/9505">pitched</a> a proposal to add a <code class="language-plaintext highlighter-rouge">#context</code> keyword.</p>
<blockquote>
<p>This would make it <em>much</em> easier to capture the context in which some code is executed rather than having to put <code class="language-plaintext highlighter-rouge">file: StaticString = #file, line: UInt = #line</code> parameters everywhere. A <code class="language-plaintext highlighter-rouge">context: Context = #context</code> would be much easier.</p>
</blockquote>
<p>Letanyan Arumugam <a href="https://forums.swift.org/t/shorthand-for-offsetting-startindex-and-endindex/9397">pitched</a> a <a href="https://github.com/Letanyan/swift-evolution/blob/offsetting-range-subscript/proposals/NNNN-offsetting-subscript.md">proposal</a> to introduce a shorthand for offsetting <code class="language-plaintext highlighter-rouge">startIndex</code> and <code class="language-plaintext highlighter-rouge">endIndex</code> in subscripts.</p>
<blockquote>
<p>Using collection indexes are a bit of a bother when you want to do simple slicing and a type is not indexed by <code class="language-plaintext highlighter-rouge">Int</code>.</p>
<p>For a simple example take the code here:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">s</span> <span class="o">=</span> <span class="s">"Hello, Swift"</span>
<span class="k">let</span> <span class="nv">m</span> <span class="o">=</span> <span class="n">s</span><span class="p">[</span><span class="o">...</span><span class="n">s</span><span class="o">.</span><span class="nf">index</span><span class="p">(</span><span class="n">s</span><span class="o">.</span><span class="n">startIndex</span><span class="p">,</span> <span class="nv">offsetBy</span><span class="p">:</span> <span class="mi">4</span><span class="p">)]</span></code></pre></figure>
<blockquote>
<p>The intent of advancing <code class="language-plaintext highlighter-rouge">startIndex</code> gets a bit muddled.</p>
<p>So to ease this I think we could add <code class="language-plaintext highlighter-rouge">startIndex(offsetBy:)</code> and <code class="language-plaintext highlighter-rouge">endIndex(offsetBy:)</code> to <code class="language-plaintext highlighter-rouge">Collection</code>.</p>
<p>Making the example above:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">s</span> <span class="o">=</span> <span class="s">"Hello, Swift"</span>
<span class="k">let</span> <span class="nv">m</span> <span class="o">=</span> <span class="n">s</span><span class="p">[</span><span class="o">...</span><span class="n">s</span><span class="o">.</span><span class="nf">startIndex</span><span class="p">(</span><span class="nv">offsetBy</span><span class="p">:</span> <span class="mi">4</span><span class="p">)]</span></code></pre></figure>
<p>@tanner0101 <a href="https://forums.swift.org/t/spm-static-dependencies/10152">pitched</a> a <a href="https://github.com/tanner0101/swift-evolution/blob/spm-static-deps/proposals/NNNN-spm-static-deps.md">proposal</a> that adds support for static dependencies in the Swift Package Manager.</p>
<blockquote>
<p>This proposal introduces the ability to rely on a dependency statically (meaning that it will be available for import in your <code class="language-plaintext highlighter-rouge">Package.swift</code> file). The idea is that this will greatly increase the usability and customization of the <code class="language-plaintext highlighter-rouge">Package.swift</code> file.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>The API does not work as expected? Can’t be. Its unit tested and all. Did you <a href="https://mobile.twitter.com/AirspeedSwift/status/962754808733036544">read its documentation</a>?</p>
Issue #102
https://swiftweeklybrief.com/issue-102
2018-02-08T00:00:00-08:00
2018-02-08T00:00:00-08:00
Tapan Thaker
https://twitter.com/tapthaker
https://github.com/tapthaker.png?size=100
tapthaker
<p>Welcome to issue #102!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-6852">SR-6852</a> [Compiler] Add support for checking <code class="language-plaintext highlighter-rouge">#if swift(<4.1)</code></li>
<li><a href="https://bugs.swift.org/browse/SR-6808">SR-6808</a> [llbuild] Visualizing Build Graph is not exposed from llbuild Build System</li>
<li><a href="https://bugs.swift.org/browse/SR-6787">SR-6787</a> [Stdlib] Unexpected result when getting a String describing a type created inside a function</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<ul>
<li><a href="https://spec.fm/podcasts/swift-unwrapped/108765">44: Swift Bi-Weekly Brief</a>: <a href="https://twitter.com/jesse_squires">Jesse</a> and <a href="https://twitter.com/simjp">JP</a> discuss the future of this newsletter.</li>
<li><a href="https://spec.fm/podcasts/swift-unwrapped/108885">45: Swift News January 2018</a>: They discuss Swift news for January 2018 including starter tasks, Xcode 9.3 beta 1, and commits to Swift source.</li>
</ul>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/gregheo">Greg Heo</a> wrote an amazing post about <a href="https://swiftunboxed.com/lang/conditional-conformance/">Conditional conformance</a>. In it, he thinks through conditional conformance in Swift, and works through the basics of its implementation.</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> published a new article: <a href="https://modocache.io/the-swift-frontend-lexing-and-parsing">Getting Started with the Swift Frontend: Lexing & Parsing</a> in his ongoing series <a href="http://modocache.io/getting-started-with-swift-development">Getting Started with Swift Compiler Development</a>.</p>
<p><a href="https://github.com/nkcsgexi">Xi Ge</a>’s talk about <a href="https://www.skilled.io/u/swiftsummit/creating-refactoring-transformations-for-swift">Creating Refactoring Transformations for Swift</a> from the <a href="https://www.swiftsummit.com/">Swift Summit 2017</a> is posted. He also talks about future of refactoring engine with <a href="https://github.com/apple/swift/blob/master/lib/Syntax/README.md">libSyntax</a>.</p>
<p><a href="http://www.fewbutripe.com/about/">Brandon Williams</a> and <a href="http://www.stephencelis.com/">Stephen Celis</a> launched a new Swift video series called <a href="https://www.pointfree.co/">Point-Free</a>. Checkout their first episode, <a href="https://www.pointfree.co/episodes/ep1-functions">Functions</a>.</p>
<blockquote>
<p>Point-Free is a video series about functional programming and the Swift programming language. Each episode covers a topic that may seem complex and academic at first, but turns out to be quite simple. At the end of each episode we’ll ask “what’s the point?!”, so that we can bring the concepts back down to earth and show how these ideas can improve the quality of your code today.</p>
</blockquote>
<p>Brandon’s talk <a href="https://www.skilled.io/u/swiftsummit/server-side-swift-from-scratch">Server-Side Swift from Scratch</a> also discusses some of the functional programming work they have done with Point-Free.</p>
<p><a href="https://twitter.com/steipete">Peter Steinberger</a> wrote about <a href="https://pspdfkit.com/blog/2018/binary-frameworks-swift/">Binary Frameworks in Swift</a></p>
<blockquote>
<p>This article explores what Application Binary Interface means and how it can be important for third-party frameworks.</p>
<p>TL;WR: ABI stability won’t change much for you, and it’s not enough to ship binary Swift frameworks.</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> <a href="https://github.com/apple/swift/pull/14368">merged</a> a pull request that will allow querying of conditional conformances at runtime. This was the last major part of implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md">SE-0143</a> <em>Conditional conformances</em> which is now complete. 🎉</p>
<blockquote>
<p>Runtime query of conditional conformances is now implemented. Therefore, a dynamic cast such as value as? P, where the dynamic type of value conditional conforms to P, will succeed when the conditional requirements are met.</p>
</blockquote>
<p>He also <a href="https://github.com/apple/swift/pull/14174">fixed</a> an <a href="https://bugs.swift.org/browse/SR-6841">issue</a> in type checker where class constraints <code class="language-plaintext highlighter-rouge">(spelled T: AnyObject)</code> on generic types were not getting checked on generic arguments.</p>
<p><a href="https://github.com/airspeedswift">Ben Cohen</a> <a href="https://github.com/apple/swift/pull/13342">merged</a> a pull request that has some more excellent uses of conditional conformances in the Swift standard library. Say goodbye to <code class="language-plaintext highlighter-rouge">(Closed)CountableRange</code>. 👋</p>
<p><a href="https://github.com/gregomni">Greg Titus</a> <a href="https://github.com/apple/swift/pull/14227">merged</a> a pull request that removes compiler terminology l-value. As <a href="https://twitter.com/slava_pestov/status/957720067822706688">mentioned by Slava Pestov</a>:</p>
<blockquote>
<p>“Removing terminology” is almost always good. Compilers often use terminology that is internal to the implementation, not part of the language model, and can change.</p>
</blockquote>
<p><a href="https://github.com/nathawes">Nathan Hawes</a> created a <a href="https://github.com/apple/swift/pull/14353">pull request</a> to fix a crash in <code class="language-plaintext highlighter-rouge">onDocumentUpdateNotification</code>. This was one of the top SourceKit crashes.</p>
<p><a href="https://github.com/mortenbekditlevsen">Morten Bek Ditlevsen</a> added Conditional conformances to <code class="language-plaintext highlighter-rouge">Hashable</code> for the following types:</p>
<ul>
<li><a href="https://github.com/apple/swift/commit/618df4aeac766fcb8069e90a44b867969a1bc47d"><code class="language-plaintext highlighter-rouge">CollectionOfOne</code>, <code class="language-plaintext highlighter-rouge">EmptyCollection</code> and <code class="language-plaintext highlighter-rouge">Range</code></a>.</li>
<li><a href="https://github.com/apple/swift/pull/14247"><code class="language-plaintext highlighter-rouge">Optional</code>, <code class="language-plaintext highlighter-rouge">Dictionary</code> and <code class="language-plaintext highlighter-rouge">Array</code></a>.</li>
</ul>
<p><a href="https://github.com/eeckstein">Eric Eckstein</a> <a href="https://github.com/apple/swift/pull/14338">fixed</a> two issues which prevented incremental LLVM compilation.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0196-diagnostic-directives.md">SE-0196</a>: <em>Compiler Diagnostic Directives</em> <a href="https://forums.swift.org/t/se-0196-compiler-diagnostic-directives/8734/47">was accepted</a> with a minor revision.</p>
<blockquote>
<p>The only revision over the original proposal is to change the syntax to use <code class="language-plaintext highlighter-rouge">#warning(<Message>)</code> instead of <code class="language-plaintext highlighter-rouge">#warning <Messsage></code>. This fits well with most of Swift’s existing compiler directives, and was strongly supported in the review discussion.</p>
<p>The review discussion also covered a variety of possible extensions or variants to this proposal, including support for using <code class="language-plaintext highlighter-rouge">#warning</code> as an expression instead of a line directive and support for runtime issues. The Core Team decided that while these directions are interesting and worth exploring, they are complementary to the core functionality serviced by this proposal. Further, keeping <code class="language-plaintext highlighter-rouge">#warning</code> as a line directive allows it to be used in a wide variety of contexts, and serves a different need than using it as a placeholder expression.</p>
</blockquote>
<p>The proposal was also implemented and <a href="https://github.com/apple/swift/pull/14048">merged</a> by <a href="https://github.com/harlanhaskins">Harlan Haskins</a>.</p>
<p><a href="https://forums.swift.org/t/se-0197-add-in-place-remove-where/8872">SE-0197</a>: <em>Adding in-place <code class="language-plaintext highlighter-rouge">remove(where:)</code> to the Standard Library</em> <a href="https://forums.swift.org/t/se-0197-add-in-place-remove-where/8872">was reviewed</a> and <a href="https://forums.swift.org/t/accepted-with-revision-se-0197-add-in-place-remove-where/9459">accepted</a>.</p>
<blockquote>
<p>The discussion of SE-0197 made it clear that there is consensus in the community to add the feature. However, several people expressed concern about using the base name remove, since it’s ambiguous about how many matching elements will be removed. There seemed to be broad agreement that <code class="language-plaintext highlighter-rouge">removeAll</code> would be a better name, with no objections raised during the review. Accordingly, the core team has decided to accept the proposal with the revision that the method be named <code class="language-plaintext highlighter-rouge">removeAll(where:)</code>.</p>
<p>We expect this feature to be available in Swift 5.</p>
<p>As always, thank you for helping to make Swift a better language.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md">SE-0195</a>: <em>Introduce User-defined “Dynamic Member Lookup” Types</em> is still under review. It’s review <a href="https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658/126">was extended</a> by another week.</p>
<blockquote>
<p>The proposal is accepted in principle, but specific details of the proposal need to be further discussed and ironed out. Specifically, there is the matter of using a marker protocol, which raises a bunch of technical questions.</p>
<p>On the general principle of the proposal, the Core Team felt that:</p>
<ul>
<li>This proposal added valuable functionality to Swift</li>
<li>This proposal is not at odds at potentially adding any new dynamic affordances to Swift later that (say) tie into Swift’s runtime metadata, etc.</li>
<li>There are tooling affordances, such as syntax coloring, that can be used to distinguish methods call going through this member lookup mechanism — without adding additional syntactic weight that would be at odds of some of the core goals of this proposal.</li>
</ul>
<p>[…]</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0198-playground-quicklook-api-revamp.md">SE-0198</a>: <em>Playground QuickLook API Revamp</em> is <a href="https://forums.swift.org/t/se-0198-playground-quicklook-api-revamp/9448">under review</a>.</p>
<blockquote>
<p>The standard library currently includes API which allows a type to customize its
description in Xcode playgrounds and Swift Playgrounds. This API takes the
form of the <code class="language-plaintext highlighter-rouge">PlaygroundQuickLook</code> enum which enumerates types which are
supported for quick looks, and the <code class="language-plaintext highlighter-rouge">CustomPlaygroundQuickLookable</code> protocol
which allows a type to return a custom <code class="language-plaintext highlighter-rouge">PlaygroundQuickLook</code> value for an
instance.</p>
<p>This is brittle, and to avoid dependency inversions, many of the cases are typed
as taking <code class="language-plaintext highlighter-rouge">Any</code> instead of a more appropriate type. This proposal suggests that
we deprecate <code class="language-plaintext highlighter-rouge">PlaygroundQuickLook</code> and <code class="language-plaintext highlighter-rouge">CustomPlaygroundQuickLookable</code> in Swift
4.1 so they can be removed entirely in Swift 5, preventing them from being
included in the standard library’s stable ABI.</p>
<p>[…]</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>There were a few discussions around Strings this week:</p>
<ul>
<li><a href="https://github.com/beccadax">Becca Royal-Gordon</a> started a discussion on a <a href="https://forums.swift.org/t/string-interpolation-revamp/9302">String interpolation revamp</a> and is looking for some ideas to generate fewer temporary strings. Currenly in Swift interpolation, when you write code like this in Swift 4:</li>
</ul>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">foo</span><span class="p">:</span> <span class="kt">MyString</span> <span class="o">=</span> <span class="s">"foo </span><span class="se">\(</span><span class="n">bar</span><span class="se">)</span><span class="s"> baz"</span></code></pre></figure>
<p>We currently generate code like below which means we create reference-counted heap objects which are purely temporary and are discarded as soon as the string interpolation is finished.</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">foo</span> <span class="o">=</span> <span class="kt">MyString</span><span class="p">(</span><span class="nv">stringInterpolation</span><span class="p">:</span>
<span class="kt">MyString</span><span class="p">(</span><span class="nv">stringInterpolationSegment</span><span class="p">:</span> <span class="s">"foo "</span> <span class="k">as</span> <span class="kt">String</span><span class="p">),</span>
<span class="kt">MyString</span><span class="p">(</span><span class="nv">stringInterpolationSegment</span><span class="p">:</span> <span class="n">bar</span><span class="p">),</span>
<span class="kt">MyString</span><span class="p">(</span><span class="nv">stringInterpolationSegment</span><span class="p">:</span> <span class="s">" baz"</span> <span class="k">as</span> <span class="kt">String</span><span class="p">)</span>
<span class="p">)</span></code></pre></figure>
<ul>
<li><a href="https://github.com/anandabits">Matthew Johnson</a> started a discussion on <a href="https://forums.swift.org/t/generalized-pattern-matching/9191">Generalized pattern matching</a>.</li>
</ul>
<p><a href="https://github.com/airspeedswift">Ben Cohen</a> started a discussion for <a href="https://forums.swift.org/t/revisiting-the-choice-of-sort-algorithm/8958">Revisiting the choice of sort algorithm</a> in the std lib:</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">Swift.sort</code> is currently an <a href="https://en.wikipedia.org/wiki/Introsort">introsort</a>. Introsort is unstable, and there’s been <a href="https://forums.swift.org/t/add-stable-sort-algorithm/778">discussion</a> over on evolution of adding a stable sort, either instead of or as well as the current sort.</p>
<p>The current sort is problematic because it uses recursion heavily, which defeats a number of optimizations relating to ARC and elimination of the overhead of passing in a closure for the comparative for the comparator. This is why we use <code class="language-plaintext highlighter-rouge">gyb</code> to stamp out two near identical versions rather than implementing the <code class="language-plaintext highlighter-rouge">Equatable</code> version in terms of the closure-taking one.</p>
<p>[…]</p>
</blockquote>
<p><a href="https://github.com/jrose-apple">Jordan Rose</a> started a discussion for <a href="https://forums.swift.org/t/exported-and-fixing-import-visibility/9415"><code class="language-plaintext highlighter-rouge">@_exported</code> and fixing import visibility</a>:</p>
<blockquote>
<p>Today, if your Swift library “Foo” uses a library “Bar”, the headers (or swiftmodule files) of “Bar” must be available to all clients of “Foo”. This is clearly undesirable, especially when “Bar” is just an implementation detail. (It may even be linked statically.)</p>
<p>[…]</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Let’s look at the <a href="https://twitter.com/jckarter/status/959091909129113602">changelog</a> for Swift 5. 😃🤣</p>
Issue #101
https://swiftweeklybrief.com/issue-101
2018-01-25T00:00:00-08:00
2018-01-25T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Hi! 👋</p>
<p><a href="https://basthomas.github.io/curating-swift-weekly">We’re back</a>. After a short hiatus, we are continuing Swift Weekly Brief every other week. 🎉
As Jesse <a href="https://www.jessesquires.com/blog/swift-weekly-brief-hiatus/">mentioned</a>, he will be taking a break from writing the newsletter. I will be taking over the curation of the newsletter for now, with the help of some awesome <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/graphs/contributors">contributors</a> and <a href="https://swiftweeklybrief.com/authors/">writers</a>.</p>
<p>There is more great news: the <a href="https://forums.swift.org/t/welcome-to-the-swift-forums/8">Swift Forums</a> are now live! They offer a more visual, searchable and navigatable way of browsing through the previous mailing lists. This will hopefully make the barrier for chiming in on everything Swift.org lower. Go <a href="https://forums.swift.org">have a look</a> - and a huge congratulations to the team at Apple for realising this.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ol>
<li><a href="https://bugs.swift.org/browse/SR-6706">SR-6706</a>: Swift should complain about weak references to classes that don’t support them</li>
<li><a href="https://bugs.swift.org/browse/SR-6691">SR-6691</a>: <code class="language-plaintext highlighter-rouge">Sequence.split</code> should have a <code class="language-plaintext highlighter-rouge">Lazy</code> equivalent</li>
<li><a href="https://bugs.swift.org/browse/SR-6736">SR-6736</a>: Enforce 16-bit limit for number of function parameters, number of tuple type element</li>
</ol>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>While we’ve been away, Jesse and JP have discussed <a href="https://spec.fm/podcasts/swift-unwrapped/100849">Improving Compilation Performance</a>, <a href="https://spec.fm/podcasts/swift-unwrapped/105029">Conditional Conformance</a> (read more in the blog post <a href="https://swift.org/blog/conditional-conformance/">here</a>), and the <a href="https://spec.fm/podcasts/swift-unwrapped/105667">State of String</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple <a href="https://download.developer.apple.com/Developer_Tools/Xcode_9.3_beta/Release_Notes_for_Xcode_9.3_beta.pdf">released</a> the first Xcode 9.3 beta, which will ship with Swift 4.1.</p>
<p>Apple <a href="https://developer.apple.com/news/?id=01242018a">released</a> Swift Playgrounds 2, which lets you subscribe to <a href="https://developer.apple.com/swift-playgrounds/subscriptions/#gallery">third-party creators</a> to browse and download their content directly within the app.</p>
<p>Ben Cohen wrote <a href="https://swift.org/blog/conditional-conformance/">about Conditional Conformance</a>, which is getting us closer to ABI stability, Swift 5’s major goal. (<a href="https://twitter.com/AirspeedSwift/status/950446966126751744">tweet</a>)</p>
<p>Joe Groff’s talk at Swift Summit, <em>Swift’s Reflective Underpinnings</em>, <a href="https://www.skilled.io/u/swiftsummit/swift-s-reflective-underpinnings-joe-groff">has been posted</a> and includes a transcript of the post as well.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Greg Titus <a href="https://github.com/apple/swift/pull/14041">merged</a> a pull request that allows you to <code class="language-plaintext highlighter-rouge">fallthrough</code> switch cases <a href="https://twitter.com/jckarter/status/955644985306619905">with the same variable bindings</a>.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/14102">merged</a> a pull request to prevent invalid inputs that could <a href="https://bugs.swift.org/browse/SR-6797">cause a compiler crash</a>.</p>
<p>Pavel Yaskevich <a href="https://github.com/apple/swift/pull/13986">opened</a> a pull request that could speed up the type checking of complex expressions.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/13573">merged</a> a pull request that enables API resilience in the Standard Library. He’s been working on it for <a href="https://twitter.com/slava_pestov/status/953897806040674304">two and a half years</a> (!). It was one of the <a href="https://github.com/apple/swift-evolution#primary-focus-abi-stability">three</a> main goals to achieve ABI stability.</p>
<p>Chris Lattner <a href="https://github.com/apple/swift/pull/14076">merged</a> a pull request that improves <code class="language-plaintext highlighter-rouge">print</code> performance - after reading a <a href="https://oleb.net/blog/2016/09/playground-print-hook/">blog post</a> by Ole Begemann from September 2016. 😱</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a>: <em>Frozen and Non-frozen Enums</em> was <a href="https://forums.swift.org/t/review-se-0192-non-exhaustive-enums/7291">reviewed</a> and will <a href="https://forums.swift.org/t/review-returned-for-revision-se-0192-non-exhaustive-enums/7423">return for revision</a>.</p>
<blockquote>
<p>The review of “SE 0192 - Non-Exhaustive Enums” had extensive discussion and has been returned for revision.</p>
<p>The proposal author, Jordan Rose, is working on a revised proposal that includes:</p>
<ul>
<li>Alterations to the naming of the attributes.</li>
<li>New affordances for how <code class="language-plaintext highlighter-rouge">switch</code> statements work with non-exhaustive enums.</li>
</ul>
<p>There will be a second round of review, but there is active discussion considering the latter point right now on swift-evolution on the thread <a href="https://forums.swift.org/t/handling-unknown-cases-in-enums-re-se-0192/7388">“Handling unknown cases in enums”</a>.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0194-derived-collection-of-enum-cases.md">SE-0194</a>: <em>Derived Collection of Enum Cases</em> is <a href="https://forums.swift.org/t/review-se-0194-derived-collection-of-enum-cases/7377">under review</a>.</p>
<blockquote>
<p>We propose the introduction of a protocol, <code class="language-plaintext highlighter-rouge">ValueEnumerable</code>, to indicate that a type has a finite, enumerable set of values. Moreover, we propose an opt-in derived implementation of <code class="language-plaintext highlighter-rouge">ValueEnumerable</code> for the common case of a simple enum.
The compiler will derive an implementation automatically for simple enums when the conformance is specified.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift">
<span class="kd">enum</span> <span class="kt">Ma</span><span class="p">:</span> <span class="kt">ValueEnumerable</span> <span class="p">{</span> <span class="k">case</span> <span class="n">马</span><span class="p">,</span> <span class="n">吗</span><span class="p">,</span> <span class="n">妈</span><span class="p">,</span> <span class="n">码</span><span class="p">,</span> <span class="n">骂</span><span class="p">,</span> <span class="n">麻</span><span class="p">,</span> <span class="n">🐎</span><span class="p">,</span> <span class="n">🐴</span> <span class="p">}</span>
<span class="kt">Ma</span><span class="o">.</span><span class="n">allValues</span> <span class="c1">// returns some Collection whose Iterator.Element is Ma</span>
<span class="kt">Ma</span><span class="o">.</span><span class="n">allValues</span><span class="o">.</span><span class="n">count</span> <span class="c1">// returns 8</span>
<span class="kt">Array</span><span class="p">(</span><span class="kt">Ma</span><span class="o">.</span><span class="n">allValues</span><span class="p">)</span> <span class="c1">// returns [Ma.马, .吗, .妈, .码, .骂, .麻, .🐎, .🐴]</span></code></pre></figure>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0195-dynamic-member-lookup.md">SE-0195</a>: <em>Introduce User-defined “Dynamic Member Lookup” Types</em> is <a href="https://forums.swift.org/t/se-0195-introduce-user-defined-dynamic-member-lookup-types/8658">under review</a>.</p>
<blockquote>
<p>This proposal introduces a new <code class="language-plaintext highlighter-rouge">DynamicMemberLookupProtocol</code> type to the standard library. Types that conform to it provide “dot” syntax for arbitrary names which are resolved at runtime - in a <strong>completely type safe</strong> way. It is simple syntactic sugar which has a non-invasive implementation in the compiler.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0196-diagnostic-directives.md">SE-0196</a>: <em>Compiler Diagnostic Directives</em> is <a href="https://forums.swift.org/t/se-0196-compiler-diagnostic-directives/8734">under review</a>.</p>
<blockquote>
<p>This proposal introduces <code class="language-plaintext highlighter-rouge">#warning</code> and <code class="language-plaintext highlighter-rouge">#error</code> directives that will cause the Swift compiler to emit a custom warning or an error during compilation.</p>
</blockquote>
<h3 id="swift-forums">Swift Forums</h3>
<p>Michael Ilseman gave <a href="https://forums.swift.org/t/state-of-string-abi-performance-ergonomics-and-you/7397">an update</a> on the State of String in regard to the ABI, performance, ergonomics and more.</p>
<blockquote>
<p>I’ve been working on implementing, optimizing, and improving String in preparation for ABI stability, and I thought I’d share the current status of String in Swift 5 and some potential directions to go. This is the product of conversations with open source contributors and my colleagues on the Swift standard library team at Apple.</p>
</blockquote>
<p>Chris Eidhof pitched adding a function to <a href="https://forums.swift.org/t/pitch-adding-toggle-to-bool/7414">toggle a Bool</a>:</p>
<blockquote>
<p>For <code class="language-plaintext highlighter-rouge">Bool</code> variables, it is common to want to toggle the state of the variable. In larger (nested) structs, the duplication involved can become especially annoying:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift">
<span class="n">myVar</span><span class="o">.</span><span class="n">prop1</span><span class="o">.</span><span class="n">prop2</span><span class="o">.</span><span class="n">enabled</span> <span class="o">=</span> <span class="o">!</span><span class="n">myVar</span><span class="o">.</span><span class="n">prop1</span><span class="o">.</span><span class="n">prop2</span><span class="o">.</span><span class="n">enabled</span></code></pre></figure>
<blockquote>
<p>It’s also easy to make a mistake in the code above if there are multiple <code class="language-plaintext highlighter-rouge">Bool</code> vars.
[The proposed solution is to] add a method toggle on <code class="language-plaintext highlighter-rouge">Bool</code>:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift">
<span class="kd">extension</span> <span class="kt">Bool</span> <span class="p">{</span>
<span class="k">mutating</span> <span class="kd">func</span> <span class="nf">toggle</span><span class="p">()</span> <span class="p">{</span>
<span class="k">self</span> <span class="o">=</span> <span class="o">!</span><span class="k">self</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>This allows us to write the example above without duplication:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift">
<span class="n">myVar</span><span class="o">.</span><span class="n">prop1</span><span class="o">.</span><span class="n">prop2</span><span class="o">.</span><span class="n">enabled</span><span class="o">.</span><span class="nf">toggle</span><span class="p">()</span></code></pre></figure>
<h3 id="finally">Finally</h3>
<p>And finally… the <a href="https://twitter.com/jckarter/status/955931838320492544">Access Control debate</a> continues.</p>
Issue #100
https://swiftweeklybrief.com/issue-100
2018-01-04T00:00:00-08:00
2018-01-04T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p><strong>Welcome to issue #100!</strong> 🎉As you’ve probably heard by now, this will be <a href="https://www.jessesquires.com/blog/swift-weekly-brief-hiatus/"><strong>the final issue</strong></a> of the newsletter. I encourage you to read <a href="https://www.jessesquires.com/blog/swift-weekly-brief-hiatus/">my entire blog post</a> announcement, but here’s the TL;DR: <em>it’s time for me to focus on other projects and priorities, and if possible, transition the newsletter to a new owner.</em> Luckily, the project is extremely healthy and could easily be taken over by an eager and motivated member of the community. If you are interested, please get in touch!</p>
<p>This newsletter started out as an accident. It <a href="https://www.jessesquires.com/blog/swift-open-source/">began on my personal blog</a> before I decided to <a href="https://www.jessesquires.com/blog/new-weekly-brief/">create this site</a> and start the mailing list. Two years later, here we are. It’s been a pleasure to deliver an issue to your inbox each week. The good news is that I’ll still be bringing you Swift news regularly — in <a href="https://spec.fm/podcasts/swift-unwrapped">podcast form</a> with the one and only <a href="https://twitter.com/simjp">JP Simard</a>. If you haven’t subscribed, <a href="https://itunes.apple.com/us/podcast/swift-unwrapped/id1209817203">you should do it now</a>. 😄 I’ll also continue to write about Swift on my blog. Of course, there are many other fantastic blogs to follow in the Swift community, which I’ve linked to often — so there will be no shortage of content for sure! My hope is that the new <a href="https://forums.swift.org/t/discourse-rollout-re-schedule/7258">Swift forums</a>, which should be rolled out soon, will help make following Swift evolution and other Swift.org news easier without this newsletter.</p>
<p>Alright — let’s get on with our last issue!</p>
<!--excerpt-->
<h3 id="news-and-community">News and community</h3>
<p>Daniel Duan <a href="https://duan.ca/2017/12/23/contributing-to-open-source-foundation/">made a YouTube video</a> tutorial on how to contribute to open source Swift. In the video he discovers, reports, fixes, and merges a bug in corelibs-foundation. 🤓 📺</p>
<p>Ole Begemann wrote two posts, <a href="https://oleb.net/blog/2017/12/fixed-size-arrays/">A hack for fixed-size arrays</a> and a <a href="https://oleb.net/blog/2017/12/swift-imports-fixed-size-c-arrays-as-tuples/">follow-up post</a> on how Swift imports C arrays as tuples. They provide an interesting look at what it currently takes to create a fixed-size array in Swift — and the cost of doing it.</p>
<p>objc.io wrote a post on implementing <a href="https://www.objc.io/blog/2017/12/28/weak-arrays/">weak arrays</a> in Swift. It’s an interesting idea, and they apply this in one of their Swift Talk episodes.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/13657">merged</a> improves to the type checker for 4.1 to make redeclaration checking validate fewer declarations. This fixes <a href="https://bugs.swift.org/browse/SR-6558">SR-6558</a>.</p>
<p>Gregory Williams <a href="https://github.com/apple/swift/pull/13676">fixed</a> a crash in <code class="language-plaintext highlighter-rouge">CharacterSet</code>, resolving <a href="https://bugs.swift.org/browse/SR-2988">SR-2988</a>.</p>
<p>Chris Lattner <a href="https://github.com/apple/swift/pull/13665">merged</a> changes to reduce Swift array literal abstraction penalties, that is, to make the SIL optimizer able to eliminate bridging overhead when dealing with array literals from Objective-C. In the test example, this results in 4x less SIL code.</p>
<p>Slava Pestov continued his work on class resilience with <a href="https://github.com/apple/swift/pull/13687">part 10</a>, <a href="https://github.com/apple/swift/pull/13689">part 11</a>, and <a href="https://github.com/apple/swift/pull/13718">part 12</a>.</p>
<p>Roman Roibu <a href="https://github.com/apple/swift/pull/12554">merged</a> a new IDE refactoring, expand a ternary operator into an if statement and vice-versa.</p>
<p>David Zarzycki <a href="https://twitter.com/slava_pestov/status/946197170658541568">warmed Slava’s heart</a> 😄 by <a href="https://github.com/apple/swift/pull/13628">cleaning up</a> some technical debt in SIL.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week, likely because of the holidays. Check <a href="https://apple.github.io/swift-evolution/">the status page</a> for updates!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Discussion on the swift-evolution list this week continued to center around <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a>: <em>Non-Exhaustive Enums</em>. Jordan Rose will be incorporating feedback into a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20180101/042480.html">revision of the proposal</a>:</p>
<blockquote>
<p>Whew! Thanks for your feedback, everyone. On the lighter side of feedback—naming things—it seems that most people seem to like <code class="language-plaintext highlighter-rouge">@frozen</code>, and that does in fact have the connotations we want it to have. I like it too.</p>
<p>More seriously, this discussion has convinced me that it’s worth including what the proposal discusses as a ‘future’ case. The key point that swayed me is that this can produce a warning when the switch is missing a case rather than an error, which both provides the necessary compiler feedback to update your code and allows your dependencies to continue compiling when you update to a newer SDK. I know people on both sides won’t be 100% satisfied with this, but does it seem like a reasonable compromise?</p>
<p>The next question is how to spell it. I’m leaning towards <code class="language-plaintext highlighter-rouge">unexpected case:</code>, which (a) is backwards-compatible, and (b) also handles “private cases”, either the fake kind that you can do in C (as described in the proposal), or some real feature we might add to Swift some day. <code class="language-plaintext highlighter-rouge">unknown case:</code> isn’t bad either.</p>
<p>I too would like to just do <code class="language-plaintext highlighter-rouge">unknown:</code> or <code class="language-plaintext highlighter-rouge">unexpected:</code> but that’s technically a source-breaking change:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">switch</span> <span class="n">foo</span> <span class="p">{</span>
<span class="k">case</span> <span class="nv">bar</span><span class="p">:</span>
<span class="nv">unknown</span><span class="p">:</span>
<span class="k">while</span> <span class="nf">baz</span><span class="p">()</span> <span class="p">{</span>
<span class="k">while</span> <span class="nf">garply</span><span class="p">()</span> <span class="p">{</span>
<span class="k">if</span> <span class="nf">quux</span><span class="p">()</span> <span class="p">{</span>
<span class="k">break</span> <span class="n">unknown</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Another downside of the <code class="language-plaintext highlighter-rouge">unexpected case:</code> spelling is that it doesn’t work as part of a larger pattern. I don’t have a good answer for that one, but perhaps it’s acceptable for now.</p>
<p>I’ll write up a revision of the proposal soon and make sure the core team gets my recommendation when they discuss the results of the review.</p>
<p>I’ll respond to a few of the more intricate discussions tomorrow, including the syntax of putting a new declaration inside the enum rather than outside. Thank you again, everyone, and happy new year!</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — thank you for reading. I cannot say ‘thank you’ enough. Thanks for reading these issues over the past two years. Thanks to all of the fantastic sponsors that helped motivate and incentivize me to keep writing. And thanks to <a href="https://swiftweeklybrief.com/authors/">the other great writers</a> who wrote issues so that I could take much-needed breaks: <a href="https://twitter.com/modocache">Brian Gesiak</a>, <a href="https://twitter.com/simjp">JP Simard</a>, <a href="https://twitter.com/BasThomas">Bas Broek</a>, <a href="https://twitter.com/gregheo">Greg Heo</a>, <a href="https://twitter.com/benasher44">Ben Asher</a>, <a href="https://twitter.com/garricn">Garric Nahapetian</a>, and <a href="https://twitter.com/volkovre">Roman Volkov</a>.</p>
<p>This is the final “finally”, at least for awhile. Until next time. <br />—jsq</p>
Issue #99
https://swiftweeklybrief.com/issue-99
2017-12-21T00:00:00-08:00
2017-12-21T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #99! 🎈 <a href="https://swiftweeklybrief.com/issue-98/">Last week we discussed</a> the move away from the mailing lists to official Swift forums, which were intended to be fully rolled out by now. Unfortunately, the rollout has been delayed until early next year due to feedback from users and the holiday season. Almost there! In other news, two exciting proposals were introduced this week that have significant implications for library authors, the Swift ABI, and potential performance improvements. Swift 5 is starting to look like a very exciting release!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped">Episode 40: Dynamic Member Lookup Proposal</a>. JP and Jesse discuss Chris Lattner’s recent “Dynamic Member Lookup” proposal.</p>
<h3 id="news-and-community">News and community</h3>
<p>The new Discourse-based <a href="https://forums.swift.org">Swift forums are online</a>, but not 100% functional yet. The full rollout has been rescheduled for early next year. However, you can sign-up with GitHub and start testing out the prototype to give feedback to the team! <a href="https://forums.swift.org/t/discourse-rollout-re-schedule/7258">Nicole Jacque writes</a>:</p>
<blockquote>
<p>First of all, a big thank you to everyone who has provided feedback on our prototype Discourse forum. Based on the fact that we’re still receiving feedback, we’d like to move to a slightly less aggressive schedule for our rollout, in order to make sure that we’ve adequately addressed it. We’re still working out an exact schedule, but due to the upcoming holidays, I expect that we’ll be looking at shortly after the beginning of the new year.</p>
<p>In the meantime, I’ve moved the prototype forum to <a href="https://forums.swift.org">forums.swift.org</a>, and I have GitHub-enabled logins working if you’d like to give it a try! You can also test out registering (including using the staged account pre-created from your mailing list account). Instructions are <a href="https://forums.swift.org/t/taking-over-a-pre-created-staged-account/712116">here</a>.</p>
<p>Once you’ve created an account, you’ll be able to experiment with the various account and notification settings that are available to you.</p>
<p>If you have feedback or see any issues, (especially with login) please file issues/comments/requests at <a href="https://bugs.swift.org">bugs.swift.org</a> under the “Project Infrastructure” component for tracking.</p>
</blockquote>
<p>Mike Ash wrote a great Friday Q&A on <a href="https://www.mikeash.com/pyblog/friday-qa-2017-12-08-type-erasure-in-swift.html">Type Erasure in Swift</a>. Back when I was first introduced to type erasure, it was difficult to understand. If that’s how you feel now, give this article a read. I think Mike provides some great examples.</p>
<p>objc.io published a blog post, <a href="https://www.objc.io/blog/2017/12/12/quick-tip-for-string-performance/">on <code class="language-plaintext highlighter-rouge">String</code> performance</a> with a pretty clever tip.</p>
<blockquote>
<p>The reason for the performance gain: a string can be backed by a Swift <code class="language-plaintext highlighter-rouge">String</code> or an <code class="language-plaintext highlighter-rouge">NSString</code>. By appending an empty string, we force it to be backed by a Swift <code class="language-plaintext highlighter-rouge">String</code>, with which our algorithm works much faster.</p>
</blockquote>
<p>Ole Begemann wrote a post on <a href="https://oleb.net/blog/2017/12/importing-c-library-into-swift/">importing a C library in Swift using SPM</a>. It’s an excerpt from their book, <em>Advanced Swift</em>, which I’d also highly recommend!</p>
<p>Nikolay Igotti <a href="https://blog.jetbrains.com/kotlin/2017/12/kotlinnative-v0-5-released-calling-kotlin-from-swift-and-c-llvm-5-and-more/">announced</a> reverse interop from Objective-C and Swift for Kotlin. You can now call Kotlin code from Swift and Objective-C.</p>
<p>Brian Gesiak continued his series on the Swift compiler with <a href="https://modocache.io/option-parsing-in-the-swift-compiler">Option Parsing in the Swift Compiler</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>I didn’t have enough time this week to browse through commits and pull requests, but know that the Swift team as been as busy as ever! This time of year we usually see refactorings, optimizations, and generally a lot of technical debt being paid off, which is great!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md">SE-0187</a>: <em>Introduce <code class="language-plaintext highlighter-rouge">Sequence.compactMap(_:)</code></em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-December/000416.html">accepted</a>.</p>
<blockquote>
<p>Hi, Swift community! I apologize for the delay in reporting our decision here; between one holiday and the other, it took awhile for the core team to assemble a quorum to talk through this. […] The result of the first review was consensus to rename the method, and the purpose of the second review was to get more specific feedback on what the new name should be.</p>
<p>“filterMap” is a name with some precedent in other programming languages, especially functional ones, but some people felt strongly that the name was misleading because, as a combined operation, it wasn’t quite a filter or a map. Of the alternatives, the one with the strongest support seemed to be “compactMap”, which builds on the precedent of “compact”, an operation from other languages (notably Ruby) which returns a copy of the input without nil values. Swift does not currently have such an operation, and in fact it is not currently possible to express it; nonetheless, the core team agrees that it would be a reasonable operation to add, and that “compactMap” is a good name for the operation.</p>
<p>Therefore, SE-0187 is accepted, with the revision that the new name be <code class="language-plaintext highlighter-rouge">Sequence.compactMap(_:)</code>, and with the agreement that we will add <code class="language-plaintext highlighter-rouge">Sequence.compact()</code> when it is possible to do so.</p>
<p>Thank you all for your continued contributions to making Swift a better language.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0192-non-exhaustive-enums.md">SE-0192</a>: <em>Non-Exhaustive Enums</em> by Jordan Rose is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-December/000417.html">under review</a>.</p>
<blockquote>
<p>Currently, adding a new case to an enum is a source-breaking change, which is very inconvenient for library authors. This proposal aims to distinguish between enums that are <em>exhaustive</em> (meaning they will never get any new cases) and those that are <em>non-exhaustive,</em> and to ensure that clients handle any future cases when dealing with the latter. Some key notes:</p>
<ul>
<li>This only affects <code class="language-plaintext highlighter-rouge">public</code> enums.</li>
<li>With rare exceptions, this does not affect <code class="language-plaintext highlighter-rouge">switch</code> statements in the same target as the enum.</li>
</ul>
</blockquote>
<p>This is definitely an exciting proposal for library authors! In Swift 5, public enums can be declared as <code class="language-plaintext highlighter-rouge">@exhaustive</code>, otherwise they default to non-exhaustive. The design and effects of such a seemingly small change are really interesting. I’d recommend reading the full proposal. It’s also important to note that this proposal effects ABI stability:</p>
<blockquote>
<p>Currently, the layout of a public enum is known at compile time in both the defining library and in its clients. For a library concerned about binary compatibility, the layout of a non-exhaustive enum must not be exposed to clients, since the library may choose to add a new case that does not fit in that layout in its next release.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0193-cross-module-inlining-and-specialization.md">SE-0193</a>: <em>Cross-module inlining and specialization</em> by Slava Pestov is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-December/000418.html">under review</a>.</p>
<blockquote>
<p>We propose introducing a pair of new attributes, <code class="language-plaintext highlighter-rouge">@inlinable</code> and <code class="language-plaintext highlighter-rouge">@abiPublic</code>. The <code class="language-plaintext highlighter-rouge">@inlinable</code> attribute exports the body of a function as part of a module’s interface, making it available to the optimizer when referenced from other modules. The <code class="language-plaintext highlighter-rouge">@abiPublic</code> attribute marks an internal declaration as being part of the binary interface of a module, allowing it to be used from <code class="language-plaintext highlighter-rouge">@inlinable</code> code without exposing it as part of the module’s source interface.</p>
<p>One of the top priorities of the Swift 5 release is a design and implementation of <em>the Swift ABI</em>. This effort consists of three major tasks:</p>
<ul>
<li>
<p>Finalizing the low-level function calling convention, layout of data types, and various runtime data structures. […]</p>
</li>
<li>
<p>Implementing support for <em>library evolution</em>, or the ability to make certain source-compatible changes, without breaking binary compatibility. […]</p>
</li>
<li>
<p>Stabilizing the API of the standard library. The goal here is to ensure that the standard library can be deployed separately from client binaries and frameworks, without forcing recompilation of existing code.</p>
</li>
</ul>
<p>All existing language features of Swift were designed with these goals in mind. In particular, the implementation of generic types and functions relies on runtime reified types to allow separate compilation and type checking of generic code.</p>
<p>[…]</p>
<p>On the other hand, across module boundaries, runtime generics introduce unavoidable overhead, as reified type metadata must be passed between functions, and various indirect access patterns must be used to manipulate values of generic type. We believe that for most applications, this overhead is negligible compared to the actual work performed by the code itself.</p>
<p>However, for some advanced use cases, and in particular for the standard library, the overhead of runtime generics can dominate any useful work performed by the library. Examples include the various algorithms defined in protocol extensions of <code class="language-plaintext highlighter-rouge">Sequence</code> and <code class="language-plaintext highlighter-rouge">Collection</code>, for instance the <code class="language-plaintext highlighter-rouge">map</code> method of the <code class="language-plaintext highlighter-rouge">Sequence</code> protocol. Here the algorithm is very simple and spends most of its time manipulating generic values and calling to a user-supplied closure; specialization and inlining can completely eliminate the algorithm of the higher-order function call and generate equivalent code to a hand-written loop manipulating concrete types.</p>
<p>[…]</p>
</blockquote>
<p>Another exciting proposal for library authors and Swift in general. This proposal has significant implications for potential performance improvements. I have high hopes for Swift 5. 😄 🤓</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/dazmuda/status/942889630738800640">great hires for functional programming roles</a>. 😄</p>
Issue #98
https://swiftweeklybrief.com/issue-98
2017-12-14T00:00:00-08:00
2017-12-14T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>All the way back in <a href="https://swiftweeklybrief.com/issue-55/">Issue #55</a> we covered discussions on the swift-evolution mailing list about possibly moving to a “modern” form-based solution for discussion and leaving the mailing lists behind. This week, about a year later, the transition to Discourse.org is starting <strong>today</strong>! This means the mailing lists will be disabled tonight (US Pacific time) with the transition completing by Monday (Dec 18).</p>
<p>I think most are excited about the move. Given the volume of discussions and the lack of adequate search for the mailing lists, I think this will be a great improvement for the Swift community — not to mention more approachable. If you’ve been avoiding swift-evolution because you aren’t a fan of email (who isn’t?!), then this might be your chance to get more involved. You’ll be able to sign up via email or with your GitHub account.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-6273">SR-6273)</a>: [Compiler] Disallow unconstructible infinite value types</li>
<li><a href="https://bugs.swift.org/browse/SR-6243">SR-6243</a>: [Foundation] <code class="language-plaintext highlighter-rouge">_fastEnumerationStorageMutationsPtr</code> isn’t doing anything</li>
<li><a href="https://bugs.swift.org/browse/SR-6082">SR-6082</a>: [Driver] Produce a better error message if Swift is run on a system without clang++</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/99551">Episode 39</a>: <em>Source Compatibility Suite Woes</em>. The source compatibility suite has been useful in catching compatibility issues before official Swift releases are cut, but it leaves much to be desired especially around communication with project maintainers outside Apple.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ole Begemann wrote a great post, <a href="https://oleb.net/blog/2017/12/dictionary-codable-array/">Why Dictionary sometimes encodes itself as an array</a>. Read on to found out!</p>
<p>From <a href="https://twitter.com/jckarter/status/941087094994214912">Joe Groff</a>:</p>
<blockquote>
<p>Moving from Swift 3 to 4, you may get “overriding declarations in extensions is not supported” errors. Before you panic and refactor everything, try adding <code class="language-plaintext highlighter-rouge">﹫objc</code> back to class extensions.</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov continued his work on class resilience <a href="https://github.com/apple/swift/pull/13312">here</a> and <a href="https://github.com/apple/swift/pull/13338">here</a>.</p>
<p>Ben Cohen opened a <a href="https://github.com/apple/swift/pull/13323">pull request</a> to eliminate <code class="language-plaintext highlighter-rouge">ArraySlice</code> from the std lib in favor of using <code class="language-plaintext highlighter-rouge">Slice</code> with conditional conformances.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/11869">fixed</a> four SR issues dealing with infinite recursion.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/13351">fixed</a> an issue regarding non-polymorphic constructors.</p>
<h3 id="proposal-pitches">Proposal pitches</h3>
<p>Nate Cook <a href="https://github.com/apple/swift-evolution/pull/773">drafted</a> a proposal for adding <code class="language-plaintext highlighter-rouge">last(where:)</code> and <code class="language-plaintext highlighter-rouge">lastIndex(where:)</code> to <code class="language-plaintext highlighter-rouge">Sequence</code> and <code class="language-plaintext highlighter-rouge">Collection</code>. You can view the <a href="https://github.com/natecook1000/swift-evolution/blob/31a84514aea6e3a05a685d31249dca7c20001f41/proposals/0000-add-last-methods.md">draft here</a> and the <a href="https://github.com/apple/swift/pull/13337">implementation here</a>.</p>
<blockquote>
<p>The standard library should include methods for finding the last element in a sequence, and the index of the last element in a collection, that match a given predicate.</p>
<p>The standard library currently has methods that perform a linear search to find an element or the index of an element that matches a predicate: […]</p>
<p>Unfortunately, there are no such methods that search from the end. Finding the last of a particular kind of element has multiple applications, particularly with text, such as wrapping a long string into lines of a maximum length or trimming whitespace from the beginning and end of a string.</p>
<p>You can work around this limitation by using the methods above on a reversed view of a collection, but the resulting code is frankly appalling.</p>
</blockquote>
<p>Chris Lattner opened <a href="https://github.com/apple/swift-evolution/pull/774">a new pull request</a> with a revision of his DynamicMemberLookup proposal. View the <a href="https://github.com/apple/swift-evolution/blob/40abd6fc5ff4e11fb73ba02cad9a7682a3f5a41f/proposals/XXXX-dynamic-member-lookup.md">draft here</a> and <a href="https://github.com/apple/swift/pull/13361">implementation here</a>.</p>
<blockquote>
<p>This proposal introduces a new <code class="language-plaintext highlighter-rouge">DynamicMemberLookupProtocol</code> type to the standard library. Types that conform to it provide “dot” syntax for arbitrary names which are resolved at runtime - in a <strong>completely type safe</strong> way. It is simple syntactic sugar which has a non-invasive implementation in the compiler.</p>
<p>Swift is well known for being exceptional at interworking with existing C and Objective-C APIs, but its support for calling APIs written in scripting languages like Python, Perl, and Ruby is quite lacking.</p>
<p>[…]</p>
</blockquote>
<p>John Holdsworth <a href="https://github.com/apple/swift-evolution/pull/771">drafted</a> a proposal for “raw” string literals. You can find the <a href="https://github.com/DoubleSpeak/swift-evolution/blob/d837ec040687f23de54b8abc01a81256ac238e9a/proposals/NNNN-raw-string-escaping.md">draft here</a> and the <a href="https://github.com/apple/swift/pull/13055">implementation here</a>.</p>
<blockquote>
<p>During the discussion on multi-line spring literals a mode for “raw-mode” strings was discussed but postponed for later consideration. This proposal looks to move this idea forward and suggests the smallest of changes be made to the Swift lexer to allow the entry of single and multi-line “raw” string literals by prefixing them with “r”. This adopts the precedent from the Python language. In raw literals, the \ character would have no special meaning.</p>
<p>One area where this form of quoting would be useful is entering regular expressions. As patterns can often contain elements such as \w or \S these do not translate well to the existing string literal syntax resulting in strings such as <code class="language-plaintext highlighter-rouge">let sentence = "\\w+(\\s+\\w+)\\."</code>. This is sometimes referred to as the “picket fencing” problem. Another example is entering windows file paths.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Nicole Jacque <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20171211/001401.html">announced</a> a proposal and timeline for the transition to Discourse.org! I recommend reading the full email for details. Nicole covers the forum structure (categories, tags, etc.), creating accounts (email or GitHub), and upvoting.</p>
<blockquote>
<p>Below is a summary proposal for our move to Discourse. Please note, that unless there are any serious objections, we’d like to do this transition over the next weekend, so please communicate any issues that you may see as soon as possible. Please file issues/comments/requests at <a href="http://bugs.swift.org/">bugs.swift.org</a> under the “Project Infrastructure” component for tracking.</p>
<p>[…]</p>
<p>In order to get the transition done, and work through any post-transition issues before many of the Swift infrastructure maintainers are on winter holiday break, we’d like to move forward soon — we propose starting the transition on the afternoon (US Pacific time) of Thursday, Dec. 14, and completing the transition by Dec 18 (Monday). This means that email from the mailing lists would be disabled on the evening of the 14th in order to do a final import of mailing list data. One final email would be sent out to the lists when the forums are up and ready for use.</p>
<p>The following @swift.org email lists will continue to function during and after the transition:</p>
<ul>
<li>code-owners</li>
<li>conduct</li>
<li>swift-infrastructure</li>
</ul>
<p><a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20171211/001401.html">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/modocache/status/938467399292063750">iceage</a>? 🤔</p>
Issue #97
https://swiftweeklybrief.com/issue-97
2017-12-07T00:00:00-08:00
2017-12-07T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Swift officially turned <a href="https://twitter.com/tkremenek/status/937421502101602304">two years old</a> this week, which means this newsletter is also two years old! It’s hard to believe. We’ve certainly come a long way, but there’s plenty of work to be done. Here’s to another great year of Swift!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/97828">Episode 38: Off to the races</a>. Think thread safety with Swift is the same as C languages, with slightly different syntax? Think again!</p>
<h3 id="news-and-community">News and community</h3>
<p>From <a href="https://twitter.com/tkremenek/status/937421502101602304">Ted Kremenek</a>:</p>
<blockquote>
<p>Two years ago today Swift became open source. Thank you to everyone who has (and continues) to contribute to Swift to make it a vibrant project.</p>
</blockquote>
<p>Xcode 9.2 <a href="https://developer.apple.com/news/releases/?id=12042017b">was released</a>, which ships with Swift 4.0.2. <a href="https://twitter.com/slava_pestov/status/938161436693446656">Slava Pestov noted</a>:</p>
<blockquote>
<p>Xcode 9.2 ships with Swift 4.0.2 which includes a large number of bug fixes, including several that y’all reported on Twitter</p>
</blockquote>
<p>From <a href="https://twitter.com/aciidb0mb3r/status/936386272318197760">Ankit Aggarwal</a>:</p>
<blockquote>
<p>If you write Swift scripts, add swiftpm as a dependency and try the new Utility product. It contains a nice collection of (cross platform) APIs, e.g. argument parser, in-memory filesystem, path, terminal controller, subprocess, sorted array etc</p>
</blockquote>
<p>Greg Heo wrote an article on <a href="https://swiftunboxed.com/stdlib/substrings/">Swift Substrings</a> and how they’re implemented. He also wrote about the implementation of <a href="https://swiftunboxed.com/interop/objc-dynamic/">@objc and dynamic</a>. Both are great reads, with delightful diagrams that really help explain what’s happening under-the-hood. 🤓</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/13178">made</a> <code class="language-plaintext highlighter-rouge">Codable</code> conformances for <code class="language-plaintext highlighter-rouge">Optional</code> and collections conditional. <em>“Array, Set, Dictionary, and Optional all provide unconditional conformances to Encodable & Decodable that dynamically check whether their type arguments are Encodable/Decodable. Now that we have conditional conformances, make these unconditional conformances properly conditional, removing all of the Swift 4-era type-erasure hacks.”</em></p>
<p>Max Moiseev <a href="https://github.com/apple/swift/pull/13292">improved</a> the default implementation of <code class="language-plaintext highlighter-rouge">Collection.distance(from:to:)</code>.</p>
<p>Previous versions of Swift accidentally treated <code class="language-plaintext highlighter-rouge">lazy</code> properties as computed properties because of how they were implemented. This has been fixed, but it’s a source-breaking change in Swift 5. Jordan Rose <a href="https://github.com/apple/swift/pull/13308">downgraded this error</a> to a warning for Swift 4.1. It’s another interesting case in source compatibility and preserving “broken” behavior.</p>
<p>Philippe Hausler <a href="https://github.com/apple/swift/pull/13280">fixed</a> a (rare) bug in <code class="language-plaintext highlighter-rouge">Data</code> in the Foundation SDK overlays that resulted in heap corruption.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md">SE-0189</a>: <em>Restrict Cross-module Struct Initializers</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000414.html">accepted</a>.</p>
<blockquote>
<p>During the review, most of the feedback voiced support that this was a necessary change for the library evolution (API resilience) story in Swift. There was some concern about the migration impact, as the change is source-breaking. Some options were discussed on the review thread to possibly mitigate the migration impact in some cases. Further, the thought process is that by having a warning in Swift 4.1 we can assess the impact of the change and soft message it, or if feedback is strong, re-evaluate the change.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md">SE-0191</a>: <em>Eliminate IndexDistance from Collection</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-December/000415.html">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted. Feedback for this simplification to the Collection protocols was positive.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041831.html">wrote an RFC on associated type inference</a>, aiming to remove parts of it and solicit feedback on a new approach. The topic was previously discussed last year.</p>
<blockquote>
<p>Associated type inference, which is the process by which the Swift compiler attempts to infer typealiases to satisfy associated-type requirements based on other requirements, has caused both implementation problems and user confusion for a long time. Some of you might remember a previous (failed) attempt to remove this feature from the Swift language, in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md">SE-0108 “Remove associated type inference”</a></p>
<p>I’m not sure we can remove this feature outright (i.e., the concerns that sank that proposal are still absolutely valid), because it is so very convenient and a lot of user code likely depends on it in some form or other. So, here I’d like to describe the uses of the feature, its current (very problematic) implementation approach, and a half-baked proposal to narrow the scope of associated type inference to something that I think is more tractable. I need help with the design of this feature, because I feel like it’s going to be a delicate balance between implementability and expressiveness.</p>
<p>[…]</p>
<p>What’s a Good Solution Look Like?
Our current system for associated type inference and associated type defaults is buggy and complicated. The compiler gets it right often enough that people depend on it, but I don’t think anyone can reasonably be expected to puzzle out what’s going to happen, and this area is rife with bugs. If we were to design a new solution from scratch, what properties should it have?</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171127/041831.html">Continue reading…</a></p>
</blockquote>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171204/006107.html">provided an update</a> on conditional conformances. The main missing piece here is support for dynamic casting. Doug is looking for feedback on the team’s implementation approach, as this involves a metadata change that will affect the ABI. (And remember, ABI stability is a hard requirement for Swift 5.)</p>
<blockquote>
<p>The main missing piece for conditional conformances (https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md) is support for dynamic casting. Right now, dynamic casting that queries a conditional conformance will always fail. […] We’d like to fix that :)</p>
<p>Joe Groff, Slava, and I discussed an approach to implement dynamic casting for conditional conformances, which I’d like to outline here.</p>
<p><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171204/006107.html">Continue reading…</a></p>
</blockquote>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042029.html">updated and shared</a> his Python interop playground.</p>
<blockquote>
<p>For anyone interested, here’s another update on this, including a bunch of operators, conformances to standard Swift protocols etc.</p>
</blockquote>
<p>Chris Lattner also <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042034.html">provided an update</a> on the direction of the random number API being discussed.</p>
<blockquote>
<p>The strong opinion of the core team is that such an API should <em>not</em> be designed with an attempt to service people writing crypto code. Such clients will have requirements that are difficult to predict or that are hard to provide in general (e.g. “must run in constant time”). These clients are also relatively few, compared the community of people who benefit from a good “general use” random number API.</p>
<p>As such, the core team strongly encourages the random number API design process to focus on building the best possible “general use” API, without worrying about the needs of crypto experts.</p>
<p>Beyond that, the core team did not discuss what the exact shape of the API should look like: it believes the community should continue hashing it out. We just wanted to remove one big constraint from that design process.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/modocache/status/937430138857447424">Xcode Spinner II</a>.</p>
Issue #96
https://swiftweeklybrief.com/issue-96
2017-11-30T00:00:00-08:00
2017-11-30T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>I’ve returned! 😊 Welcome back to the weekly. We skipped last week and I haven’t written the last few issues, but luckily we have <a href="https://swiftweeklybrief.com/authors/">some amazing contributors</a> to help bring this to your inbox each week. Big thanks to <a href="https://twitter.com/basthomas">Bas</a>, <a href="https://twitter.com/modocache">Brian</a>, and <a href="https://twitter.com/volkovre">Roman</a>. I was traveling and speaking at <a href="http://iosconf.sg">iOS Conf Singapore</a> and then the very first <a href="https://www.tryswift.co/events/2017/bangalore/">try! Swift India</a> — both of which were great!</p>
<p>This week, we saw a progress on conditional conformances, a few new proposals, and discussions on Swift interop with Python.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/94838">Episode 37: Enum case enumerable proposal</a>: JP and Jesse discuss the popular, long ago deferred proposal for enumerating all cases of an enum.</p>
<h3 id="news-and-community">News and community</h3>
<p>All of the videos from iOS Conf Singapore last month have been posted. There’s a <a href="https://www.youtube.com/watch?v=2fO-B4qL8ZA&list=PLED4k3CZkY9S5UzlKToFiVSrXK_lzNRGL">playlist on YouTube</a>. While this is an iOS conference, there was no shortage of talks specifically about Swift:</p>
<ul>
<li><a href="https://www.youtube.com/watch?v=G88qaR9R0v0">Slow Swift</a>, Marcin Krzyzanowski</li>
<li><a href="https://www.youtube.com/watch?v=cdRn4DJq9eY&t=6s">Exploring Swift’s numeric types and protocols</a>, Jesse Squires</li>
<li><a href="https://www.youtube.com/watch?v=Q1Tayh4unMw">To be! Or not? Optionals in practice</a>, Rob Napier</li>
<li><a href="https://www.youtube.com/watch?v=RRnoYYolgT8">Strings in Swift</a>, Omer Iqbal</li>
<li><a href="https://www.youtube.com/watch?v=_txZbmYmT3Y">Codeable in Swift 4</a>, Sam Davies</li>
</ul>
<p>Brian Gesiak continued his Swift compiler series this week with a new post, <a href="https://modocache.io/reading-and-understanding-the-swift-driver-source-code">Reading and Understanding the Swift Driver Source Code</a>.</p>
<p>Greg Heo crafted an <a href="https://twitter.com/gregheo/status/933429621399289856">excellent diagram</a> of the Swift compilation flow. 😆</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Daniel Dunbar opened a work-in-progress <a href="https://github.com/apple/swift-llbuild/pull/200">pull request</a> to allow swift-llbuild to be used via the Swift Package Manager.</p>
<p>Keith Smiley <a href="https://github.com/apple/swift-lldb/pull/259">fixed</a> a bug in lldb for using enums as Swift dictionary keys, <a href="https://bugs.swift.org/browse/SR-6290">SR-6290</a>. Definitely a strange edge case! (pun intended 😉)</p>
<p>Simon Evans <a href="https://github.com/apple/swift-corelibs-foundation/pull/1286">merged</a> a pull request that adds Darwin compatibility tests to corelibs-foundation. <em>“This allows tests to be validated against the native Foundation and is useful for checking edge cases…”</em></p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/13046">merged</a> changes to use conditional conformances to implement <code class="language-plaintext highlighter-rouge">Equatable</code> for <code class="language-plaintext highlighter-rouge">Optional</code>, <code class="language-plaintext highlighter-rouge">Array</code>, and <code class="language-plaintext highlighter-rouge">Dictionary</code>. He also <a href="https://github.com/apple/swift/pull/13041">merged</a> minor optimizations for protocol conformances.</p>
<p>Chris Lattner <a href="https://github.com/apple/swift-evolution/pull/768">drafted</a> his proposal, <a href="https://github.com/apple/swift-evolution/blob/3c2947c7d6e894b36ceaf18ce32e85facc5e6feb/proposals/0191-DynamicMemberLookup.md"><em>Introduce User-defined “Dynamic Member Lookup” Types</em></a> and <a href="https://github.com/apple/swift/pull/13076">implemented</a> the proposed <code class="language-plaintext highlighter-rouge">DynamicLookupProtocol</code> in the std lib. This lays the necessary groundwork for interoperating with scripting languages like Python (discussed below).</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/13062">improved</a> support for large (<code class="language-plaintext highlighter-rouge">DoubleWidth</code>) integers in the std lib.</p>
<p>Xiaodi Wu <a href="https://github.com/apple/swift/pull/13007">merged changes</a> that eliminate intermediate rounding error in floating-point strides.</p>
<p>Ben Cohen made <a href="https://github.com/apple/swift/pull/12913">progress on</a> Swift’s conditional conformances, adopting them for <code class="language-plaintext highlighter-rouge">Indices</code>, <code class="language-plaintext highlighter-rouge">Slice</code>, and <code class="language-plaintext highlighter-rouge">ReversedCollection</code>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0190-target-environment-platform-condition.md">SE-0190</a>: <em>Target environment platform condition</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000410.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000413.html">accepted</a>. You can find the <a href="https://github.com/apple/swift/pull/12964">implementation here</a>.</p>
<blockquote>
<p>During the review, support for the enhancement was unanimous. There were some questions during the review about the capabilities of this feature. Graydon explained that his is largely surfacing target environment information from the target triple, which can be flexibly used in many circumstances.</p>
<p>Thanks to everyone who participated in the review.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md">SE-0188</a>: <em>Make Standard Library Index Types Hashable</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000411.html">accepted</a>.</p>
<blockquote>
<p>During the review, the only point of discussion was whether to go one step further and make conformance to Hashable a requirement for all Collection indices. While this would be a source-breaking change, the core team are receptive to this proposal being pitched and discussed as a separate evolution proposal if it covered the handling of the source compatibility issues.</p>
<p>Thanks to everyone who participated in the review.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0191-eliminate-indexdistance.md">SE-0191</a>: <em>Eliminate <code class="language-plaintext highlighter-rouge">IndexDistance</code> from <code class="language-plaintext highlighter-rouge">Collection</code></em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000412.html">under review</a>. You can find the <a href="https://github.com/apple/swift/pull/12641">implementation here</a>.</p>
<blockquote>
<p>Eliminate the associated type <code class="language-plaintext highlighter-rouge">IndexDistance</code> from <code class="language-plaintext highlighter-rouge">Collection</code>, and modify all uses to the concrete type <code class="language-plaintext highlighter-rouge">Int</code> instead.</p>
<p><code class="language-plaintext highlighter-rouge">Collection</code> allows for the distance between two indices to be any <code class="language-plaintext highlighter-rouge">SignedInteger</code> type via the <code class="language-plaintext highlighter-rouge">IndexDistance</code> associated type. While in practice the distance between indices is almost always an <code class="language-plaintext highlighter-rouge">Int</code>, generic algorithms on <code class="language-plaintext highlighter-rouge">Collection</code> need to either constrain <code class="language-plaintext highlighter-rouge">IndexDistance == Int</code> or write their algorithm to be generic over any <code class="language-plaintext highlighter-rouge">SignedInteger</code>.</p>
<p>Swift 4.0 introduced the ability to constrain associated types with <code class="language-plaintext highlighter-rouge">where</code> clauses
(<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md">SE-142</a>) and will soon allow protocol constraints to be recursive (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-157</a>). With these features, writing generic algorithms against <code class="language-plaintext highlighter-rouge">Collection</code> is finally a realistic tool for intermediate Swift programmers. You no longer need to know to constrain <code class="language-plaintext highlighter-rouge">SubSequence.Element == Element</code> or <code class="language-plaintext highlighter-rouge">SubSequence: Collection</code>, missing constraints that previously led to inexplicable error messages.</p>
<p>At this point, the presence of <code class="language-plaintext highlighter-rouge">IndexDistance</code> is of of the biggest hurdles that new users trying to write generic algorithms face. If you want to
write code that will compile against any distance type, you need to constantly juggle with explicit type annotations (i.e. you need to write <code class="language-plaintext highlighter-rouge">let i:
IndexDistance = 0</code> instead of just <code class="language-plaintext highlighter-rouge">let i = 0</code>), and perform <code class="language-plaintext highlighter-rouge">numericCast</code> to convert from one distance type to another.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Graydon Hoare <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/006001.html">shared updates</a> about ongoing work related to compilation performance.</p>
<blockquote>
<p>This is just an update on some work that’s been ongoing in the past several months related to tracking and improving Swift compilation performance. I’ve been helping coordinate some of that work: documenting what’s known about compilation performance patterns and diagnostic machinery, increasing visibility and process controls around compilation performance, and also helping making some changes directly to the compiler.</p>
<p>I wanted to post here to make sure everyone’s aware of what’s currently going on, as well as solicit feedback on priorities and ways to help others interested in the topic.</p>
<p>Here’s a bit of an overview of recent activities:</p>
<p><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/006001.html">Continue reading…</a></p>
</blockquote>
<p>Graydon covers compilation-performance testing, measurements, scale testing, reducing quadratic costs, and improving incremental mode. I highly suggest reading the full email and following the links, especially the <a href="https://github.com/apple/swift/blob/master/docs/CompilerPerformance.md">Swift Compiler Performance</a> doc.</p>
<p>Nicole Jacque <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041355.html">started the discussion</a> on moving swift-evolution from their current form to Discourse.</p>
<blockquote>
<p>As Ted Kremenek has previously announced, we are in the process of moving the Swift mailing lists to Discourse. Previously the discussion was mostly about moving swift-evolution over to a forum, but the consensus from Ted and the Core Team was that should look to move all the lists to Discourse for consistency.</p>
<p>I will be shepherding the transition from the mailing lists to the forum. Rather than simply move the existing lists and structure as-is, we’d like to take this opportunity to explore new ways of organizing the forums to help foster communication and collaboration. We also have a number of new options that will be available with Discourse, that we’d like some input from the community on.</p>
<p>To help with this, I am looking for 3-4 volunteers from the Swift community to create a workgroup to discuss and create a plan for the structure for the Discourse-based forums. We will then present this plan back to the community. We are also investigating the possibility of having a preview version of the forums available for comment from the community.</p>
<p>If you would like to be part of this workgroup, please reply back to me and let me know!</p>
</blockquote>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution//Week-of-Mon-20171113/041463.html">discussed</a> Python interoperability with Swift:</p>
<blockquote>
<p>As I mentioned on a couple other threads, I’ve been working on improving Swift interoperability with Python. I have two pitches out: one to improve Python member lookup and one to improve calls to Python values. While those proposals are important, I think it is also useful to see what can be accomplished with Swift today.</p>
<p>To show you how far we can get, here is a Swift playground (tested with Xcode 9) that has an example interoperability layer, and a tutorial for using it. If you’re interested in the pitches, or in Python, please <a href="https://lists.swift.org/pipermail/swift-evolution/attachments/20171119/ed5c1964/attachment.zip">check it out</a>.</p>
<p>In addition to showing how far the interop can go today (which is really quite far) it shows what the future will look like assuming the member lookup and call issues are resolved. To reiterate what I said on the pitch threads, I am not attached at all to the details of the two pitches themselves, I simply want the problems they address to be solved.</p>
<p>Finally, of course I also welcome questions and feedback on the actual approach, naming, and other suggestions to improve the model!</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/934867063721541632">A team of iOS developers prepare to type-erase a protocol with associated types</a>.</p>
Issue #95
https://swiftweeklybrief.com/issue-95
2017-11-16T00:00:00-08:00
2017-11-16T00:00:00-08:00
Brian Gesiak
https://twitter.com/modocache
https://github.com/modocache.png?size=100
modocache
<p>“The sky is falling! The sky is falling, and Google is forking Swift!”</p>
<p>Fear not, dear reader, Google doesn’t appear to be “forking” the Swift project
– no matter what the blowhards on some venture capitalist’s forum board tell
you. Instead, Google employees will simply be using <a href="https://github.com/google/swift">google/swift</a>
as a staging area for their pull requests to the main <a href="https://github.com/apple/swift">apple/swift</a>
project. In fact, this week we already saw some incredible contributions from
Google engineers, including support for Fuchsia OS!</p>
<p>So while the internet tries to get a rise out of you, just keep reading Swift
Weekly Brief to learn what’s <em>really</em> going on in Swift – I promise you it’ll
be less melodramatic than what’s “trending” on Twitter. 😏</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p><a href="https://bugs.swift.org/browse/SR-6360">SR-6360</a>: Ever try to type
<code class="language-plaintext highlighter-rouge">UnsafeMutableRawBufferPointer</code>, but end up writing
<code class="language-plaintext highlighter-rouge">UnsafeRawMutableBufferPointer</code> instead? It’s a reasonable mistake, and the
Swift compiler should inform users that they switched the placement of <code class="language-plaintext highlighter-rouge">Raw</code>
and <code class="language-plaintext highlighter-rouge">Mutable</code>. Check the comments on this one for some helpful hints from
<a href="https://twitter.com/UINT_MIN">Jordan Rose</a>.</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/89166">Episode 36: Swift Evolution - Current Topics & Proposals</a>:
Jesse and JP discuss some recent proposals.</p>
<h3 id="news-and-community">News and community</h3>
<p>A team at Google is planning on contriuting to Swift’s lib/Syntax.
<a href="https://twitter.com/lexlash/status/930877904551944192">Alexander Lash</a>
<a href="https://twitter.com/lexlash/status/930877904551944192">writes</a>, “My team is
planning to contribute to lib/Syntax - we’re interested in linting, formatting,
and refactoring.” No word yet on whether they’re accepting résumés! 😉</p>
<p><a href="https://twitter.com/Injection4Xcode">John Holdsworth</a> <a href="https://github.com/johnno1962/SwiftPython">implemented</a>
a proof-of-concept for calling Python code from within Swift.</p>
<p>GitHub user <a href="https://github.com/quellish">@quellish</a> <a href="https://github.com/quellish/XcodeNewBuildSystem">claims</a>
that the new Xcode build system was “on average 28% faster with clean builds
and 82% faster on incremental builds” when building an open-source application
named “V2EX.app”.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Google engineer <a href="https://twitter.com/zbowling">Zac Bowling</a> has <a href="https://github.com/apple/swift/pull/12955">opened</a>
a pull request that adds a Fuchsia OS target to the Swift compiler (one of the
first pull requests submitted from the <a href="https://github.com/google/swift">google/swift</a>
repository). In case you’re keeping track, a comprehensive set of OS target
conditionals in Swift now looks like this:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="cp">#if os(OSX) || os(iOS) || os(tvOS) || os(watchOS)</span>
<span class="c1">// ...</span>
<span class="cp">#elseif os(Linux) || os(FreeBSD) || os(PS4) || os(Android) || os(Cygwin) || os(Fuchsia) || os(Haiku)</span>
<span class="c1">// ...</span>
<span class="cp">#endif</span></code></pre></figure>
<p>A lot of work this week has centered on conditional conformances:</p>
<ul>
<li><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://github.com/apple/swift/pull/12910">merged</a>
a pull request to implement <code class="language-plaintext highlighter-rouge">Equatable</code> using conditional conformances, for
<code class="language-plaintext highlighter-rouge">Optional</code>, <code class="language-plaintext highlighter-rouge">Array</code>, and <code class="language-plaintext highlighter-rouge">Dictionary</code>.</li>
<li><a href="https://twitter.com/AirspeedSwift">Ben Cohen</a> <a href="https://github.com/apple/swift/pull/12913">opened</a>
a work-in-progress pull request that demonstrates just how much boilerplate
can be eliminated from the Swift standard library thanks to conditional
conformances.</li>
<li><a href="https://github.com/huonw">Huon Wilson</a> <a href="https://github.com/apple/swift/pull/12531">merged</a>
changes to lib/IRGen that allow Swift to produce LLVM IR to represent
conditional conformances.</li>
</ul>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> is going wild
reducing Swift compilation times and improving runtime performance. He <a href="https://github.com/apple/swift/pull/6485">opened</a>
a draft pull request with what <a href="https://twitter.com/jckarter">Joe Groff</a> <a href="https://twitter.com/jckarter/status/928733395219185664">calls</a>
“a pretty significant optimization for unspecialized Swift code,” as well as
a work-in-progress <a href="https://github.com/apple/swift/pull/12855">pull request</a>
that he <a href="https://twitter.com/slava_pestov/status/928834964690411520">notes</a>
will crack down on some redundant validation the Swift compiler performs.</p>
<p><a href="https://twitter.com/aciidb0mb3r">Ankit Aggarwal</a> <a href="https://github.com/apple/swift-package-manager/pull/1390">opened</a>
a pull request that allows Swift package manager to build projects with the
thread sanitizer enabled.</p>
<p><a href="https://github.com/alper">Alper Cugun</a> <a href="https://github.com/apple/swift/pull/12856">fixed</a>
one of the starter tasks mentioned in last week’s issue.</p>
<p>Many people (myself included) have tried to refactor Swift’s Python
<code class="language-plaintext highlighter-rouge">build-script</code>. Thankfully, Apple’s <a href="https://github.com/Rostepher">Ross Bayer</a>
has picked up the mantle and <a href="https://github.com/apple/swift/pull/12873">opened</a>
a pull request.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>The review period of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md">SE-0187</a>:
<em>Introduce <code class="language-plaintext highlighter-rouge">Sequence.filterMap(_:)</code></em> has been <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171113/041342.html">accepted</a>
with an additional re-review period of November 15th - 20th, in order to decide
on a new name: <code class="language-plaintext highlighter-rouge">filterMap</code>, <code class="language-plaintext highlighter-rouge">compactMap</code>, or something else entirely.</p>
<blockquote>
<p>[T]he core team feels that the central question is whether Swift benefits from
overloading <code class="language-plaintext highlighter-rouge">flatMap</code> in this way. There is a reasonable argument that an
<code class="language-plaintext highlighter-rouge">Optional</code> is a sort of container, and therefore it makes sense to “flatten”
that container into a surrounding container. But Swift has resisted applying
that interpretation in its library design; for example, you cannot directly
iterate an <code class="language-plaintext highlighter-rouge">Optional</code> or append its contents to an Array. In general, we feel
that using different operations for working with <code class="language-plaintext highlighter-rouge">Optional</code>s tends to make
code easier to both write and understand, especially given the existence of
implicit optional promotion, which we cannot eliminate or easily suppress
based on the context. On reflection, we think it was a mistake to use the
same name in the first place, and there is no better time to fix a mistake
than now.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>The <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000408.html">review</a>
of <em><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0189-restrict-cross-module-struct-initializers.md">SE-0189</a>:
Restrict Cross-module Struct Initializers</em> has begun and runs through November
21st, 2017.</p>
<blockquote>
<p>Adding a property to a public struct in Swift ought to not be a
source-breaking change. However, a client in another target can currently
extend a struct with a new initializer that directly initializes the struct’s
fields. This proposal forbids that, requiring any cross-target initializers to
use <code class="language-plaintext highlighter-rouge">self.init(...)</code> or assign to <code class="language-plaintext highlighter-rouge">self</code> instead. This matches an existing
restriction for classes, where cross-module initializers must be convenience
initializers.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p><a href="https://twitter.com/racer_girl27">Nicole Jacque</a> is <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/005988.html">seeking</a>
volunteers to join a workgroup that aims to “discuss and create a plan for the
structure for the Discourse-based forum.” If you have ideas for how online
discussions of Swift should take place, please consider volunteering!</p>
<p><a href="https://twitter.com/clattner_llvm">Chris Lattner</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/041142.html">pitched</a>
adding user-defined dynamically “callable” types, as part of a series of ideas
he has around helping Swift interoperate with dynamic languages such as Python.</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171106/005934.html">sent</a>
an email summarizing the current state of Swift compile time debugging options
such as <code class="language-plaintext highlighter-rouge">-debug-time-function-bodies</code>, and asked whether anyone had suggestions
for future work in this area. He also <a href="https://github.com/apple/swift/pull/12939">opened</a>
a pull request to fix an issue he mentioned in the email.</p>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171106/005828.html">sent</a>
an email summarizing how the compiler generates type metadata records, and what
implications that has for ABI stability. His email also suggests areas to
change.</p>
<p><a href="https://twitter.com/jckarter">Joe Groff</a> <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/005971.html">proposed</a>
generalizing the nominal type descriptor data emitted as part of Swift modules’
type metadata, into something he calls “context descriptors.”</p>
<p>Following up on his <a href="https://github.com/apple/swift/pull/12789">pull request</a>
adding a representation for coroutines in SIL, which last week’s issue of the
weekly covered, John McCall <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/005965.html">sent</a>
a proposal for how to represent coroutine types in the Swift AST. His proposal
hints at how coroutines will be gradually introduced into Swift’s syntax:</p>
<blockquote>
<p>Only special kinds of declarations can be coroutines. In the first stage,
that will exclusively be read/modify accessors; eventually we will add
generators, but maybe not in Swift 5.</p>
</blockquote>
<p>Last week’s issue of the weekly mentioned that Erik Eckstein proposed
deprecating the <code class="language-plaintext highlighter-rouge">-Ounchecked</code> Swift compiler option. That conversation pivoted
into a discussion on whether compiler flags are subject to the Swift Evolution
process of community review. This week, <a href="https://twitter.com/tkremenek">Ted Kremenek</a>
<a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171106/005938.html">weighed in</a>
to make the case that they are in some cases, and this is one such case. Sounds
like we may see a proposal to remove <code class="language-plaintext highlighter-rouge">-Ounchecked</code> soon – the first Swift
Evolution proposal related to compiler flags.</p>
<p>Swift is capable of running on many platforms outside of just macOS and Linux,
but those are the only platforms that are built and tested by the Swift
project’s continuous integration bots. Back in September 2016, Ted Kremenek
<a href="https://github.com/apple/swift-corelibs-foundation/pull/622#issuecomment-247415912">mentioned</a>
that support for other platforms would be added, and the clearest estimate of
when that was provided on the mailing list was <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160919/002972.html">“soon”</a>.
This week, Ted <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171113/005983.html">mentioned</a>
that the feature was tentatively planned for December 2017, but no official
announcement has yet been made.</p>
<h3 id="finally">Finally</h3>
<p>I didn’t think you could get “real work” done on an iPad, but this photo
gave me <a href="https://twitter.com/jckarter/status/930542808796037120">paws</a>.</p>
Issue #94
https://swiftweeklybrief.com/issue-94
2017-11-09T00:00:00-08:00
2017-11-09T00:00:00-08:00
Brian Gesiak
https://twitter.com/modocache
https://github.com/modocache.png?size=100
modocache
<p>This week in Swift development: the Swift team created several fun new starter
tasks, Doug Gregor fixed a nasty bug in Objective-C interop, and the mailing
lists were abuzz with several exciting Swift Evolution proposals. Adjust your
Apple Watches – it’s “Swift Weekly Brief O’Clock”!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-6264">SR-6264</a>: This task is to extract
duplicated code in three methods. The methods each check whether a declaration
may be used externally based on its access level (<code class="language-plaintext highlighter-rouge">public</code>, <code class="language-plaintext highlighter-rouge">internal</code>, etc.).</li>
<li><a href="https://bugs.swift.org/browse/SR-6272">SR-6272</a>: This task is to add better
diagnostics for common numerical conversions. For example, the Swift compiler
should be able to suggest a cast for source code that attempts to multiply an
<code class="language-plaintext highlighter-rouge">Int</code> and a <code class="language-plaintext highlighter-rouge">CGFloat</code>.</li>
<li><a href="https://bugs.swift.org/browse/SR-6312">SR-6312</a>: To clone the apple/swift
family of projects, and to pull in the latest changes to those clones,
contributors use a Python script: <code class="language-plaintext highlighter-rouge">utils/update-checkout --clone</code> to clone,
and just <code class="language-plaintext highlighter-rouge">utils/update-checkout</code> to update. This task is to modify
<code class="language-plaintext highlighter-rouge">utils/update-checkout</code> so that it suggests using <code class="language-plaintext highlighter-rouge">--clone</code> if the user
attempts to update before cloning.</li>
</ul>
<p>If you’re looking for a meatier task, you may want to try
<a href="https://bugs.swift.org/browse/SR-3423">SR-3423</a>, which would allow enum cases
with tuple raw values. In other words, you could make this possible in Swift:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">enum</span> <span class="kt">Status</span><span class="p">:</span> <span class="p">(</span><span class="kt">Int</span><span class="p">,</span> <span class="kt">String</span><span class="p">)</span> <span class="p">{</span>
<span class="k">case</span> <span class="kt">OK</span> <span class="o">=</span> <span class="p">(</span><span class="mi">200</span><span class="p">,</span> <span class="s">"OK"</span><span class="p">)</span>
<span class="k">case</span> <span class="kt">NotFound</span> <span class="o">=</span> <span class="p">(</span><span class="mi">404</span><span class="p">,</span> <span class="s">"Not Found"</span><span class="p">)</span>
<span class="p">}</span></code></pre></figure>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://twitter.com/arekholko">Arek Holko</a> <a href="https://github.com/fastred/Optimizing-Swift-Build-Times">posted</a>
a checklist for diagnosing and improving long compile times in Swift projects.</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> continued his Swift compiler series with
<a href="https://modocache.io/introduction-to-the-swift-compiler-driver"><em>An Introduction to the Swift Compiler Driver</em></a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://twitter.com/dgregor79">Doug Gregor</a> <a href="https://github.com/apple/swift/pull/12823">fixed</a>
an issue in which Swift’s ClangImporter would use a stale AST cache for
properties of Objective-C classes, which affected how declarations would be
imported into Swift. This most likely fixes an issue in which
<code class="language-plaintext highlighter-rouge">-[UIView addGestureRecognizer:]</code> would sometimes be imported as
<code class="language-plaintext highlighter-rouge">UIView.add(_:)</code>.</p>
<p><a href="https://twitter.com/pathofshrines">John McCall</a> <a href="https://github.com/apple/swift/pull/12789">added</a>
a way to represent coroutines in Swift’s intermediate language, SIL.</p>
<p><a href="https://twitter.com/daniel_dunbar">Daniel Dunbar</a> opened a <a href="https://github.com/apple/swift-llbuild/pull/195">pull request</a>
that improves the cancellation model in llbuild. Previously, cancelling a build
in llbuild would not stop work that was in-flight, but instead merely have those
units of work finish normally and then report a “cancelled” status. The change
cancels the work, preventing it from completing as it normally would.</p>
<p><a href="https://github.com/rudkx">Mark Lacey</a> opened a <a href="https://github.com/apple/swift/pull/12682">pull request</a>
to fix edge cases in which implicitly-unwrapped optional (IUO) usage that was
disallowed by <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054</a>
was considered valid in Swift 3 and 4. This is a “source-breaking” change for
codebases that used syntax that, while being technically invalid in Swift 3 and
4, would not result in errors being emitted by the Swift compiler until now.
He also opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/1306">pull request</a>
that removes a soon-to-be-disallowed IUO from swift-corelibs-foundation.</p>
<p><a href="https://twitter.com/phausler">Philippe Hausler</a> opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/1305">pull request</a>
to update swift-corelibs-foundation with the latest CoreFoundation source code
included in macOS High Sierra.</p>
<p><a href="https://github.com/fjricci">Francis Ricci</a> opened a <a href="https://github.com/apple/swift/pull/12702">pull request</a>
that allows Objective-C to be imported even on non-Darwin platforms. Although
I would imagine almost no developers use an Objective-C runtime outside of
Darwin, this does decouple some ClangImporter behavior from its host platform,
which seems like a good thing to do.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>The <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000406.html">review</a>
of <em><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0187-introduce-filtermap.md">SE-0187</a>:
Introduce <code class="language-plaintext highlighter-rouge">Sequence.filterMap(_:)</code></em> has begun and runs through November 14th, 2017.</p>
<blockquote>
<p>We propose to deprecate the controversial version of a <code class="language-plaintext highlighter-rouge">Sequence.flatMap</code>
method and provide the same functionality under a different, and potentially
more descriptive, name. […] The name being <code class="language-plaintext highlighter-rouge">filterMap(_:)</code> as we believe it
best describes the intent of this function. […] Since the old function will
still be available (although deprecated) all the existing code will compile,
producing a deprecation warning and a fix-it.</p>
</blockquote>
<p>The <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-November/000407.html">review</a>
of <em><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0188-stdlib-index-types-hashable.md">SE-0188</a>:
Make stdlib index types <code class="language-plaintext highlighter-rouge">Hashable</code></em> begins now and runs through November 14th, 2017.</p>
<blockquote>
<p>This proposal would add <code class="language-plaintext highlighter-rouge">Hashable</code> conformance to all the index types in the
standard library. With that done, <code class="language-plaintext highlighter-rouge">[Int]</code>, <code class="language-plaintext highlighter-rouge">String</code>, and all other standard
libary collections would have the same behavior when using subscripts in key
paths.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Tony Parker <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040959.html">solicited</a>
public feedback on a Foundation-only proposal that has been evaluated internally
at Apple. The proposal is for a mechanism to encode and decode JSON keys in
order to, for example, automatically deserialize <code class="language-plaintext highlighter-rouge">snake_case_keys</code> as
<code class="language-plaintext highlighter-rouge">camelCaseKeys</code>.</p>
<p><a href="https://twitter.com/davedelong">Dave DeLong</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040862.html">proposed</a>
allowing custom operators to take parameters with default arguments. He also
provided an implementation with the proposal.</p>
<p>Ben Cohen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/041053.html">pitched</a>
eliminating <code class="language-plaintext highlighter-rouge">IndexDistance</code> from <code class="language-plaintext highlighter-rouge">Collection</code>. He <a href="https://twitter.com/AirspeedSwift/status/928376958357876736">tweeted</a>
that it would make writing generic algorithms easier.</p>
<p>Alejandro Alonso <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039605.html">proposed</a>
adding standard library functions for generating random numbers, as well as for
randomizing the order of an array (“shuffling”). The proposal aims to address
a pain point in cross-platform Swift development, since different platforms
use different randomization functions (<code class="language-plaintext highlighter-rouge">arc4random()</code> on Darwin, <code class="language-plaintext highlighter-rouge">random()</code> or
<code class="language-plaintext highlighter-rouge">rand()</code> on Linux, etc.).</p>
<p><a href="https://twitter.com/jtbandes">Jacob Bandes-Storch</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040950.html">re-proposed</a>
adding an <code class="language-plaintext highlighter-rouge">allCases</code> static property to enums. The proposal was widely popular
when it was first proposed for Swift 3, but ultimately deferred. If it’s
accepted this time, we may see it in Swift 5.</p>
<p>Discussion of <a href="https://twitter.com/graydon_pub">Graydon Hoare</a>’s Swift Evolution
<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040652.html">proposal draft</a>,
which adds a target environment platform condition to the Swift language,
continues. The patch proposes adding a <code class="language-plaintext highlighter-rouge">#if targetEnvironment(simulator)</code>
condition. Replies to the proposal began to discuss what attributes should be
available as platform conditions. This week, Graydon <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040819.html">pointed out</a>
that whether the compilation target was a simulator or not was encoded in the
target triple, a decision made recently in LLVM, so discussions of whether it
should be encoded at all should be done on the LLVM mailing lists.</p>
<p><a href="https://twitter.com/beccadax">Becca Royal-Gordon</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171030/040863.html">asked</a>
about how she could update her once deferred proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md">SE-0132</a>,
which proposes renaming several <code class="language-plaintext highlighter-rouge">Sequence</code> and <code class="language-plaintext highlighter-rouge">Collection</code> methods such that
they follow a consistent naming scheme.</p>
<p>Erik Eckstein <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171030/005774.html">proposed</a>
deprecating the <code class="language-plaintext highlighter-rouge">-Ounchecked</code> compiler option. This optimization mode removes
runtime safety checks, and adds additional complexity to the standard library
code, which must behave differently at that optimization level.</p>
<p><a href="https://twitter.com/rballard">Rick Ballard</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171106/040953.html">responded</a>
to questions about SwiftPM’s roadmap for Swift 5.</p>
<p>Kelvin Ma <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171106/005811.html">pointed out</a>
that Swift has potential to layout some enums using fewer bytes.</p>
<h3 id="finally">Finally</h3>
<p>Did you <a href="https://twitter.com/lapcatsoftware/status/926911250507993088">remember</a> to adjust for DST? (That’s “delightful Swift time”, of course.)</p>
Issue #93
https://swiftweeklybrief.com/issue-93
2017-11-02T00:00:00-07:00
2017-11-02T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It’s iPhone X week! Tomorrow, the first customers will receive their new devices.
In other news… the team working on Swift at Apple is <a href="https://twitter.com/gregheo/status/925119320606236673">reading our blogs</a>, so definitely keep up the blogging (or start doing so?!)</p>
<p>Apple also released Xcode 9.1, which includes <a href="https://twitter.com/slava_pestov/status/925548115452497920">fixes for various Swift crashers</a>.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/91842">Episode 35</a> Jesse and JP talk about performance profiling in Linux - without Instruments.</p>
<h3 id="news-and-community">News and community</h3>
<p>The video of Doug, Slava and John’s talk on “Implementing Swift Generics” is now <a href="https://twitter.com/modocache/status/925555416351825920">available</a>.</p>
<p>Apple’s Joe Groff and Xi Ge gave talks at <a href="http://swiftsummit.com">Swift Summit</a> this week, where Joe talked about “Swift’s Reflective Underpinnings” and Xi talked about “Creating Refactoring Transformations for Swift”. At the same conference, there were also “Open Sourcing Swift” and “Refactoring Transformations” labs run by Apple. So awesome to see Apple engineers attending and speaking at conferences, sharing their knowledge! 🤓</p>
<p>Video’s of JP’s and my talk from FrenchKit are available. JP talked about <a href="https://www.youtube.com/watch?v=TWeLLTFjqXg">Profiling Swift Performance on Linux</a>, I gave a talk about <a href="https://www.youtube.com/watch?v=XXqZaKodLfA">What’s up with Swift 5</a>.</p>
<p>Slava shared a gentle reminder of the awesome <a href="https://twitter.com/slava_pestov/status/924133915199119360"><code class="language-plaintext highlighter-rouge">swift-source-compat-suite</code></a>, where you can add your open source project to make sure new additions to Swift do not break source compatability.</p>
<p>The first swift evolution proposals (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md">SE-0186</a>) have been implemented in Swift 4.1, so this Swift version has been added to the <a href="https://apple.github.io/swift-evolution/">status page</a> now, <a href="https://github.com/apple/swift-evolution/pull/755">too</a>.</p>
<p>In Signapore, the government is teaching <a href="https://www.cnet.com/news/singapore-teaches-its-seniors-to-code/">seniors to write Swift</a> for the Hour of Code.</p>
<p>Slava’s fingers are itching to <a href="https://twitter.com/slava_pestov/status/925133908835835904">implement an <code class="language-plaintext highlighter-rouge">Either</code> type</a>. Soon™?</p>
<p>Chris Bailey announced <a href="https://developer.ibm.com/swift/2017/10/30/kitura-20/">Kitura 2.0</a>, IBM’s web framework for building Swift applications.</p>
<p>Paul Hudson introduced the Swift Community Awards a few weeks ago, and <a href="https://www.hackingwithswift.com/awards">the shortlist</a> is available. It includes <strong>this very newsletter</strong> as well as its podcast, <a href="https://spec.fm/podcasts/swift-unwrapped">Swift Unwrapped</a>. That’s quite the honor! Thanks for all of you who mentioned us, and feel free to vote and make it even more awesome! 😎</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Mark Lacey <a href="https://github.com/apple/swift/pull/12653">opened a pull request</a> that abolishes <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> (IUOs) completely - in Swift 5. You can test this (and more) in the development toolchain snapshots that Apple is sharing on <a href="https://swift.org/download/">Swift.org</a>. Go test and explore what’s coming in future versions of Swift!
It was first (partly) implemented in Swift 3 as part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054</a>.</p>
<p>Slava Pestov pitched a proposal on cross-module inlining and specialization by opening <a href="https://github.com/apple/swift-evolution/pull/754">a pull request</a> on swift-evolution, which would be another step towards Swift 5’s goal of reaching ABI stability.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040733.html">shared some thoughts</a> on Python interop in Swift.</p>
<blockquote>
<p>In short, I think we should build a simple Swift/Python interop story. This sort of thing has be built numerous times for many languages (owing to Python’s great support for embed-ability), including things like <code class="language-plaintext highlighter-rouge">PyObjC</code>, <code class="language-plaintext highlighter-rouge">boost.python</code>, and many others.</p>
<p>If we do this, the vast majority of the Python ecosystem should be directly usable from within Swift code, and there are only a few major syntactic differences (e.g. ranges work differently). We would add failable inits to the primitive datatypes like <code class="language-plaintext highlighter-rouge">Int</code>/<code class="language-plaintext highlighter-rouge">String</code>/etc to convert <code class="language-plaintext highlighter-rouge">Python.Object</code> values into them, and add the corresponding non-failable conversions from <code class="language-plaintext highlighter-rouge">Python.Object</code> to those primitives.</p>
<p>Overall, I think it will provide a really nice experience, and allow us to leverage the vast majority of the Python ecosystem directly in Swift code. This project would also have much more narrow impact on the Swift compiler than the ObjC importer (since it works completely differently). For a first cut, I don’t think we would have to worry about Swift classes subclassing Python classes, for example.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Joe Groff’s human was <a href="https://twitter.com/jckarter/status/925122252479148032">very, very prepared</a> for his talk at Swift Summit.</p>
Issue #92
https://swiftweeklybrief.com/issue-92
2017-10-26T00:00:00-07:00
2017-10-26T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Greetings! Hope you’re feeling a little rested from the week off and are ready to absorb Swift news again. There has been some interesting development activity at the main Swift repo over the past two weeks. Plus, two exciting themes have been covered by Swift Unwrapped. Enjoy the issue!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-6082">SR-6082</a>: Produce a better error message if Swift is run on a system without clang++</li>
<li><a href="https://bugs.swift.org/browse/SR-6102">SR-6102</a>: Improve <code class="language-plaintext highlighter-rouge">Sequence.elementsEqual</code> and <code class="language-plaintext highlighter-rouge">lexicographicallyPrecedes</code></li>
<li><a href="https://bugs.swift.org/browse/SR-6154">SR-6154</a>: Add support for <code class="language-plaintext highlighter-rouge">LLVM_REVERSE_ITERATION</code> and use it to uncover non-determinism</li>
<li><a href="https://bugs.swift.org/browse/SR-6207">SR-6207</a>: Misleading error for unqualified use of static variable in method</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/89166">Episode 33: HTTP server v0.1.0</a>: Jesse and JP discuss the first release of the HTTP server library from the Swift Server APIs project.</p>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/91615">Episode 34: Floating-Point</a>: JP and Jesse share their thoughts on numeric protocols and types, especially those of the floating point variety.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ted Kremenek <a href="https://swift.org/blog/swift-4-1-release-process/">posted</a> an article discussing the goals, release process, and estimated schedule for Swift 4.1. This release will be a source compatible update to Swift 4.0, but it will not be binary compatible. Swift 4.1 is intended to be released in the first half of 2018.</p>
<p>Andre Videla <a href="https://medium.com/@andre_videla/total-programming-in-swift-526508c12a74">posted</a> a discussion of how Swift encourages it’s totality. And there’s a <a href="https://twitter.com/clattner_llvm/status/918885734890663937">discussion</a> on Twitter.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> <a href="https://twitter.com/slava_pestov/status/922357520819134465">started</a> an interesting discussion on improvements to type checker performance in non-WMO builds of projects with many classes.</p>
<p>Harlan Haskins gave a great <a href="https://academy.realm.io/posts/improving-swift-tools-with-libsyntax-try-swift-haskin-2017/">talk</a> about the structure of libSyntax, design decisions behind it, and how to make use of it to analyze, generate, and transform Swift code.</p>
<p>It’s never too much to repeat the basics, especially in Swift. Ennio Masi <a href="https://medium.com/@EnnioMa/back-to-the-fundamentals-sorting-algorithms-in-swift-from-scratch-fccf8a3daea3">wrote</a> about popular sorting algorithms in pure Swift. 🤓</p>
<p>If you’re still doubting to use Swift - check <a href="https://medium.com/@guydaher/what-stats-and-surveys-are-saying-about-swift-in-2017-7e21dcce1f8b">these</a> stats and surveys. Swift’s position is stronger and stronger. 💪</p>
<p>The <a href="github.com/apple/swift/pull/9619">implementation</a> of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">SE-0185: Synthesizing Equatable and Hashable conformance</a> <a href="https://github.com/apple/swift/pull/9619#issuecomment-336746025">might go out</a> in “Swift 4.1” in early 2018. 🎉</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/gregomni">Greg Titus</a> and <a href="https://github.com/slavapestov">Slava Pestov</a> <a href="https://github.com/apple/swift/pull/12440">fixed</a> a crash when a statement in an <code class="language-plaintext highlighter-rouge">if let</code> referenced a binding defined later, for example <code class="language-plaintext highlighter-rouge">if let b = c, c = ...</code>.</p>
<p><a href="https://github.com/gspiers">Greg Spiers</a> <a href="https://github.com/apple/swift/pull/11744">implemented</a> the Swift Evolution <a href="https://github.com/apple/swift-evolution/pull/707">proposal</a> “Remove ownership keyword support in protocols” to remove support for <code class="language-plaintext highlighter-rouge">weak</code> and <code class="language-plaintext highlighter-rouge">unowned</code> keywords for property declarations in protocols.</p>
<p><a href="https://github.com/Kacper20">Kacper Harasim</a> <a href="https://github.com/apple/swift/pull/12281">fixed</a> <a href="https://bugs.swift.org/browse/SR-6051">SR-6051: Refactoring to expand missing switch cases from <code class="language-plaintext highlighter-rouge">switch</code> keyword</a> to provide cursor refactoring, when the cursor is anywhere on <code class="language-plaintext highlighter-rouge">switch</code> keyword lets a user to expand missing switch cases into code placeholders.</p>
<p><a href="https://github.com/xedin">Pavel Yaskevich</a> <a href="https://github.com/apple/swift/pull/12482">merged</a> improvements to mangling: improve handling of the variadic function parameters.</p>
<p><a href="https://github.com/rintaro">Rintaro Ishizaki</a> <a href="https://github.com/apple/swift/pull/12457">opened</a> pull request to fix <a href="https://bugs.swift.org/browse/SR-5869">SR-5869: trailing closure not parsed correctly in if-statement conditional</a>. The deal is: this fix allows users to write conditional statements with functions with trailing closures inside without parentheses. Before <code class="language-plaintext highlighter-rouge">if nums.filter ({ $0 % 2 == 0 }).isEmpty {</code>; after <code class="language-plaintext highlighter-rouge">if nums.filter { $0 % 2 == 0 }.isEmpty {</code>.</p>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> <a href="https://github.com/apple/swift/pull/12633">fixed</a> compiler crash <a href="https://bugs.swift.org/browse/SR-6100">SR-6100: Compilation hangs when catching error with associated value defined inside generic class/struct</a>.</p>
<p><a href="https://github.com/rudkx">Mark Lacey</a> <a href="https://github.com/apple/swift/pull/12631">opened</a> a pull request with an implementation of warning in case of type is spelled as <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> rather than <code class="language-plaintext highlighter-rouge">T!</code>. It seems <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054: Abolish ImplicitlyUnwrappedOptional type</a> will get a full implementation soon!</p>
<p><a href="https://github.com/CodaFi">Robert Widmann</a> <a href="https://github.com/apple/swift-evolution/pull/114">implemented</a> the pre-proposal <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006876.html">CaseEnumerable protocol (derived collection of enum cases)</a>.</p>
<p><a href="https://github.com/huonw">Huon Wilson</a> <a href="https://github.com/apple/swift/pull/12430">opened</a> a pull request that improves Swift Intermediate Language (SIL). Conditional conformances are inching closer and closer.</p>
<p><a href="https://github.com/allevato">Tony Allevato</a> <a href="https://github.com/apple/swift/pull/12598">opened</a> a pull request with improvements into synthesize of <code class="language-plaintext highlighter-rouge">Equatable</code>/<code class="language-plaintext highlighter-rouge">Hashable</code>: synthesis for fields/associated values that are tuples where all fields are <code class="language-plaintext highlighter-rouge">Equatable</code>/<code class="language-plaintext highlighter-rouge">Hashable</code>.</p>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> <a href="https://github.com/apple/swift/pull/12595">fixed</a> various regressions against the master branch.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week. As always, you can check out the <a href="https://apple.github.io/swift-evolution/">Swift Evolution status page</a> for all the details.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Xiaodi Wu <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171009/040362.html">pitched a draft proposal</a> at [swift-dev] to rename <code class="language-plaintext highlighter-rouge">Sequence.elementsEqual</code>.</p>
<blockquote>
<p>The current behavior of <code class="language-plaintext highlighter-rouge">Sequence.elementsEqual</code> is potentially confusing to
users given its name. Having surveyed the alternative solutions to this
problem, it is proposed that the method be renamed to
<code class="language-plaintext highlighter-rouge">Sequence.lexicographicallyEquals</code>.</p>
</blockquote>
<p>Xiaodi Wu <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20171016/005629.html">continued</a> the conversation about rationalizing <code class="language-plaintext highlighter-rouge">FloatingPoint</code> conformance to <code class="language-plaintext highlighter-rouge">Equatable</code> at [swift-dev].</p>
<blockquote>
<p>Regardless of whether or not
it is wise for the partial equivalence relation <code class="language-plaintext highlighter-rouge">FloatingPoint.==</code> to be
deemed as semantically satisfactory for the purposes of <code class="language-plaintext highlighter-rouge">Equatable</code>, the
fact remains that Swift deliberately ships with such a conformance, and
<code class="language-plaintext highlighter-rouge">Array.==</code> should not blow up given that explicitly contemplated design
decision. This PR resolves that proximal issue.</p>
</blockquote>
<p>Max Moiseev <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040609.html">started a discussion</a> about introducing a new standard sequence method: <code class="language-plaintext highlighter-rouge">Sequence.filteredMap(_:)</code>. Here’s the <a href="https://gist.github.com/moiseev/2f36376c8ef4c2b1273cff0bfd9c3b95">proposal draft</a>.</p>
<blockquote>
<p>We propose to deprecate the controversial version of a <code class="language-plaintext highlighter-rouge">Sequence.flatMap</code> method and provide the same functionality under a different, and potentially more descriptive, name.</p>
</blockquote>
<p>Slava Pestov <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171023/040641.html">pitched</a> an idea to deprecate <code class="language-plaintext highlighter-rouge">AnyObject</code> method dispatch.</p>
<blockquote>
<p>Dynamic dispatch of methods through <code class="language-plaintext highlighter-rouge">AnyObject</code> is a source of implementation complexity, has many known bugs which we are not going to fix, and no longer makes sense now in an id-as-Any world; <code class="language-plaintext highlighter-rouge">AnyObject</code> is not the ‘common currency’ type for arbitrary Objective-C objects anymore.</p>
<p>I would like to propose we deprecate it as follows:</p>
<ul>
<li>Unconditional warning in Swift 4.1, with a fixit to add an ‘as’ cast to cast the base value to the right type</li>
<li>Error in Swift 5 in -swift-version 5 mode</li>
</ul>
<p>Thoughts? Does anyone actually rely on this feature, instead of just stumbling on it by accident once in a while?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Are you feeling cold? <a href="https://twitter.com/llvmorg/status/920046402360696832">LLVM dragons</a> will warm you.</p>
Issue #91
https://swiftweeklybrief.com/issue-91
2017-10-12T00:00:00-07:00
2017-10-12T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Wow, it’s been quite the week! There has been a lot going on this week, and quite a few swift-evolution proposals have landed. And not the smallest ones either: what about Automatic <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance for example? Swift 4.1 is shaping up to be a great release that will make our lives even easier. 🏎💨</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p><a href="https://spec.fm/podcasts/swift-unwrapped/89162">Episode 32: Migrating to Swift 4</a>: JP and Jesse share their thoughts on the transition to Swift 4.</p>
<h3 id="news-and-community">News and community</h3>
<p>Kubra Mracek improved the display of fatal errors and wrote a blog post <a href="https://swift.org/blog/xcode-9-1-improves-display-of-fatal-errors/">on Swift.org</a> describing the changes. Now, you will see where and why a failure occurred, which is a big improvement to the previous ambiguous errors in the main function.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Tony Allevato’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">SE-0185: <em>Synthesizing <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance</em></a> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">was merged</a>! This is huge — it provides automatic <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance for types for whose members are all <code class="language-plaintext highlighter-rouge">Equatable</code> or <code class="language-plaintext highlighter-rouge">Hashable</code>. 😱🎉</p>
<p>Greg Spiers <a href="https://github.com/apple/swift/pull/11744">implemented</a> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md">SE-0186: <em>Remove ownership keyword support in protocols</em></a>.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/12397">opened a pull request</a> that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155: <em>Normalize Enum Case Representation</em></a>.</p>
<p>Javi Soto <a href="https://github.com/apple/swift/pull/12295">opened a pull request</a> to make <code class="language-plaintext highlighter-rouge">+new</code> unavailable when <code class="language-plaintext highlighter-rouge">-init</code> is too.</p>
<p>Doug Gregor made <a href="https://github.com/apple/swift/pull/12321">some more improvements</a> for type checking in the standard library. <a href="https://twitter.com/slava_pestov/status/916452691840241664">Another 16% speedup</a>!</p>
<p>David Ungar <a href="https://github.com/apple/swift/pull/12335">opened a pull request</a> to speed up compilation for full rebuilds in non-WMO (Whole Module Optimization) mode. And there’s <a href="https://twitter.com/senderPath/status/917270872209055744">more to come</a>!</p>
<p>Chris Lattner <a href="https://github.com/apple/swift/pull/12338">opened a pull request</a> with some small improvements to the optimizer.</p>
<p>Recursive protocol constraints are now available on <a href="https://twitter.com/AirspeedSwift/status/918159453467295744">the master toolchain</a>!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md">SE-0184</a>: <em>Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-October/000405.html">accepted with revisions</a>.</p>
<blockquote>
<p>It was a large proposal for which most parts received a lot of support, while other parts were contentious. The proposal is accepted with revisions:</p>
<ul>
<li>Partial initialization/assignment will be removed from this proposal and discussed separately</li>
<li>Some argument labels will be changed for clarity (<code class="language-plaintext highlighter-rouge">bytes</code> -> <code class="language-plaintext highlighter-rouge">byteCount</code>, <code class="language-plaintext highlighter-rouge">alignedTo</code> -> <code class="language-plaintext highlighter-rouge">alignment</code>)</li>
<li>The <code class="language-plaintext highlighter-rouge">count</code> argument to <code class="language-plaintext highlighter-rouge">deallocate()</code> will be removed entirely</li>
</ul>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md">SE-0186</a>: <em>Remove ownership keyword support in protocols</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-September/000404.html">accepted</a>.</p>
<blockquote>
<p>The proposal has been accepted.</p>
<p>Feedback for the proposal — which many interpreted as being mostly a compiler bug fix — was limited but unanimously positive. The consensus was that removing the support for these ownership keywords in protocols removes false expectations on their behavior, which could be a source of bugs.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171002/040261.html">pitched a proposal</a> to restrict cross-module struct initializers.</p>
<blockquote>
<p>While working on the non-exhaustive enums proposal I had it pointed out to me that structs actually currently leak implementation details across module boundaries, specifically their full set of stored properties. This only comes up in one place: when making an initializer for the struct in an extension in another module. We really want people to be able to change the stored properties in their structs between releases without it being a source break—that’s half the point of computed properties—and it’s also important for a struct author to be able to enforce invariants across the struct’s properties.</p>
</blockquote>
<p>There’s already a <a href="https://github.com/apple/swift-evolution/pull/753">proposal</a> and an <a href="https://github.com/apple/swift/pull/12352">initial implementation</a>.</p>
<h3 id="finally">Finally</h3>
<p>Chris Lattner is <a href="https://twitter.com/olebegemann/status/917710728194347009">back to square one</a>.</p>
Issue #90
https://swiftweeklybrief.com/issue-90
2017-10-05T00:00:00-07:00
2017-10-05T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>It’s been a while since I last wrote an issue, but I am glad to be writing another one. Especially after meeting JP at <a href="http://frenchkit.fr">FrenchKit</a> where we both gave a talk (JP did one on profiling Swift performance on Linux (<a href="https://speakerdeck.com/jpsim/performance-profiling-swift-on-linux">slides</a>), I did one on what we can expect from Swift 5 (<a href="https://speakerdeck.com/basthomas/whats-up-with-swift-5">slides</a>)). There will be videos, but we’ll have to wait a little longer for those.</p>
<p>Other than that, we are now less than a month away from the iPhone X! That means upgrading your apps sooner rather than later.</p>
<p>Have a great week!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p>There’s a starter task to <a href="https://bugs.swift.org/browse/SR-6055">check if a given map file exists when passing it as an argument</a>.</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/88491">Episode 31</a> Jesse and JP discuss compile times, looking at the ways you can profile and improve your compile times and some discussions on the mailing lists regarding the topic.</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple <a href="https://twitter.com/fchollet/status/915653994176954368">open sourced</a> their CoreML tools - and they’re open to contributions. 😱</p>
<p>The Swift HTTP server v0.1.0 is now <a href="https://twitter.com/Chris__Bailey/status/914925288240316416">available</a>! Go try it out and leave some feedback!</p>
<p>Chris Bailey <a href="https://github.com/swift-server/which_is_the_fastest">checked the speed</a> of the various Swift HTTP frameworks to check “which is the fastest?”.</p>
<p>Nate Cook <a href="https://swift.org/blog/dictionary-and-set-improvements/">wrote a blogpost</a> on the official Swift.org blog talking about the improvements (like <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md">SE-0165</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md">SE-0154</a>) made in <code class="language-plaintext highlighter-rouge">Dictionary</code> and <code class="language-plaintext highlighter-rouge">Set</code> in Swift 4. It contains some great examples (with emoji 👌).</p>
<p>Ted Kremenek is <a href="https://twitter.com/tkremenek/status/915229686740926465">looking for someone</a> to help him with project management on Swift. Maybe it’s you he’s looking for?! 🏎</p>
<p>Slava Pestov shared that Swift’s 5 goal of ABI stability also means he’s also <a href="https://twitter.com/slava_pestov/status/915110709209456640">able to do some cleanup</a> because of it. 💪</p>
<p>Doug Gregor’s improvements on generics sped up the type checking phase of the standard library <a href="https://twitter.com/slava_pestov/status/914594813697130496">by a whopping 300%</a>!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Kelvin Ma <a href="https://github.com/apple/swift/pull/12200">opened a pull request</a> that has an implementation for his <a href="https://github.com/kelvin13/swift-evolution/blob/improved-pointers/proposals/0184a-unsafe-pointers-part-1.md">proposal</a>. This implements part of the original proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md">SE-0184</a>.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/11923">implemented</a> one of the two proposals required for ABI stability, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157: <em>Support recursive constraints on associated types</em></a>. In the process, that <a href="https://twitter.com/slava_pestov/status/914729705827209216">removed more than 600 lines of code</a> in the standard library that were not needed anymore. <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md">1 to go</a>!</p>
<p>Roman Levenstein <a href="https://github.com/apple/swift/pull/12191">made some progress</a> on ABI stability - as well as cleaning up the compiler. 😎</p>
<p>Jordan Rose <a href="https://github.com/apple/swift-evolution/pull/751">opened a pull request</a> on <code class="language-plaintext highlighter-rouge">swift-evolution</code> to add non-exhaustive enums to Swift. It (obviously?) includes an <a href="https://github.com/apple/swift/pull/11961">implementation</a> too. Read <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038663.html">the pitch</a> for this proposal on the mailing lists.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/12174">opened a pull request</a> that fixes a one and a half year old <a href="https://bugs.swift.org/login.jsp?os_destination=%2Fplugins%2Fservlet%2Fmobile%23issue%2FSR-617">bug</a> related to the use of <code class="language-plaintext highlighter-rouge">Self</code> and <code class="language-plaintext highlighter-rouge">self</code>.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/11869">opened a pull request</a> to diagnose infinite recursion (recursion, recursion), fixing four SR-bugs in the process.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md">SE-0186</a>: <em>Remove ownership keyword support in protocols</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-September/000404.html">accepted</a>.</p>
<blockquote>
<p>Feedback for the proposal — which many interpreted as being mostly a compiler bug fix — was limited but unanimously positive. The consensus was that removing the support for these ownership keywords in protocols removes false expectations on their behavior, which could be a source of bugs.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Chris Lattner sent out an email discussing a metaproposal - a proposal on a proposal - to tackle <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170925/040009.html">refining identifier and operator symbology</a>.</p>
<blockquote>
<p><a href="https://github.com/xwu/swift-evolution/blob/7c2c4df63b1d92a1677461f41bc638f31926c9c3/proposals/NNNN-refining-identifier-and-operator-symbology.md">The proposal</a> correctly observes that the partitioning of unicode codepoints into identifiers and operators is a mess in some cases. It really is an outright bug for 🙂 to be an identifier, but ☹️ to be an operator. That said, the proposal itself is complicated and is defined in terms of a bunch of unicode classes that may evolve in the “wrong way for Swift” in the future.</p>
<p>The core team would really like to get this sorted out for Swift 5.</p>
<p>To make progress on this, we suggest a few separable steps:</p>
<p>First, please split out the changes to the ASCII characters to its own proposal [..]</p>
<p>Second, someone should take a look at the concrete set of unicode identifiers that are accepted by Swift 4 and write a new proposal that splits them into the three groups: those that are clearly identifiers (which become identifiers), those that are clearly operators (which become operators), and those that are unclear or don’t matter (these become invalid code points).</p>
<p>Third, if there is interest sometime in the future, we can have subsequent proposals that expand the range of accepted code points, motivated by the specific application domain that cares about them. These proposals will not be source breaking, so they can happen at any time.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>🎶 <a href="https://twitter.com/Catfish_Man/status/913922418833420289">Call me maybe?</a></p>
Issue #89
https://swiftweeklybrief.com/issue-89
2017-09-28T00:00:00-07:00
2017-09-28T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Welcome to the 89th issue of Swift Weekly Brief! This week was more calm, no news explosions. The repositories and mailing lists had their usual activity.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p>Starter tasks are a great way to get started with contributing to Swift. Ask questions directly in the bug reporting system, and get feedback when you submit your pull request.</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5996">SR-5996</a>: Improve compiler error with a fix-it: Cannot assign to value, <code class="language-plaintext highlighter-rouge">bar</code> is a <code class="language-plaintext highlighter-rouge">let</code> constant</li>
<li><a href="https://bugs.swift.org/browse/SR-5995">SR-5995</a>: <code class="language-plaintext highlighter-rouge">update-checkout --tags</code> should fetch –tags before attempting to find a tag</li>
<li><a href="https://bugs.swift.org/browse/SR-5983">SR-5983</a>: Unused result warning phrasing is worse for closures than normal functions</li>
<li><a href="https://bugs.swift.org/browse/SR-5982">SR-5982</a>: <code class="language-plaintext highlighter-rouge">didSet</code> causes unwanted calls to getter even when <code class="language-plaintext highlighter-rouge">oldValue</code> isn’t used</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/87409">Episode 30</a> Jesse and JP welcome Mike Ash to discuss weak references and the implementation changes that shipped in Swift 4.</p>
<h3 id="news-and-community">News and community</h3>
<p>There’s a (relatively) new addition to the Swift docs collection: <a href="https://github.com/apple/swift/blob/master/docs/StandardLibraryProgrammersManual.md">Standard Library Programmers Manual</a>, written by Michael Ilseman. <a href="https://twitter.com/olebegemann/status/913104239576182785">Thank Ole</a> for discovering this and sharing!</p>
<p>This week was Clang’s <a href="https://twitter.com/llvmorg/status/912724943221096448">10th anniversary</a>! 🎉 🎊</p>
<p>Mike Ash <a href="https://mikeash.com/pyblog/friday-qa-2017-09-22-swift-4-weak-references.html">wrote</a> a great Friday Q&A about the changes in Swift’s weak references implementation. (This is the post he discussed on Swift Unwrapped.)</p>
<blockquote>
<p>Weak references are an important language feature. Swift’s original implementation was wonderfully clever and had some nice properties, but also had some problems. By adding an optional side table, Swift’s engineers were able to solve those problems while keeping the nice, clever properties of the original. The side table implementation also opens up a lot of possibilities for great new features in the future.</p>
</blockquote>
<p><a href="https://medium.com/@ahmedsulaiman">Ahmed Sulaiman</a> wrote a descriptive blog post: <a href="https://medium.com/flawless-app-stories/debugging-swift-code-with-lldb-b30c5cf2fd49">Debugging Swift code with LLDB</a> about using lldb in general and some unpopular tricks with Swift debugging. Take this chance to enhance your debugging skills!</p>
<p>Russ Bishop <a href="https://twitter.com/xenadu02/status/911463433521860609">shared the problem</a> behind the Xcode 9 simulator’s very slow performance — surprising bug!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> opened <a href="https://github.com/apple/swift/pull/11923">a pull requests</a> that implements the standard library part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>: <em>Recursive Protocol Constraints</em>.</p>
<p><a href="https://github.com/jckarter">Joe Groff</a> <a href="https://github.com/apple/swift/pull/12112">fixed</a> a compiler crash in the case where code captured <em>[weak self]</em> in a closure inside a class method returning <em>dynamic</em> <code class="language-plaintext highlighter-rouge">Self</code>.</p>
<p><a href="https://github.com/jrose-apple">Jordan Rose</a> <a href="https://github.com/apple/swift/pull/12101">merged a pull request</a> for a Swift compiler crash fix where Swift didn’t handle cases of Objective-C inheritance from a <code class="language-plaintext highlighter-rouge">typedef</code> for a class/protocol composition as shorthand for inheriting from the class and adopting the protocol.</p>
<p><a href="https://github.com/phausler">Philippe Hausler</a> <a href="https://github.com/apple/swift/pull/11939">merged</a> great improvements to Data slices. This change fixes <a href="SR-5887">SR-5887</a>, <a href="https://bugs.swift.org/browse/SR-5873">SR-5873</a> and <a href="https://bugs.swift.org/browse/SR-5810">SR-5810</a>.</p>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> merged a <a href="https://github.com/apple/swift/pull/12097">pull request</a> for caching name lookup for nested types of generic types through the equivalence class.</p>
<p><a href="https://github.com/compnerd">Saleem Abdulrasool</a> <a href="https://github.com/apple/swift/pull/12136">merged</a> changes to allow building the stdlib on Windows ARM.</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> <a href="https://github.com/apple/swift/pull/12030">merged</a> a preliminary implementation of a code completion fuzzer. And guess what, it’s written in Swift! 😎</p>
<p><a href="https://github.com/Kacper20">Kacper Harasim</a> <a href="https://github.com/apple/swift/pull/12128">implemented</a> a new refactoring action to convert <code class="language-plaintext highlighter-rouge">do</code>/<code class="language-plaintext highlighter-rouge">catch</code> statements to <code class="language-plaintext highlighter-rouge">try!</code>. (<a href="https://bugs.swift.org/browse/SR-5743">SR-5743</a>)</p>
<p><a href="https://github.com/milseman">Michael Ilseman</a> <a href="https://github.com/apple/swift/pull/12115">opened a pull request</a> with a prototype implementation for new String comparison.</p>
<p><a href="https://github.com/Kacper20">Kacper Harasim</a> <a href="https://github.com/apple/swift/pull/12123">merged</a> a pull request with improvements to the local refactoring library.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week. As always, you can check out the <a href="https://apple.github.io/swift-evolution/">Swift Evolution status page</a> for all the details.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ben Cohen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170925/039944.html">revived</a> a pitch to add a <code class="language-plaintext highlighter-rouge">remove(where:)</code> function to the Standard Library. You can <a href="https://github.com/airspeedswift/swift-evolution/blob/0f4a24d6ded2ab7cb39c1a68e0f92705a7615d73/proposals/NNNN-RemoveWhere.md">check out</a> a proposal draft and join the discussion.</p>
<blockquote>
<p>It is common to want to remove all occurrences of a certain element from a collection. This proposal is to add two in-place <code class="language-plaintext highlighter-rouge">remove</code> algorithms to the standard library, which will remove all entries in a collection in-place matching either an <code class="language-plaintext highlighter-rouge">Equatable</code> value, or match that a certain criteria.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Finally — tl;dr <a href="https://github.com/apple/swift/pull/11939#issue-257913935">slicing a CoW should result in fillet mignon not ground chuck.</a></p>
Issue #88
https://swiftweeklybrief.com/issue-88
2017-09-21T00:00:00-07:00
2017-09-21T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Swift 4.0 is finally here! So now everyone can relax, right? 😅 Ha. ABI Stability isn’t going to implement itself! 😆 There’s a lot of work ahead. We saw some progress here this week with Jordan Roses’s proposal on non-exhaustive enums. Also, there were some improvements to KeyPaths and the start to recursive protocol constraints.</p>
<p>Swift 4 landed along with Xcode 9, iOS 11, tvOS 11, and watchOS 4. This only leaves macOS High Sierra, which will be out in a few days. Good lucking with migrating your code bases if you haven’t started already. Over at <a href="https://medium.com/plangrid-technology">PlanGrid</a>, we decided to move to Swift 3.2 during the betas and move to Swift 4.0 after the final release. I have a work-in-progress branch doing the migration now and it’s not too bad, but definitely not trivial.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/86442">Episode 29</a> we discuss some recent Swift Evolution proposals, Xcode 9 GM, along with a boatload of follow-ups from Ted Kremenek and Pierre Habouzit.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ted Kremenek published <a href="https://swift.org/blog/swift-4-0-released/">the official Swift 4.0 announcement</a> on the Swift.org blog. Congrats to <a href="https://oleb.net">Ole Begemann</a> for getting a shout out in the opening paragraphs!</p>
<blockquote>
<p>Swift 4 is now officially released! Swift 4 builds on the strengths of Swift 3, delivering greater robustness and stability, providing source code compatibility with Swift 3, making improvements to the standard library, and adding features like archival and serialization.</p>
<p>You can watch a quick overview of it by watching the <a href="https://developer.apple.com/videos/play/wwdc2017/402/">WWDC 2017: What’s New in Swift</a> presentation, and try out some of the new features in this <a href="https://github.com/ole/whats-new-in-swift-4">playground</a> put together by Ole Begemann.</p>
</blockquote>
<p>Mike Ash has a great post on <a href="https://plausible.coop/blog/2017/09/13/best-new-features-in-swift-4">The Best New Features in Swift 4</a>, in case you forgot. 😆</p>
<p>Brian Gesiak continued his Swift compiler series with <a href="https://modocache.io/reading-and-understanding-the-cmake-in-apple-swift"><em>Reading and Understanding the CMake in apple/swift</em></a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/11730">merged</a> his work on KeyPath subscripts. (<a href="https://twitter.com/jckarter/status/908787192327135232">Tweet</a>)</p>
<p>Doug Gregor opened a <a href="https://github.com/apple/swift/pull/11923">pull request</a> to implement the standard library part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>: <em>Recursive Protocol Constraints</em>.</p>
<p>Calvin Hill <a href="https://github.com/apple/swift/pull/11583">added</a> initial platform support for building swiftc and the stdlib on <a href="https://download.haiku-os.org">64bit Haiku OS</a>, which I assume is <a href="https://gregheo.com">Greg Heo’s</a> favorite operating system. 😆 Anyway, this brings Swift one step closer to world domination.</p>
<p>Will T. Ellis <a href="https://github.com/apple/swift/commit/57454eb8c9ad01668309c978ec0cc8976af6d443">added</a> a refactoring action to collapse nested <code class="language-plaintext highlighter-rouge">if</code> statements into a single <code class="language-plaintext highlighter-rouge">if</code> statement. (<a href="https://bugs.swift.org/browse/SR-5739">SR-5739</a>) This is the <a href="https://twitter.com/xge_apple/status/909920319766278145"><em>first</em> external contribution</a> to the Swift local refactoring tools. 🎉</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/11984">eliminated</a> the last direct use of <code class="language-plaintext highlighter-rouge">Builtin.UnknownObject</code>. <em>“At the Swift level, this is equivalent to AnyObject, which we’ve done much more testing of. This commit paves the way for taking UnknownObject out of the SIL type system and just using it as type metadata.”</em></p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/12015">wrote a script</a> to generate random type definitions. The intent is to use this to generate input for fuzzing runtime layout, ABI compatibility, layout algorithms, and more. Unfortunately, it was written in Python, <a href="https://twitter.com/jckarter/status/910513257626005504">not Swift</a>.</p>
<p>Amr Aboelela opened a <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/302">pull request</a> for corelibs-libdispatch that adds a <code class="language-plaintext highlighter-rouge">build-android</code> script, which will build libdispatch for Android.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0186-remove-ownership-keyword-support-in-protocols.md">SE-0186</a>: <em>Remove ownership keyword support in protocols</em> by Greg Spiers is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-September/000403.html">under review</a>.</p>
<blockquote>
<p>This proposal removes support for the keywords <code class="language-plaintext highlighter-rouge">weak</code> and <code class="language-plaintext highlighter-rouge">unowned</code> for property declarations in a protocol.</p>
<p>Currently it’s possible to use the weak/unowned keywords for a property requirement in a protocol. This can lead to confusion as specifying one of these keywords does not enforce or raise any warnings in the adopting type of that protocol…</p>
</blockquote>
<h3 id="proposal-drafts">Proposal drafts</h3>
<p>Jordan Rose drafted a proposal for <a href="https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/nnnn-non-exhaustive-enums.md">non-exhaustive enums</a>. You can find the work-in-progress <a href="https://github.com/apple/swift/pull/11961">implementation here</a>. Determining how to address and design this is one part of Swift’s ABI stability story.</p>
<blockquote>
<p>Currently, adding a new case to an enum is a source-breaking change, which is very inconvenient for library authors. This proposal aims to distinguish between enums that are exhaustive (meaning they will never get any new cases) and those that are non-exhaustive, and to ensure that clients handle any future cases when dealing with the latter. This change only affects clients from outside the original module.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-September/000402.html">announced</a> Swift 4.0.</p>
<blockquote>
<p>I am pleased to announce that Swift 4.0 has been <a href="https://swift.org/blog/swift-4-0-released/">officially released</a>.</p>
<p>Swift 4 is available in Xcode 9 (which went live on the Mac App Store earlier today) and we will be posting an official toolchain shortly as well (likely early tomorrow morning).</p>
<p>Official builds have been posted for Linux (Ubuntu 16.10, Ubuntu 16.04 and Ubuntu 14.04). For those of you downloading the Linux builds, please note that there is a new signing key (search for ‘Swift 4.x Release Signing Key’) on the <a href="ttps://swift.org/download/">downloads page</a></p>
<p>Thank you to everyone who contributed to making this release happen!</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/modocache/status/910288511223390209">artificial intelligence, 5 cents</a>.</p>
Issue #87
https://swiftweeklybrief.com/issue-87
2017-09-14T00:00:00-07:00
2017-09-14T00:00:00-07:00
Greg Heo
https://twitter.com/gregheo
https://github.com/gregheo.png?size=100
gregheo
<blockquote>
<p>Foundation improvements, no longer a fable<br />
Resilience and ownership, back on the table<br />
Swift 4 is now live<br />
Let’s look to Swift 5<br />
The primary goal: get that ABI stable<br /></p>
</blockquote>
<p>It was iPhone hardware day this week, but don’t forget about the software side of things — <a href="https://developer.apple.com/download/">iOS 11, Xcode 9, and Swift 4 GM releases</a> all available on the developer portal.</p>
<p>But you’ve decided to stop refreshing the Apple Store web site and have found your way here…welcome! Let’s get into the Swift news.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://plausible.coop/training/corporate?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_87" target="_blank">Take your development team to the next level</a></h4>
<p>Plausible’s corporate training programs will teach your team new skills and new technologies. Choose from Introduction to Swift, Intermediate Swift, or a fully customized course, all of which are tailored to fit your team’s needs and lead by world renowned guy and occasional Swift expert Mike Ash.</p>
<p><small><a href="https://plausible.coop/training/corporate?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_87" target="_blank">plausible.coop</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<p>Starter tasks are a great way to get started with contributing to Swift. Ask questions right in the bug reporting system, and get feedback when you submit your pull request.</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5856">SR-5856</a>: Error claims a protocol is a generic type, but no generics are used</li>
<li><a href="https://bugs.swift.org/browse/SR-5457">SR-5457</a>: Specific error message when user tries to compile Swift executable</li>
<li><a href="https://bugs.swift.org/browse/SR-5337">SR-5337</a>: Improve diagnostic for ‘var’ in parameter position</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/85798">episode 28 of Swift Unwrapped</a>, JP and Jesse discuss the Clang & Swift refactoring engines and how you shouldn’t be afraid of C++ code.</p>
<h3 id="news-and-community">News and community</h3>
<p>Xcode 9 is out, with both Swift 3.2 and Swift 4.0 support! 🎉 Check out the <em>Swift Language</em> section of the Xcode 9 GM release notes while you’re waiting for your <a href="https://developer.apple.com/download/">download</a> to complete.</p>
<p>The 11th annual US LLVM Developers’ Meeting is coming up on October 18, and the <a href="https://llvm.org/devmtg/2017-10/">list of accepted talks</a> is available. Something to look forward to if you’re interested in the compiler level or curious about <a href="https://llvm.org/devmtg/2017-10/#talk15">implementing Swift generics</a>?</p>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a> published <a href="https://modocache.io/the-swift-compilers-build-system">The Swift Compiler’s Build System</a>, the second post in his ongoing series <a href="http://modocache.io/getting-started-with-swift-development">Getting Started with Swift Compiler Development</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Here’s one from the archives: you may know that an optional is an <code class="language-plaintext highlighter-rouge">enum</code> behind the scenes, but did you know optionals used to be arrays that were either empty or holding a single element? Take a trip in the wayback machine: here’s <a href="https://github.com/apple/swift/commit/9e0ecddfb9e0aacab537ff2a4299b5f209e845d9#diff-a9c187958304db124979ee946128cfa5R72">the commit from 2013</a> and associated <a href="https://twitter.com/jckarter/status/907342743499714560">Twitter conversation</a>.</p>
<p><a href="https://github.com/milseman">Michael Ilseman</a> landed a cherry pick to fix mutating the various <code class="language-plaintext highlighter-rouge">String</code> views with <code class="language-plaintext highlighter-rouge">popFirst</code> in Swift 3.2. This is a great example of <a href="https://github.com/apple/swift/pull/11806/files">a small targeted fix with unit tests</a>, and as someone who enjoys reading code I think it’s a great example of working on the standard library.</p>
<p><a href="https://github.com/moiseev">Max Moiseev</a> landed an interesting change to the <code class="language-plaintext highlighter-rouge">BinaryInteger</code> protocol <a href="https://github.com/apple/swift/pull/11731">to speed up performance of accessing arbitrary words within an integer</a>. It’s great to see the attention to detail the Swift team spends looking at performance. 🙏</p>
<p><a href="https://github.com/DougGregor">Doug Gregor</a> opened <a href="https://github.com/apple/swift/pull/11899">a pull request</a> to implement more of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>: <em>Support recursive constraints on associated types</em>. The bug report <a href="https://bugs.swift.org/browse/SR-3453">SR-3453</a> has all the details and links to the previous pull requests on this feature.</p>
<h3 id="swift-evolution-proposals">Swift Evolution Proposals</h3>
<p>The review period for <a href="(https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md)">SE-0184</a>: <em>Unsafe[Mutable][Raw][Buffer]Pointer]</em> is over, and we’re still waiting for the official results.</p>
<p>You can review the status of all proposals on <a href="https://apple.github.io/swift-evolution/">the Swift Evolution status page</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>As part of his research, <a href="https://twitter.com/modocache">Brian Gesiak</a> asked about the history of the Swift project’s build system. Check out his <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170904/005296.html">original post with timeline</a> and the ensuing thread for all the details.</p>
<p>Alejandro Alonso opened up discussion on <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039605.html">unifying the concept of random number generation in Swift</a>. In addition to the original post and thread, there’s a gist with some ideas on what <a href="https://gist.github.com/Azoy/5d294148c8b97d20b96ee64f434bb4f5">the end API might look like</a>.</p>
<p>Logan Shire posted about <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039598.html">some common issues when working with enumerations</a>: needing to iterate through all options, and getting a count of cases. Follow the rest of the thread for some discussion on <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039601.html">why you might need these features</a> and how they might be implemented.</p>
<p>Get a real life behind-the-scenes peek at Swift engineers discussing <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170911/005321.html">coroutines, ABI stability, and stack vs heap</a> over two hours.</p>
<h3 id="finally">Finally</h3>
<p>Q: What color would Chris Lattner paint the <a href="https://en.wiktionary.org/wiki/bikeshedding">bikeshed</a>? 🎨</p>
<p>A: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170904/039672.html">Resilience</a>.</p>
Issue #86
https://swiftweeklybrief.com/issue-86
2017-09-07T00:00:00-07:00
2017-09-07T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Welcome back to the weekly! The Swift project repos continue to delight with their usual activity. This week we have some new starter tasks, updates on proposals, and most excitingly, Chris Lattner’s appearance on Swift Unwrapped to talk about concurrency in Swift 5.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5832">SR-5832</a>: Eliminate curried function representation from ASTs</li>
<li><a href="https://bugs.swift.org/browse/SR-5819">SR-5819</a>: Suggest <code class="language-plaintext highlighter-rouge">as? AnyHashable</code> when <code class="language-plaintext highlighter-rouge">as? Equatable</code> or <code class="language-plaintext highlighter-rouge">as? Hashable</code> is attempted</li>
<li><a href="https://bugs.swift.org/browse/SR-5817">SR-5817</a>: Swift CMake prints “Building Swift standard library and SDK overlays” and “Building Swift runtime”, even when those are <em>not</em> being built</li>
<li><a href="https://bugs.swift.org/browse/SR-5789">SR-5789</a>: Fixit when failed reference to member named <code class="language-plaintext highlighter-rouge">subscript</code> could refer to subscript declaration</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In Episode 27: <a href="https://spec.fm/podcasts/swift-unwrapped/84323">Concurrency with Chris Lattner</a>, JP and Jesse welcome Chris Lattner to the show to discuss concurrency in Swift 5 and beyond.</p>
<h3 id="news-and-community">News and community</h3>
<p>LLVM 5.0.0 version <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-September/117136.html">is complete</a> and marked as final. In a few days it will be published on <a href="http://releases.llvm.org">LLVM’s web-page</a>.</p>
<p><a href="https://gregheo.com">Greg Heo</a> published an article called <a href="https://swiftunboxed.com/lang/optionals-map-flatmap/">“The Strange Case Of Mapping Over Optionals”</a> at Swift Unboxed. Greg describes the differences in using <code class="language-plaintext highlighter-rouge">map</code> and <code class="language-plaintext highlighter-rouge">flatMap</code> with optionals and collections, and explains what types are returned after applying <code class="language-plaintext highlighter-rouge">map</code> or <code class="language-plaintext highlighter-rouge">flatMap</code> and why.</p>
<p>Vincent Benony wrote an <a href="https://www.hopperapp.com/blog/?p=219">article</a> on the <a href="https://www.hopperapp.com/blog/">Hopper Disassembler blog</a> about injecting methods in Swift at runtime. If you really need this, this article might help you.</p>
<p>Mike Ash took a closer look at Swift’s error handling in another great <a href="https://www.mikeash.com/pyblog/friday-qa-2017-08-25-swift-error-handling-implementation.html">Friday Q&A</a>, exploring the similarity and differences with exceptions.</p>
<p>Jordan Rose wrote a great post about <a href="http://belkadan.com/blog/2017/09/Over-abstraction/">Over-abstraction in Swift</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/gspiers">Greg Spiers</a> <a href="https://github.com/apple/swift-evolution/pull/707">pushed</a> draft proposal about <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036495.html">Ownership on protocol property requirements</a> and provided a <a href="https://github.com/apple/swift/pull/11744">draft implementation</a>.</p>
<p><a href="https://github.com/nkcsgexi">Xi Ge</a> <a href="https://github.com/apple/swift/pull/11711/files">implemented</a> a refactoring action to simplify long number literal format. (<a href="https://bugs.swift.org/browse/SR-5746">SR-5746</a>)</p>
<p><a href="https://github.com/modocache">Brian Gesiak</a> opened a <a href="https://github.com/apple/swift/pull/11703">pull request</a> to link static libraries as PUBLIC in CMake, but Jordan Rose <a href="https://github.com/apple/swift/pull/11703#pullrequestreview-59910998">commented</a> that not doing this was deliberate. The thread on the pull request is interesting if you’d like to learn more about CMake and the Swift intra-compiler infrastructure.</p>
<p><a href="https://github.com/jckarter">Joe Groff</a> <a href="https://github.com/apple/swift/pull/11730">opened</a> a work-in-progress pull request to support key path subscripts.</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> opened a <a href="https://github.com/apple/swift/pull/11786">pull request</a> to fix confusing redundant constraints for generated interfaces of the form <em>protocol P : AnyObject</em>.</p>
<p><a href="https://github.com/krilnon">Kyle Murray</a> implemented an <a href="https://github.com/apple/swift-evolution/pull/747">improvement</a> for <a href="http://apple.github.io/swift-evolution/">proposals status page</a>. Since all proposals are now required to have an implementation, the status page should show a link to those implementations.</p>
<h3 id="proposal-updates">Proposal updates</h3>
<p>Robert Widmann is <a href="https://github.com/CodaFi/swift/pull/5">working on</a> an implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155</a> <em>Normalize Enum Case Representation</em>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a> <em>Adding a Build Configuration Import Test</em> is <a href="https://github.com/apple/swift-evolution/commit/087d3fa5034719e3c3e5076bcec9af80af04c319">implemented</a> in Swift 4.1.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md">SE-0183</a> <em>Substring performance affordances</em> is <a href="https://github.com/apple/swift-evolution/commit/f19236c66a4e1a3d1c6914e6f21c871b40d3329e">implemented</a> in Swift 4.0.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a> <em>Protocol-oriented integers</em> is <a href="https://github.com/apple/swift-evolution/commit/abe20baea443b7aa7ffe22a4d1202df442d9a434">implemented</a> in Swift 4.0.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-unsafe-pointers-add-missing.md">SE-0184</a>: <em>Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size</em> by Kelvin Ma is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-September/000401.html">under review</a>.</p>
<blockquote>
<p>Swift’s pointer types are an important interface for low-level memory manipulation, but the current API design is not very consistent, complete, or convenient.</p>
<p>This proposal seeks to improve the Swift pointer API by ironing out naming inconsistencies, adding sensible default argument values, adding missing methods, and reducing excessive verbosity, offering a more convenient, more sensible, and less bug-prone API. We also attempt to introduce a buffer pointer API that supports partial initialization without excessively compromising memory state safety.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Joe Groff sent an <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039349.html">email</a> to resume discussions about an <code class="language-plaintext highlighter-rouge">async</code> coroutines implementation in Swift.</p>
<blockquote>
<p>The coroutine proposal as it stands essentially exposes raw delimited continuations. While this is a flexible and expressive feature in the abstract, for the concrete purpose of representing asynchronous coroutines, it provides weak user-level guarantees about where their code might be running after being resumed from suspension, and puts a lot of pressure on APIs to be well-behaved in this respect. And if we’re building toward actors, where async actor methods should be guaranteed to run “in the actor”, I think we’ll <em>need</em> something more than the bare-bones delimited continuation approach to get there. I think the proposal’s desire to keep coroutines independent of a specific runtime model is a good idea, but I also think there are a couple possible modifications we could add to the design to make it easier to reason about what context things run in for any runtime model that benefits from async/await […]</p>
</blockquote>
<p><a href="https://twitter.com/steipete/status/902247491235717121">Peter Steinberger</a> discovered an older thread about the problems of implicit conversion in an <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170612/004776.html">email from John McCall</a>, “RFC: bridging peephole for as casts”:</p>
<blockquote>
<p>So, there’s a longstanding issue that we’re planning to fix in Swift 4, and I want to both make sure that the plan is documented publicly and give people a chance to disagree with it.</p>
<p>A bridging conversion is a conversion between a Swift type and a foreign type (C / ObjC / whatever) which can represent the same set of values. For example, there are bridging conversions from Swift.String to ObjC’s NSString and vice-versa. When there two-way conversions like this, we say that the Swift type is bridged to the foreign type.</p>
<p>Bridging conversions are performed for three reasons in Swift:</p>
<ol>
<li>
<p>You can always request a bridging conversion with an unconditional “as” cast. For example, if myString is a String, you can convert it to NSString by writing “myString as NSString”.</p>
</li>
<li>
<p>Certain bridging conversions can be introduced as implicit conversions. (This is perhaps a mistake.) For example, CFString and NSString are considered different types, but they will implicitly convert to each other.</p>
</li>
<li>
<p>Bridging conversions are done “behind the scenes” when using an imported declaration that has been given a type that does not match its original type. For example, an Objective-C method that returns an NSString will be imported as returning a String; Swift will implicitly apply a bridging conversion to the true return value in order to produce the String that the type system has promised.</p>
</li>
</ol>
<p>[…]</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/modocache/status/905521640112615425">for your next whiteboarding interview</a>. 😂</p>
Issue #85
https://swiftweeklybrief.com/issue-85
2017-08-31T00:00:00-07:00
2017-08-31T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Welcome to issue 85! This week was quieter than last, but various discussions on concurrency continued. Proposal SE-0184: <em>Improved pointers</em> was updated and is waiting to get merged back into the swift-evolution repository.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/84324">Episode 26: Swift 5 Goals</a>, Jesse and JP share their thoughts on the newly announced goals for Swift 5.</p>
<h3 id="news-and-community">News and community</h3>
<p>A <a href="https://twitter.com/NachoSoto/status/874336844757975040">discussion</a> came up regarding problems with diagnostics and the “tuple-splat” changes in Swift 4. There’s definitely a lot of frustration in the community here. Swift certainly has <a href="https://bugs.swift.org/browse/SR-5198">room to improve</a> on diagnostics and error messages to make migrating from Swift 3 to Swift 4 smoother.</p>
<p>Brian Gesiak <a href="https://twitter.com/modocache/status/903091561457700865">generated a graph</a> of the Swift compiler executable and its dependencies. 🤓</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/CodaFi">Robert Widmann</a> opened <a href="https://github.com/apple/swift/pull/11613">a pull request</a> with an implementation for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>, which was originally accepted for Swift 3. 😅</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> <a href="https://github.com/apple/swift/pull/11637">fixed</a> an issue where calling a protocol extension initializer from a class convenience initializer would incorrectly use the static <code class="language-plaintext highlighter-rouge">Self</code> type rather than the dynamic type. Note that <strong>this is a source-breaking change for Swift 5.</strong> Also, it appears corelibs-foundation was relying on that bug, so he <a href="https://github.com/apple/swift-corelibs-foundation/pull/1191">proposed</a> a fix there as well.</p>
<p>Currently the mangled names for subscripts include “subscript”, for example <code class="language-plaintext highlighter-rouge">_T04main3FooC9subscriptAA6OutputVAA5InputVci</code>. <a href="https://github.com/ahoppen">Alex Hoppen</a> <a href="https://github.com/apple/swift/pull/11283">opened</a> a pull request request to fix this, which makes subscript mangled names more consistent with others. (<a href="https://bugs.swift.org/browse/SR-5506">SR-5506</a>)</p>
<p><a href="https://github.com/jrose-apple">Jordan Rose</a> merged two pull requests: <a href="https://github.com/apple/swift/pull/11504#issuecomment-325472480">Excise “Accessibility” from the compiler</a> and <a href="https://github.com/apple/swift-lldb/pull/250/files">Update for Swift renames of “Accessibility” to “Access(Level)”</a>. It’s a cosmetic change, but 100% justified. This definitely makes the code more readable and easier to understand from an app developer perspective.</p>
<blockquote>
<p>“Accessibility” has a different meaning for app developers, so we’ve already deliberately excised it from our diagnostics in favor of terms like “access control” and “access level”.</p>
</blockquote>
<p><a href="https://github.com/eeckstein">Erik Eckstein</a> <a href="https://github.com/apple/swift/pull/11675">fixed</a> an issue which can crash the compiler when a global struct or tuple has one or more elements as an empty type (e.g. an empty tuple or empty struct).</p>
<p>Erik Eckstein also <a href="https://github.com/apple/swift/pull/11537">merged</a> optimizations that give significant performance improvements for large array literals.</p>
<p><a href="https://github.com/kelvin13">Kelvin Ma</a> opened a <a href="https://github.com/apple/swift-evolution/pull/744">pull request</a> with updated version of SE-0184: <em>Improved pointers</em>.</p>
<p><a href="https://github.com/johnno1962">John Holdsworth</a> opened a <a href="https://github.com/apple/swift-corelibs-xctest/pull/200">pull request</a> to get XCTest building on Android.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates this week! See the <a href="http://apple.github.io/swift-evolution/">status page here</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Adam Kemp started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039280.html">discussion</a> on the scope of the <code class="language-plaintext highlighter-rouge">await</code> keyword to clarify how exactly <code class="language-plaintext highlighter-rouge">await</code> is applied in case there are several functions calls in one line. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039306.html">From Chris Lattner</a>:</p>
<blockquote>
<p>Yes, this is a reasonable concern. We debated it heavily in the Swift 2 timeframe when introducing error handling (as other’s have pointed out, it works the same way).</p>
<p>This is a tradeoff between the readability benefits of marking non-obvious control flow vs the readability disadvantage of having noise in the code. Requiring marking on every async or throwing call is particularly bad in the case of chaining.</p>
<p>[….]</p>
<p>In the Swift 2 timeframe, we decided that in many cases, it is mostly obvious what APIs can throw, so one marker is enough. That said, there ARE potentially confusing cases, and some programmers may want to be more explicit about marking. This is why the compiler allows you to explicitly mark subexpressions if you’d like.</p>
<p>I believe that this design has served the community well, and I haven’t heard of serious problems with it. I’m pretty confident that async following the same model will have similar success.</p>
</blockquote>
<p>Howard Lovatt discussed <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170828/039296.html">reactive streams as building blocks for actors</a>.</p>
<blockquote>
<p>Many of the currently popular server side frameworks are switching to <a href="http://en.wikipedia.org/wiki/Reactive_Streams#Adoption">Reactive Streams</a> for their underlying communication, including Akka. Reactive Streams are also to become builtin to Java, as the Flow class, in version 9.</p>
<p>Would it be wise if Swift 5 also builtin Reactive Stream protocols and built its Actor implementation etc. on top of this protocol?</p>
</blockquote>
<p>Chris Lattner added this in a new “<a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782#further-extensions">Further extensions</a>” section of the Concurrency Manifesto. So maybe we’ll get this some day!</p>
<p>Logan Shire <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039186.html">pitched an idea</a> for improvements to <code class="language-plaintext highlighter-rouge">KeyPath</code>.</p>
<blockquote>
<p>Firstly, <code class="language-plaintext highlighter-rouge">KeyPath</code> does not provide the name of the property on the type it indexes. […] But once I have a keyPath, I can’t actually figure out what property it accesses.</p>
<p>[…]</p>
<p>All I want is to be able to access: <code class="language-plaintext highlighter-rouge">keyPath.propertyName</code> […]</p>
<p>Also, if I want to get all of the attributes from a given Swift type, my options are to try to hack
something together with Mirrors, or forcing the type to declare a function / computed property
returning an array of all of its key path / property name pairings. I would really like to be able to
retrieve a type-erased array of any type’s key paths…</p>
<p>And finally, without straying too far into Objective-C land, it would be nice if we could initialize key paths with a throwing initializer…</p>
</blockquote>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170821/039231.html">was supportive</a>:</p>
<blockquote>
<p>These would all be great additional features to eventually add to key paths. I think reflection mechanisms centered on key paths like what you describe would be a superior replacement for most of what Mirror attempts to provide.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally, <a href="https://twitter.com/modocache/status/902618510966349829">me before reading <code class="language-plaintext highlighter-rouge">swift/utils/build-script --help</code> vs me after</a>.</p>
Issue #84
https://swiftweeklybrief.com/issue-84
2017-08-24T00:00:00-07:00
2017-08-24T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>What a surprisingly exciting week! Discussions on Swift’s concurrency story (for Swift 5) have started with a new manifesto and proposal for <code class="language-plaintext highlighter-rouge">async</code> / <code class="language-plaintext highlighter-rouge">await</code>, and the new refactoring tools were open sourced with a blog post explaining how do implement your own refactoring actions. There’s a lot of exciting work ahead!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p>If you’re interested in contributing to Xcode 9’s brand new <a href="https://swift.org/blog/swift-local-refactoring/">refactoring tools</a>, here are <a href="https://bugs.swift.org/browse/SR-5746?jql=labels%3DStarterProposal%20AND%20labels%3DRefactoring%20AND%20resolution%3DUnresolved">a handful of tasks</a> for implementing new refactoring actions.</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 25: <a href="https://spec.fm/podcasts/swift-unwrapped/82593">ABI Stability — Calling Convention, Runtime and Standard Library</a>. In the fourth and final episode in our series on ABI Stability, we cover the remaining categories of decisions that must be made to stabilize the ABI.</p>
<h3 id="news-and-community">News and community</h3>
<p>Xi Ge wrote an excellent post on the Swift.org blog, <a href="https://swift.org/blog/swift-local-refactoring/">Swift Local Refactoring</a>. The post not only describes how the refactoring tools work, but provides walk-throughs on how to implement new actions yourself!</p>
<blockquote>
<p>Xcode 9 includes a brand new refactoring engine. It can transform code locally within a single Swift source file, or globally, such as renaming a method or property that occurs in multiple files and even different languages. The logic behind local refactorings is implemented entirely in the compiler and SourceKit, and is now open source in the swift repository. Therefore, any Swift enthusiast can contribute refactoring actions to the language. This post discusses how a simple refactoring can be implemented and surfaced in Xcode.</p>
</blockquote>
<p>At this point, we all know that no major feature in Swift is worth discussing without a manifesto. Lucky for us, Chris Lattner wrote a <a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782">concurrency manifesto</a> this past week! Or, as <a href="https://twitter.com/clattner_llvm/status/898310296183357441">he described</a>: <em>“An essay looking at how async/await+actors could transform Swift concurrency & distributed compute.”</em> He emphasizes that this is only <em>one possible</em> approach, and details how the concurrency story in Swift could grow and evolve over <strong>many years</strong>. It’s only 19 pages! 😄 There’s also a much older <a href="https://github.com/apple/swift/blob/master/docs/proposals/Concurrency.rst">concurrency doc</a> in the Swift repo if you’re interested.</p>
<p>Brian Gesiak started a tutorial series on Swift compiler development with his inaugural post, <a href="https://modocache.io/getting-started-with-swift-development">Getting Started with Swift Compiler Development</a>. This is a great introduction to making your first changes in the compiler.</p>
<p>John Holdsworth wrote a post on <a href="http://johnholdsworth.com/bothworlds.html">Swift in Android Apps</a>, in which he lays out a brief history and the current state of Swift on Android. He explains the Swift Android toolchain, code generation, and communicating with the JNI. I’m not sure if this is worth the effort, but it is super interesting!</p>
<blockquote>
<p>… a viable environment exists that opens the possibility that <strong>model, business logic and network code can be shared between Android and iOS when it is written in Swift.</strong></p>
</blockquote>
<p>From <a href="https://twitter.com/slava_pestov/status/899759135528427521">Slava Pestov</a>:</p>
<blockquote>
<p>Great collection of fast and slow type checker test cases to catch regressions and track progress. (<a href="https://github.com/apple/swift/tree/master/validation-test/Sema/type_checker_perf">Link</a>)</p>
</blockquote>
<p>The <a href="http://llvm.org/devmtg/2017-10/">2017 US LLVM Developers Meeting</a> will be on October 18-19. The LLVM Foundation is also hosting its first <a href="https://www.eventbrite.com/e/2017-us-llvm-developers-meeting-women-in-compilers-and-tools-reception-tickets-36844782737">Women in Compilers and Tools Reception</a>, in conjunction with Developers Meeting. <em>“This event aims to connect women in the LLVM community and the field of compilers and tools. It also is open to anyone (men or women) who is interested in increasing diversity within the LLVM community, their workplace or university.”</em></p>
<p>Xcode 9 beta 6 was released. (<a href="https://download.developer.apple.com/Developer_Tools/Xcode_9_beta_6/Release_Notes_for_Xcode_9_beta_6.pdf">Release notes</a>)</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Chris Lattner opened a <a href="https://github.com/apple/swift/pull/11501">pull request</a> with a prototype for <code class="language-plaintext highlighter-rouge">async</code> / <code class="language-plaintext highlighter-rouge">await</code>.</p>
<p>Ben Langmuir <a href="https://github.com/apple/swift/pull/11566">added</a> code completion for generic <code class="language-plaintext highlighter-rouge">where</code> clauses.</p>
<p>Kelvin Ma opened a <a href="https://github.com/apple/swift/pull/11464">pull request</a> with an implementation for <a href="https://github.com/apple/swift-evolution/pull/741">SE-0184</a>: Improved pointers. However, it looks like this is going to require <a href="https://github.com/apple/swift-evolution/pull/741#issuecomment-324401647">more discussion on the mailing list</a>.</p>
<p>As previously discussed, Robert Widmann <a href="https://github.com/apple/swift/pull/11087">removed</a> the SwiftExperimental library.</p>
<h3 id="proposals">Proposals</h3>
<p>Chris Lattner and Joe Groff <a href="https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619">drafted a proposal</a> for <code class="language-plaintext highlighter-rouge">async</code> / <code class="language-plaintext highlighter-rouge">await</code>. This is still in the early stages, but it looks like this has a substantial chance of being included in Swift 5, despite the urgency of ABI stability. <a href="https://github.com/apple/swift/pull/11501">Prototype implementation here</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038891.html">kicked off concurrency discussions</a> for Swift 5:</p>
<blockquote>
<p>One of the goals for Swift 5 is to start laying the <em>groundwork</em> for a concurrency model. […]</p>
<p>Concurrency is a topic with many axes of design to explore, as the different domains we wish Swift to be successful will place different demands on a model. That exploration will take time: there will be tradeoffs with any model, and evaluating those tradeoffs will take discussion and iteration.</p>
<p>Today I’d like to open up swift-evolution to start some discussions about concurrency. Some of those discussions will focus on broader designs and concerns, and some will focus on specific use cases which we want to work great in Swift. Some opinions will likely differ significantly in the directions we should take — that’s fine. We intentionally want to explore different design spaces here, as a concurrency model for Swift has far reaching impact in the long-term on Swift as a language.</p>
<p>To kick things off, Chris Lattner has been sharing privately with a few people his own ideas for concurrency, which I have encouraged him to send out after this email. […]</p>
</blockquote>
<p>Also of note, Ted briefly mentioned an update on the move to Discourse:</p>
<blockquote>
<p>Once the Discourse forum comes online <strong>(which we are making progress on)</strong> we will likely tag or somehow segregate/mark discussions related to concurrency so they can easily be found. […]</p>
</blockquote>
<p>Chris’s <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038892.html">email</a> introducing the concurrency manifesto:</p>
<blockquote>
<p>As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift. This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast.</p>
<p>I’ve been advocating for a specific model involving async/await and actors for many years now. Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete. While I hope these ideas help push the discussion on concurrency forward, this isn’t in any way meant to cut off other directions: in fact I hope it helps give proponents of other designs a model to follow: a discussion giving extensive rationale, combined with the long term story arc to show that the features fit together.</p>
<p>[…]</p>
</blockquote>
<p>During the discussion on Chris’s <a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782">concurrency manifesto</a>, typed throws <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038928.html">came up as a sub-discussion</a> (which has been briefly discussed before on the mailing list).</p>
<blockquote>
<p>Typed throws is something we need to settle one way or the other, and I agree it would be nice to do that in the Swift 5 cycle.</p>
<p>For the purposes of this sub-discussion, I think there are three kinds of code to think about:</p>
<ol>
<li>large scale API like Cocoa which evolve (adding significant functionality) over the course of many years and can’t break clients.</li>
<li>the public API of shared swiftpm packages, whose lifecycle may rise and fall - being obsoleted and replaced by better packages if they encounter a design problem.</li>
<li>internal APIs and applications, which are easy to change because the implementations and clients of the APIs are owned by the same people.</li>
</ol>
<p>These each have different sorts of concerns, and we hope that something can start out as #3 but work its way up the stack gracefully.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038928.html">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/898940052792688640">this is too much for me to handle</a>.</p>
Issue #83
https://swiftweeklybrief.com/issue-83
2017-08-17T00:00:00-07:00
2017-08-17T00:00:00-07:00
Roman Volkov
https://twitter.com/volkovre
https://github.com/RomanVolkov.png?size=100
volkovre
<p>Things have been more quiet this week as everyone is excited about Swift 5 development beginning (announced last week). Bugs are being fixed, improvements are being made, and we finally found out where Chris Lattner is headed next!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5674">SR-5674</a>: Add fix-it for computed <code class="language-plaintext highlighter-rouge">let</code> declaration.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 24: <a href="https://spec.fm/podcasts/swift-unwrapped/81026">ABI Stability - Mangling</a>. Continuing from previous episodes on ABI Stability, this JP and Jesse discuss the mangling component and address some mistakes made in previous episodes.</p>
<h3 id="news-and-community">News and community</h3>
<p>Chris Lattner <a href="https://twitter.com/clattner_llvm/status/897149537109684224">officially announced</a> that he will be joining Google Brain.</p>
<p><a href="https://www.mikeash.com">Mike Ash</a> wrote a really great Friday Q&A on <a href="https://www.mikeash.com/pyblog/friday-qa-2017-08-11-swiftunmanaged.html">Swift.Unmanaged</a>, describing the way Swift converts object references to and from raw C pointers. He gives a good overview of this task in general, dividing API usage by memory management requirements, which depends on object ownership. He also provides a few fundamental patterns to use: Synchronous Callback, Asynchronous One-Shot Callback, and Asynchronous Multi-Shot Callback.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><code class="language-plaintext highlighter-rouge">String/Substring.CharacterView</code> was marked as deprecated in <a href="https://github.com/apple/swift/pull/11425">this pull request</a> from <a href="https://github.com/milseman">Michael Ilseman</a>. Moving from Swift 3.2 to Swift 4 could be a little bit easier now. <em>“CharacterView is now entirely redundant in Swift 4. Deprecate its use. This also allows us to schedule the unbreaking of String.CharacterView leakiness without a hard source break.”</em></p>
<p><a href="https://github.com/aschwaighofer">Arnold Schwaighofer</a> <a href="https://github.com/apple/swift/pull/11437">merged</a> a fix for a memory leak in <code class="language-plaintext highlighter-rouge">_cocoaStringSlice</code>. (Original fix by John McCall.)</p>
<p><a href="https://github.com/CodaFi">Robert Widmann</a> merged <a href="https://github.com/apple/swift/pull/11441">a pull request</a> to resolve an issue (<a href="https://bugs.swift.org/browse/SR-5671">SR-5671</a>) where downcasting inside a switch case from an array of superclass objects to array of subclass objects would fail to compile.</p>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> <a href="https://github.com/apple/swift/pull/11462">merged changes</a> to improvement to SIL by recording whether vtable entries are inherited or overridden.</p>
<p><a href="https://github.com/harlanhaskins">Harlan Haskins</a> <a href="https://github.com/apple/swift/pull/11320">merged</a> the initial implementation of the Swift libSyntax API, which was discussed first in <a href="https://swiftweeklybrief.com/issue-81/">Issue #81</a>.</p>
<p>Deyton Sehn <a href="https://github.com/apple/swift/pull/11448">fixed SR-5677</a> to clarify unsupported options passed to <code class="language-plaintext highlighter-rouge">swift</code> on the command line where users probably intended to use <code class="language-plaintext highlighter-rouge">swiftc</code>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">SE-0185</a>: <em>Synthesizing <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance</em> by Tony Allevato <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170814/038854.html">was accepted</a>. You can find the <a href="https://github.com/apple/swift/pull/9619">implementation here</a>.</p>
<blockquote>
<p>Feedback for the feature was glowingly positive, and the proposal is accepted. The core team discussed the concerns raised in the feedback thread for the proposal. Here are some rough notes (not intended to be exhaustive), but it is important to recognize that the proposal follows the design of the auto-synthesized <code class="language-plaintext highlighter-rouge">Codable</code> proposal, and that many of these same points were discussed when it came up:</p>
<ul>
<li>
<p>The core team feels that adding compiler magic for this case is reasonable because it solves an important user need, and doesn’t preclude the introduction of a more general feature (e.g. like a macro system, or Rust’s ‘deriving’ feature) in the future. When/if that feature is designed and built, the compiler magic can be replaced with standard library magic.</p>
</li>
<li>
<p>The hash value of a type is not intended to be stable across rebuilds or other changes to the code. It is ok to change if fields are reordered, the standard library changes the hash function, etc. Tony pointed this out on-thread, saying: The stdlib documentation for <code class="language-plaintext highlighter-rouge">hashValue</code> states “Hash values are not guaranteed to be equal across different executions of your program. Do not save hash values to use during a future execution.”</p>
</li>
<li>
<p>The code synthesized is meant to feel like a default implementation that you’re getting for free from a (constrained) extension on the protocol. This is why conformance to the protocol itself is all that is required, not something like “AutoEquatable”.</p>
</li>
</ul>
<p>Many thanks to Tony Allevato for driving forward this proposal. The patch just needs final code review now - I think we’re all looking forward to this landing, congrats!</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Robert Widmann started a <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170717/004953.html">discussion</a> on the swift-dev mailing list to fully remove the <code class="language-plaintext highlighter-rouge">SwiftExperimental</code> library. A <a href="https://github.com/apple/swift/pull/11087">pull request</a> was opened and is waiting for approval. If you have ideas how to transform <code class="language-plaintext highlighter-rouge">SwiftExperimental</code> into something new and useful — don’t be shy!</p>
<blockquote>
<p>The SwiftExperimental library’s stated purpose is to be a place where experimental library features could be explored without fear of committing to a stable interface. At least, that was its goal many years ago when significant work on it was last done. Since then, SwiftExperimental has sat untouched except for passing committers that need to alter parts of its implementation for language changes.</p>
<p>I would like to remove this library and target from the project, but first I’d like to solicit opinions about this change. In particular, if there are any users of the library, I’d like to know. I’d also like to know if there would be any interest in reviving a project like this in a different form — ideally out of tree.</p>
</blockquote>
<p>Daryle Walker <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170724/038297.html">stared a discussion</a> on adding the <code class="language-plaintext highlighter-rouge">constexpr</code> facility from C++ to Swift.</p>
<blockquote>
<p>The “constexpr” facility from C++ allows users to define constants and functions that are determined and usable at compile-time, for compile-time constructs but still usable at run-time. The facility is a key step for value-based generic parameters (and fixed-size arrays if you don’t want to be stuck with integer literals for bounds). Can figuring out Swift’s story here be part of Swift 5?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/clattner_llvm/status/897150073296928768">this is an outrage</a>.</p>
Issue #82
https://swiftweeklybrief.com/issue-82
2017-08-10T00:00:00-07:00
2017-08-10T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>With Swift 4 development wrapping up, this week the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038645.html">goals for Swift 5</a> were announced! There are a lot of things to unpack in this announcement, but two main topics stand out — ABI stability and changes to the Swift Evolution process.</p>
<p>First, ABI stability is not merely a goal for Swift 5, but <strong>a requirement</strong> for the release. Notably, this is the first Swift release to have a hard requirement like this. As Ted discussed in the email, whatever ABI we have at the end of Swift 5, that’s what we’re stuck with! So there you have it, no more ABI stability delays! This likely means that iOS 12 could be the first release to ship with Swift, no longer requiring application developers to bundle the Swift runtime and standard library with their apps.</p>
<p>Secondly, the Swift Evolution process will see substantial changes. If you recall, the Swift 4 development cycle was split up into two “phases” in an attempt to address the somewhat chaotic churn of proposals that we saw during the development of Swift 3. The intent of Swift 4’s phases was to keep the release focused on meeting its goals, but this didn’t quite work out as expected. Thus, beginning with Swift 5 <strong>proposals are required to have an implementation</strong> before being officially reviewed by the Core Team.</p>
<p>There’s some concern in the community that this raises the bar too high for proposals and participation will decrease dramatically as a result. However, this new rule <strong>does not</strong> mean that the proposal author is required to implement the changes. It only specifies that an implementation must be available in order to be reviewed. Thus, multiple contributors can collaborate on writing and implementing. Despite the potential downsides, I’m in favor of this change. I expect it reduce much of the distraction and pure bikeshedding that happens sometimes on the mailing lists. And practically speaking, I honestly don’t see any other option given the importance of ABI stability — have you seen <a href="https://swift.org/abi-stability/">how much work is still left to do</a>? 😅 Another benefit of this is that we could see the <em>actual impact</em> of the proposal on real-world code and include that as part of the review process. This will hopefully avoid another debacle like the <a href="https://jessesquires.com/blog/thoughts-on-swift-access-control/">access control controversy</a> of Swift 3.</p>
<p><a href="https://twitter.com/tkremenek/status/894957252389593088">Start your engines</a>! 🏎</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.tryswift.co/events/2017/bangalore/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_82" target="_blank">try! Swift India 2017</a></h4>
<p>try! Swift India is an amazing chance for developers in the Asian Pacific region to learn the latest in Swift Development. Learn from 15 international speakers, engage with the community. Coming to Bangalore on November 18th & 19th 2017! Limited tickets available.</p>
<p><small><a href="https://www.tryswift.co/events/2017/bangalore/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_82" target="_blank">tryswift.co</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5615">SR-5615</a>: Improve diagnostic “<code class="language-plaintext highlighter-rouge">public</code> modifier cannot be used in protocols”</li>
<li><a href="https://bugs.swift.org/browse/SR-5614">SR-5614</a>: <code class="language-plaintext highlighter-rouge">NS_EXTENSIBLE_STRING_ENUM</code> on a <code class="language-plaintext highlighter-rouge">typedef NSString</code> crashes the compiler / source editor</li>
<li><a href="https://bugs.swift.org/browse/SR-5605">SR-5605</a>: Parser fails on optional <code class="language-plaintext highlighter-rouge">#keyPath</code> in enum case</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 23: <a href="https://spec.fm/podcasts/swift-unwrapped/79765">ABI Stability – Data Layout and Metadata</a>. Following last week’s episode on the big picture of ABI Stability, we focus on two categories of decisions that need to happen to get there: data layout and metadata.</p>
<h3 id="news-and-community">News and community</h3>
<p>Xcode 9 beta 5 <a href="https://developer.apple.com/news/?id=07102017a">was released</a>, along with other betas. (<a href="https://download.developer.apple.com/Developer_Tools/Xcode_9_beta_5/Release_Notes_for_Xcode_9_beta_5.pdf">Release notes</a>).</p>
<p>You can find the list of Swift 5 goals <a href="https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md#development-major-version--swift-50">here</a>.</p>
<p>From <a href="https://twitter.com/slava_pestov/status/895097488079634433">Slava Pestov</a> on Twitter:</p>
<blockquote>
<p>If you have an idea for a contribution to the Swift compiler but aren’t sure where to start, please don’t hesitate to reach out</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Roman Levenstein <a href="https://github.com/apple/swift/pull/11380">merged</a> changes to reduce the stdlib size by 200KB.</p>
<p>Back in <a href="https://swiftweeklybrief.com/issue-71/">Issue #71</a>, we covered George Karpenkov’s <a href="https://github.com/apple/swift/pull/9450">pull request</a> to add support for the <code class="language-plaintext highlighter-rouge">-sanitize=fuzzer flag</code>. This was finally merged this week.</p>
<p>Michael Ilseman opened a <a href="https://github.com/apple/swift/pull/11373">pull request</a> to change <code class="language-plaintext highlighter-rouge">String.CharacterView</code> from being its own slice type to use <code class="language-plaintext highlighter-rouge">Substring.CharacterView</code> instead, as well as making it <code class="language-plaintext highlighter-rouge">RangeReplaceable</code>. <em>“This aligns with the goal of introducing Substring as a separate type
to avoid accidental memory ‘leaks’.”</em> The PR also removes some old Unicode 8 code.</p>
<p>As mentioned in detail below, Ted Kremenek officially announced the Swift 5 goals. Here’s <a href="https://github.com/apple/swift-evolution/commit/9cc90f33b6659adeaf92355c359e34e6fed73254#diff-04c6e90faac2675aa89e2176d2eec7d8">the diff</a> for the Swift Evolution README if you’re interested.</p>
<p>Per the new “rules” for Swift Evolution proposals (where proposals must be accompanied by an implementation prior to formal review), there is a new label on GitHub, <a href="https://github.com/apple/swift-evolution/labels/core%20team%3A%20needs%20implementation">core team: needs implementation</a> to denote proposals that have a lot of traction in the community and/or that the Core Team is interested in pursing. Ted Kremenek commented on two such draft proposals (<a href="https://github.com/apple/swift-evolution/pull/707#issuecomment-321391004">PR #707</a>, <a href="https://github.com/apple/swift-evolution/pull/705#issuecomment-321391584">PR #705</a>). One aims to <a href="https://github.com/apple/swift-evolution/pull/707/files">remove ownership keyword support in protocols</a>, and the other aims to <a href="https://github.com/apple/swift-evolution/pull/705/files">deprecate “tuple shuffle” expressions</a>. Chris Lattner commented on a third (<a href="https://github.com/apple/swift-evolution/pull/609">PR #609</a>) which seeks to <a href="https://github.com/apple/swift-evolution/pull/609/files">refine identifier and operator symbology</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0185-synthesize-equatable-hashable.md">SE-0185</a>: <em>Synthesizing <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance</em> by Tony Allevato is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-August/000397.html">under review</a>. This is the first proposal up for review for Swift 5, and (as required) you can find an initial implementation at <a href="https://github.com/apple/swift/pull/9619">PR #9619</a>.</p>
<blockquote>
<p>Developers have to write large amounts of boilerplate code to support equatability and hashability of complex types. This proposal offers a way for the compiler to automatically synthesize conformance to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> to reduce this boilerplate, in a subset of scenarios where generating the correct implementation is known to be possible.</p>
<p>[…]</p>
<p>In general, we propose that a type synthesize conformance to <code class="language-plaintext highlighter-rouge">Equatable</code>/<code class="language-plaintext highlighter-rouge">Hashable</code> if all of its members are <code class="language-plaintext highlighter-rouge">Equatable</code>/<code class="language-plaintext highlighter-rouge">Hashable</code>. We describe the specific conditions under which these conformances are synthesized below, followed by the details of how the conformance requirements are implemented.</p>
<p>[…]</p>
</blockquote>
<p>The ideas here are very much the same as the <code class="language-plaintext highlighter-rouge">Codable</code> protocol introduced in Swift 4, where all you have to do is declare conformance and the compiler will synthesize the rest. If all of a type’s properties are <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code>, then the type itself could be too. I expect this proposal to have overwhelming support from the community, especially given the precedent set by <code class="language-plaintext highlighter-rouge">Codable</code> and other synthesis that the compiler currently does.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>As mentioned, Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038645.html">officially announced</a> the <a href="https://github.com/apple/swift-evolution/blob/master/README.md">goals for Swift 5</a> as the development cycle for Swift 4 is winding down and nearing final release. Consideration of proposals for Swift 5 begins now! 🎉</p>
<blockquote>
<p>The proposal phase for Swift 4 is now officially over, and the release is now in endgame engineering convergence for an expected release later this year. Swift 4 has turned out to be one of the highest quality, well-rounded releases of Swift, and I am grateful to everyone in the community who made this release come together!</p>
<p>Now it is time to turn our attention to Swift 5. I have just posted updates to the <a href="https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md">README.md file</a> […]</p>
<p>I am not going to repeat all of that information here, but I wanted to highlight a few important things.</p>
<p><strong>ABI Stability</strong></p>
<p>First, ABI stability is the center focus of Swift 5 — and we will pivot much of our prioritization of efforts for Swift 5 around it. With Swift 4, ABI stability was a strong goal. In Swift 5, it is a <em>requirement</em> of the release. Whatever ABI we have at the end of Swift 5 is the ABI that we will have. ABI stability is an important inflection point for the maturity of the language, and it cannot be delayed any longer. […]</p>
<p><strong>Other focus areas (including laying the groundwork for concurrency)</strong></p>
<p>There are several other areas mentioned for Swift 5 which I won’t repeat here, but there is a general theme of refining and broadening out the core ergonomics of the language and standard library.</p>
<p>One of those that I wanted to highlight is laying the groundwork for concurrency. It is a non-goal of Swift 5 to roll out a full new concurrency model. That is simply too large an effort to do alongside ABI stability. However, it is important that we start making progress on discussing the directions for concurrency and laying some of the groundwork. […]</p>
<p><strong>Changes to the language evolution process</strong></p>
<p>Last, I want to highlight important changes to <a href="https://github.com/apple/swift-evolution/blob/9cc90f33b6659adeaf92355c359e34e6fed73254/README.md#evolution-process-for-swift-5">the evolution process</a>:</p>
<p>With Swift 4, the release period was divided up into “stage 1” and “stage 2” for setting guidelines for the kind of evolution proposals that were in scope for the release. This was needed to establish focus — especially after the churn we saw during Swift 3 — on some core themes that were aligned with converging the language towards source & ABI stability. One downside is that “stage 2” opened up discussion for potentially disruptive changes fairly late in the release. Further, some proposals — such as SE-0155 — came in so late that there was little runway to actually implement them for Swift 4, let alone evaluate their impact in practice on real projects. Related, there has been some desire for a while to be able to better evaluate the impact of proposals on real code before they are locked into the release, and the best way to do that is to actually have an implementation that vets out the design in a proposal.</p>
<p>With Swift 5, the focus on ABI stability will predominate priorities for both design and implementation work, but the Core Team did not want that focus to stifle all discussion on potential enhancements to the language that were not fundamentally tied to that primary goal. After reflecting on the evolution process during both the Swift 3 and Swift 4 releases, the Core Team felt that we could strike a balance with not diluting attention from ABI stability while still enabling a broader range of proposals compared to Swift 4 by <strong>requiring that all proposals have an implementation</strong> before they are officially reviewed by the Core Team. An implementation can come long after an idea has been pitched and after a proposal has been written. However, before a pull request for an evolution proposal will be accepted — and thus an official review scheduled — an implementation must be in hand for a proposal as part of the review. The existence of an implementation does not guarantee that the proposal will be accepted, but it is instrumental in evaluating the quality and impact of the proposal.</p>
<p>There are two key benefits of requiring an implementation:</p>
<ol>
<li>It encourages a design in a proposal to be more thoroughly fleshed out before the proposal is formally reviewed. The hope is that this will make the review process both more efficient as well as more effective.</li>
<li>An implementation allows the proposal to be evaluated on real world code and not just the examples that are in the proposal.</li>
</ol>
<p>[…]</p>
<p>Requiring an implementation naturally raises the bar for proposals. While this is by design, it can possibly have the negative aspect of making some feel the bar is too high for them to participate in the Swift evolution process. As an open source project, both the design and implementation of the language is a highly social endeavor, and we encourage the community to collaborate on both the design and implementation of proposals. Specifically, it is not a requirement that the original author(s) of a proposal be the one who provides an implementation — all that matters is that there is an implementation when a proposal gets reviewed.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038645.html">Continue reading…</a></p>
</blockquote>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038663.html">started a discussion</a> on <em>Enums and Source Compatibility</em>, elaborating on how to allow (or not allow) extending enums (i.e. adding additional cases) while maintaining both source and binary compatibility. This is an important design decision for ABI stability.</p>
<blockquote>
<p>Hi, everyone. Now that Swift 5 is starting up, I’d like to circle back to an issue that’s been around for a while: the source compatibility of enums. Today, it’s an error to switch over an enum without handling all the cases, but this breaks down in a number of ways:</p>
<ul>
<li>A C enum may have “private cases” that aren’t defined inside the original enum declaration, and there’s no way to detect these in a switch without dropping down to the rawValue.</li>
<li>For the same reason, the compiler-synthesized <code class="language-plaintext highlighter-rouge">init(rawValue:)</code> on an imported enum never produces <code class="language-plaintext highlighter-rouge">nil</code>, because who knows how anyone’s using C enums anyway?</li>
<li>Adding a new case to a Swift enum in a library breaks any client code that was trying to switch over it.</li>
</ul>
<p>(This list might sound familiar, and that’s because it’s from a message of mine on a thread started by Matthew Johnson back in February called “[Pitch] consistent public access modifiers”. Most of the rest of this email is going to go the same way, because we still need to make progress here.)</p>
<p>At the same time, we really like our exhaustive switches, especially over enums we define ourselves. And there’s a performance side to this whole thing too; if all cases of an enum are known, it can be passed around much more efficiently than if it might suddenly grow a new case containing a struct with 5000 Strings in it.</p>
<p>[…]</p>
<p>Just to have something to work off of, I propose the following:</p>
<ol>
<li>All enums (<code class="language-plaintext highlighter-rouge">NS_ENUM</code>s) imported from Objective-C are “open” unless they are declared “non-open” in some way (likely using the <code class="language-plaintext highlighter-rouge">enum_extensibility</code> attribute mentioned above).</li>
<li>All public Swift enums in modules compiled “with resilience” (still to be designed) have the option to be either “open” or “closed”. This only applies to libraries not distributed with an app, where binary compatibility is a concern.</li>
<li>All public Swift enums in modules compiled from source have the option to be either “open” or “closed”.</li>
<li>In Swift 5 mode, a public enum should be required to declare if it is “open” or “closed”, so that it’s a conscious decision on the part of the library author. (I’m assuming we’ll have a “Swift 4 compatibility mode” next year that would leave unannotated enums as “closed”.)</li>
<li>None of this affects non-public enums.</li>
</ol>
<p>(4) is the controversial one, I expect. “Open” enums are by far the common case in Apple’s frameworks, but that may be less true in Swift.</p>
<p>Why now?</p>
<p>Source compatibility was a big issue in Swift 4, and will continue to be an important requirement going into Swift 5. But this also has an impact on the ABI: if an enum is “closed”, it can be accessed more efficiently by a client. We don’t have to do this before ABI stability—we could access all enums the slow way if the library cares about binary compatibility, and add another attribute for this distinction later—but it would be nice™ (an easy model for developers to understand) if “open” vs. “closed” was also the primary distinction between “indirect access” vs. “direct access”.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170807/038663.html">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — the new Swift Evolution, <a href="https://twitter.com/modocache/status/895041827967037443">it’s a match</a>!</p>
Issue #81
https://swiftweeklybrief.com/issue-81
2017-08-03T00:00:00-07:00
2017-08-03T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>I can’t believe it’s already August! This means we are only one or two months away from a final release of Xcode 9, Swift 4, and all of the Apple OSes. We usually see a GM around late August or September. There are still a number of proposals that have not been implemented and I think it’s safe to say they will <em>not</em> be included in Swift 4. Anyway, this week there were some changes to SourceKit that will make SwiftLint users happy and an initial implementation of Swift bindings to libSyntax. On the mailing list, Jordan Rose discussed his 99 problems — spoiler, all of them are inheritance and initializers.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.harfangapps.com/regis/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_81" target="_blank">Regis: A Drastically Different Redis GUI For The Mac</a></h4>
<p>Harfang Apps is proud to sponsor this newsletter again with its newly-launched Mac App built with Swift! Regis is a powerful Redis client with a flexible multi-windows, multi-tabs-per-window UI where each tab is an independent Redis session. It supports all Redis features including the new Redis modules, pub-sub, pipelining and much more. <strong>Buy it now on the Mac App Store.</strong></p>
<p><small><a href="https://www.harfangapps.com/regis/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_81" target="_blank">harfangapps.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In Episode 22: <a href="https://spec.fm/podcasts/swift-unwrapped/78919">ABI Stability — The Big Picture</a>, we clear up some of the misconceptions around what ABI stability means, how we’ll get there and why it’s important.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Marcelo Fabri <a href="https://github.com/apple/swift/pull/11264">merged</a> changes to SourceKit to address <a href="https://bugs.swift.org/browse/SR-2487">SR-2487</a>. The issue here was that Swift 2.3 removed the “<code class="language-plaintext highlighter-rouge">source.decl.attribute.__raw_doc_comment</code>” attribute from structures returned by SourceKit. This was used by <a href="https://github.com/realm/SwiftLint">SwiftLint</a> (everyone’s favorite Swift linter 😄) to implement <code class="language-plaintext highlighter-rouge">ValidDocsRule</code> and <code class="language-plaintext highlighter-rouge">MissingDocsRule</code>. Marcelo’s pull request not only restores the functionality, but takes it a step further and adds the range of a doc comment for each declaration. This would make possible to add back those rules (and their implementation could possibly even be simpler now). Nice work Mercelo! 🙌</p>
<p>Harlan Haskins opened a <a href="https://github.com/apple/swift/pull/11320">pull request</a> with an initial implementation of the Swift libSyntax API, which aims to provide all features of the C++ API but exposed to Swift — that is, Swift bindings to libSyntax. <a href="https://github.com/apple/swift/tree/master/lib/Syntax">libSyntax</a> is a library in the Swift compiler that provides a full source-preserving Syntax tree that can be easily transformed and re-printed as a file. Why is this exciting? Let <a href="https://twitter.com/simjp/status/892960652129480704">JP Simard</a> explain: “this should eventually make it easier to write Swift tools <em>in Swift</em>.” 😱</p>
<p>Roman Levenstein <a href="https://github.com/apple/swift/pull/11251">implemented</a> a more robust way to avoid infinite generic specialization loops.</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/11249">merged</a> documentation revisions for the stdlib.</p>
<h3 id="proposals">Proposals</h3>
<p>Some proposal statuses <a href="https://github.com/apple/swift-evolution/pull/737">were updated</a> this week, which means the <a href="https://apple.github.io/swift-evolution/">Status Page</a> should be accurate now. Currently it looks like there are 12 accepted but unimplemented proposals and one still in review.</p>
<p>Kelvin Ma completed and merged the first draft of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md">SE-0184</a>: <em>Improved pointers</em> which was pitched on the mailing lists last week. It is not yet scheduled for a review and I am highly skeptical it will even be reviewed in the Swift 4 time frame, much less implemented if it gets accepted.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Jordan Rose sent out <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038522.html">a great explanation</a> on <code class="language-plaintext highlighter-rouge">Decodable</code> and <code class="language-plaintext highlighter-rouge">required</code> initializers in response to a discussion on twitter. He outlines the intricacies of Swift initializers and eventually refers readers to <a href="https://github.com/apple/swift/blob/master/docs/InitializerProblems.rst">this doc on Initializer Problems</a>. The TL;DR is that there’s not really a great answer and initializers are hard, but there are a few potential directions to explore in the future. Or, as <a href="https://twitter.com/Gankro/status/893117977901617152">Alexis Beingessner</a> put it, it’s “a great piece on why inheritance continues to be a nightmare when you try to mix it with traits/protocols/typeclasses.” 😄</p>
<blockquote>
<p><strong>Why you can’t make someone else’s class <code class="language-plaintext highlighter-rouge">Decodable</code>: a long-winded explanation of <code class="language-plaintext highlighter-rouge">required</code> initializers</strong></p>
<p>David Hart recently <a href="https://twitter.com/dhartbit/status/891766239340748800">asked on Twitter</a> if there was a good way to add <code class="language-plaintext highlighter-rouge">Decodable</code> support to somebody else’s class. The short answer is “no, because you don’t control all the subclasses”, but David already understood that and wanted to know if there was anything working to mitigate the problem. So I decided to write up a long email about it instead. (Well, actually I decided to write a short email and then failed at doing so.)</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038522.html">Continue reading…</a></p>
</blockquote>
<p>Nicole Jacque <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170731/038521.html">announced</a> some planned downtown for Swift.org:</p>
<blockquote>
<p>We will have some downtime for <a href="http://swift.org/">swift.org</a> resources over the weekend as we upgrade our infrastructure.</p>
<p>The outage schedule will be as follows:</p>
<ul>
<li><a href="http://bugs.swift.org/">bugs.swift.org</a> will become unavailable starting at 9 PM Thursday, Aug 3 (Pacific) until the upgrade is completed on Saturday, Aug 5</li>
<li><a href="http://swift.org/">swift.org</a> mailing lists (including this list) will become unavailable starting at 3 PM Friday, Aug 4 until the upgrade is completed on Saturday</li>
<li><a href="http://ci.swift.org/">ci.swift.org</a> and all CI infrastructure will become unavailable starting at 3 PM Friday, Aug 4 until the upgrade is completed on Saturday. We will also be locking the repos at this time until CI is back up.</li>
<li>The <a href="http://swift.org/">swift.org</a> website will be unavailable for a short time on Saturday afternoon.</li>
</ul>
<p>We expect the upgrade to be complete on Saturday afternoon or evening. We will send out email when the upgrade is complete.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/892391702949801984">I got two words for you</a>.</p>
Issue #80
https://swiftweeklybrief.com/issue-80
2017-07-27T00:00:00-07:00
2017-07-27T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>The fourth beta of Xcode 9/Swift 4 was released this week, which included support for Swift static libraries. Proposals are winding down with only revisions to SE-0104 still in review. And everybody’s favorite topic — the Swift Evolution process — was discussed on the swift-evolution mailing lists. 😄</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.harfangapps.com/regis/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_80" target="_blank">Regis: Full-featured Redis Client For The Mac</a></h4>
<p>Harfang Apps is proud to sponsor this week’s newsletter with its newly-launched Mac App built with Swift! Regis is a powerful Redis GUI that is command-based and provides built-in commands, JSON and binary output, integrated help, saved connections and settings and much more. <strong>Buy it now on the Mac App Store.</strong></p>
<p><small><a href="https://www.harfangapps.com/regis/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_80" target="_blank">harfangapps.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>This week in <a href="https://spec.fm/podcasts/swift-unwrapped/77840">Episode 21</a>, we dive into some of the recent proposals, including SE-0180, SE-0181, SE-0182, SE-0183.</p>
<h3 id="news-and-community">News and community</h3>
<p>Xcode 9 beta 4 was released. (<a href="https://download.developer.apple.com/Developer_Tools/Xcode_9_beta_4/Xcode_9_beta_4_Release_Notes.pdf">Release notes here</a>.) The big news is that the standard and the new build system both support Swift static libraries now. Thanks <a href="https://twitter.com/daniel_dunbar/status/889546788633321472">Daniel</a>!</p>
<p>Jordan Rose’s documentation on Swift, LLVM, and LLDV branching merged is now available in at <a href="https://github.com/apple/swift/blob/master/docs/Branches.md">docs/Branches.md</a>.</p>
<p>Not entirely related to Swift, but three new Darwin lib mirrors have appeared under the Apple GitHub organization over the past few weeks: <a href="https://github.com/apple/darwin-xnu">darwin-xnu</a> (Darwin Kernel), <a href="https://github.com/apple/darwin-libplatform">darwin-libplatform</a> (Darwin Platform Library), and <a href="https://github.com/apple/darwin-libpthread">darwin-libpthread</a> (Darwin PThread Library). These were previously only available at <a href="https://opensource.apple.com">opensource.apple.com</a>.</p>
<p>Also unrelated, but did you know that you can <a href="https://twitter.com/jesse_squires/status/889697105572319232">write Go in Xcode</a>?</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/11217">merged changes</a> to enable recursive protocol constraints (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>). <em>“With this change, type-checking the standard library is 4% faster than it was prior to this patch series…”</em></p>
<p>Michael Ilseman and Dave Abrahams <a href="https://github.com/apple/swift/pull/11212">implemented</a> changes to give <code class="language-plaintext highlighter-rouge">Substring</code> its own views. <em>“Substring now has distinct views inside of it. String’s view’s SubSequences are the same as Substring’s respective views, lending a consistent API that also encourages/enforces thinking about slices holding onto memory.”</em></p>
<p>Maxim Moiseev <a href="https://github.com/apple/swift/pull/11203">implemented</a> the updates to proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>.</p>
<p>Bartek Chlebek <a href="https://github.com/apple/swift-corelibs-foundation/pull/1128">added</a> <code class="language-plaintext highlighter-rouge">Codable</code> conformances to <code class="language-plaintext highlighter-rouge">CGPoint</code>, <code class="language-plaintext highlighter-rouge">CGSize</code>, and <code class="language-plaintext highlighter-rouge">CGRect</code> in corelibs-foundation.</p>
<p><strong>@practicalswift</strong> added seven new compiler crashers. (<a href="https://github.com/apple/swift/pull/11122">43</a>, <a href="https://github.com/apple/swift/pull/11123">44</a>, <a href="https://github.com/apple/swift/pull/11124">45</a>, <a href="https://github.com/apple/swift/pull/11128">46</a>, <a href="https://github.com/apple/swift/pull/11130">47</a>, <a href="https://github.com/apple/swift/pull/11131">48</a>, <a href="https://github.com/apple/swift/pull/11132">49</a>)</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md">SE-0183</a>: <em>Substring performance affordances</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000395.html">accepted</a>.</p>
<blockquote>
<p>As expected, feedback was light but positive. Thanks to Ben Cohen for driving this effort forward.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>The fourth revision of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000394.html">under review</a>. You can find the <a href="https://github.com/apple/swift-evolution/commit/f87bcb9b0f51dec13f6afc1c2f68e3a965edc4fe">diff here</a>.</p>
<blockquote>
<p>Following feedback during the 4.0 preview, a handful of minor amendments have been suggested to SE-104: Protocol-oriented integers that the core team feels are important to include into 4.0 as they have an impact on source stability.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>The discussion for the fourth review of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> got derailed into yet another meta-discussion about the swift-evolution process itself. As always, Chris Lattner provided a kind and insightful <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170717/038180.html">response to the concerns</a>:</p>
<blockquote>
<p>This is a great thing to discuss, and I don’t think that there is an iron-clad answer. Keeping swift-evolution effective is a complex problem, because it is highly multi-dimentional space to optimize in. We want to engage the community, encourage people to participate, allow people to push Swift in new directions (when that makes sense) and keep discussions productive and humane. All of this serves a meta goal of harnessing the folks who participate on swift-evolution to make Swift the best language possible.</p>
<p>The constraints are obvious: on most non-trivial topics, there will be some disagreement, so not everyone can be happy. There is only so much engineering time to build cool new things, so it has to be prioritized and divvied up somehow. As you say, it is impossible to make perfect decisions up front, so revisions and iteration are inevitable. Constraints like source and (looming) ABI stability restrict the kinds of changes that can be made. This is made all the more complicated by the fact that a lot of the tradeoffs made are necessarily judgement calls (and occasionally quite subjective), and decisions must be made with imperfect information (e.g. how long it will take to develop a feature). I think it is truly fantastic how engaged and productive swift-evolution is, particularly considering these challenges.</p>
<p>I don’t know how Swift 5 will go, but I would guess that it will be similar to the Swift 4 cycle, but will include changes made by learning from it. If so, it means that Ted will define the overarching themes for the release, to help prioritize effort. This is because currently Apple is paying for the majority of the engineering and they have a completely rationale right to determine how they spend that engineering time. In addition to the major themes, there will be other areas of focus as well (some of which won’t impact swift-evolution, like improvements to build times, performance, and stability).</p>
<p>Development will continue for some period of time, building out new things and a “feature complete” point will be reached. At this point, major changes will be restricted in an effort to stabilize and reduce risk for the release. This doesn’t mean that “no changes” will be made, but as the release grinds inexorably towards its final GM build the scope of changes will be restricted more and more. This is an interesting challenge given that “Beta 1” is usually the first release that goes out to the really broad Swift community, so it is the release that generates the most insight on where the changes have hit their mark or where they have missed. It is incredibly important to enable a feedback loop between folks using the early Swift toolchain builds and the betas so that we can refine and improve things to be the best possible.</p>
<p>Given that we’re very very late in the Swift 4 cycle, this is why Ben is guiding feedback in a certain narrow way (and why Xiaodi is helping to reinforce that guidance). As he says, there are certain changes that just <em>can’t</em> be made rationally at this late stage, because big or risky changes require an iteration and feedback cycle, and there isn’t time for it.</p>
<p>Going forward, we’ll all try to communicate what sorts of changes are appropriate at a given time. That said, we can’t make a perfect prediction and guarantee an absolute schedule. I know this can be frustrating, but it is simply the nature of having to make decisions without perfect information.</p>
</blockquote>
<p>Morten Bek Ditlevsen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170724/038230.html">started a thread</a> to ask about exposing <code class="language-plaintext highlighter-rouge">_JSONEncoder</code> and <code class="language-plaintext highlighter-rouge">_JSONDecoder</code>, which are private components used for the new <code class="language-plaintext highlighter-rouge">Codable</code> protocol in the standard library. If you read Greg Heo’s <a href="https://twitter.com/olebegemann/status/890149002389450752">article on this</a>, you’ll remember that the new Swift encoders and decoders just use <code class="language-plaintext highlighter-rouge">NSJSONSerialization</code> internally. Itai Ferber noted that this may change in the future:</p>
<blockquote>
<p>This is something we’ve considered adding and may do so in the future — however, this will require additional API review and will not make it in time for the Swift 4.0 release. The usage of <code class="language-plaintext highlighter-rouge">JSONSerialization</code> as the serialization backend is a current implementation detail, and may change in future releases; it would, for instance, be more efficient to read/write JSON as we encode/decode, instead of trying to collect the entire object graph before performing the next step.</p>
<p>We could also introduce something like a general <code class="language-plaintext highlighter-rouge">StructureEncoder</code>/<code class="language-plaintext highlighter-rouge">StructureDecoder</code> which performs this conversion, as this might be useful outside of just JSON. (For instance, <code class="language-plaintext highlighter-rouge">PropertyListEncoder</code>/<code class="language-plaintext highlighter-rouge">PropertyListDecoder</code> currently do something similar.)</p>
<p>So yes, this is under consideration for future API. :)</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/889560703132024836">You say “missing retain bugs”…</a>. 😂</p>
Issue #79
https://swiftweeklybrief.com/issue-79
2017-07-20T00:00:00-07:00
2017-07-20T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week two more outstanding proposals were formally accepted, including the much anticipated <em>String Newline Escaping</em> proposal, and there was a new, last minute string performance proposal from Ben Cohen. Even more, two non-Apple contributors have stepped up to implement two accepted-but-unimplemented proposals. Keep in mind, we’re already on beta 3 of Xcode 9 so the clock is ticking! Unfortunately, the time is up for some. Joe Groff confirmed that conditional conformances will not make the cut for Swift 4 (sad!), but he made up for the bad news by revealing how dogs wear pants. And yes, this means Joe is back from his Twitter hiatus!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.tryswift.co/events/2017/nyc/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_79" target="_blank">Join other Swifters in NYC!</a></h4>
<p>Contribute to Open Source Swift. Get the latest scoop from the founder of RxSwift. Master the new Swift 4 Codable. Build your first ARKit app. Add Machine Learning to your iOS App. Switch to Swift on the Server-Side with the creator of Vapor. Go bowling with new friends!</p>
<p><small><a href="https://www.tryswift.co/events/2017/nyc/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_79" target="_blank">tryswift.co</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/76778">Episode 20: Swift Migrator</a>, we dissect the newly open sourced part of Swift tooling that helps us port our apps to the latest Swift version.</p>
<h3 id="news-and-community">News and community</h3>
<p>Mike Ash is back with another <a href="https://www.mikeash.com/pyblog/friday-qa-2017-07-14-swiftcodable.html">Friday Q&A on Swift.Codable</a>. Mike’s Friday Q&A posts are always spectacular. 🙌</p>
<p>Tom Lokhorst wrote a great post on <a href="http://tom.lokhorst.eu/2017/07/strongly-typed-identifiers-in-swift">Strongly typed identifiers in Swift</a>. This is a clever way to take advantage of the type system instead of relying on traditional string identifiers or a mere <code class="language-plaintext highlighter-rouge">typealias</code>. I will definitely be implementing this in my projects!</p>
<p>Unfortunately, it looks like conditional conformances (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md">SE-0143</a>) are <a href="https://twitter.com/jckarter/status/885517749094539264"><strong>not going to happen</strong></a> for Swift 4 / Xcode 9. The proposal was accepted for Swift 4, but has not been completed. Maybe we’ll see this in a future Swift 4.1 release? At least we got multi-line strings though, am I right? 😉</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/10940">merged</a> a pull request enabling recursive protocol constraints by default (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>). However it was later <a href="https://github.com/apple/swift/pull/10949">reverted</a>.</p>
<p>John Holdsworth <a href="https://github.com/apple/swift/pull/11080">implemented</a> <code class="language-plaintext highlighter-rouge">String</code> newline escaping, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md">SE-0182</a>.</p>
<p>Jordan Rose opened a <a href="https://github.com/apple/swift/pull/11071">pull request</a> that adds documentation describing the Swift, LLVM, and LLDB branch structure. Super helpful!</p>
<p>The great David Rönnqvist (<a href="https://twitter.com/davidronnqvist">@davidronnqvist</a>) <a href="https://github.com/apple/swift/pull/10976">implemented</a> reduce with inout, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md">SE-0171</a>.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/11068">fixed</a> a bug with capture analysis for <code class="language-plaintext highlighter-rouge">defer</code>. <em>“A ‘defer’ that uses generic parameters inside of a closure had incorrect capture info computed by Sema, which could trigger various SILGen assertions.”</em></p>
<p>Itai Ferber <a href="https://github.com/apple/swift/pull/11045">fixed</a> a few outstanding issues with the new <code class="language-plaintext highlighter-rouge">Codable</code> protocol. (<a href="https://bugs.swift.org/browse/SR-4772">SR-4772</a> and <a href="https://bugs.swift.org/browse/SR-5122">SR-5122</a>)</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md">SE-0181</a>: <em>Package Manager C/C++ Language Standard Support</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000392.html">accepted <strong>with revision</strong></a>.</p>
<blockquote>
<p>There was support for the general feature, with some discussion of the spelling. We chose to accept the proposal mostly unmodified:</p>
<ol>
<li>While we agreed the enum cases could have simpler spellings, we felt this would require substantial design with little practical benefit (at this time, we will consider this for our future build setting proposal).</li>
<li>We agreed with feedback that using <code class="language-plaintext highlighter-rouge">cLanguageStandard</code>, etc in place of <code class="language-plaintext highlighter-rouge">cStandard</code> was more consistent, and will adopt that revision.</li>
</ol>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md">SE-0182</a>: <em>String Newline Escaping</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000393.html">accepted</a>.</p>
<blockquote>
<p>Feedback for the feature was positive, and the proposal is accepted with revision based on community discussion.</p>
<p>The core team requests that the feature be restricted to multi-line string literals, so it is a compile-time error to use in a single-quoted string. As was pointed out during review discussion, enabling escaped newlines for single line strings means that they are not single line anymore, and enabling single quoted strings to span multiple lines does not solve a strongly motivated glaring problem, since they can be upgraded to triple quoted strings. This change reduces the scope of the proposal, allowing proponents of this to restart the discussion later if and when there is compelling evidence (e.g. specific important use cases) to reconsider.</p>
<p>The core team also discussed feedback about the whitespace rules proposed, and agreed with the proposed design. It also discussed whether <code class="language-plaintext highlighter-rouge">\</code> should be allowed on the line immediately following the close <code class="language-plaintext highlighter-rouge">"""</code> and agreed that it was best to not allow it in this go-around.</p>
<p>Thank you to John Holdsworth, David Hart, and Adrian Zubarev for driving this proposal forward. Please revise the proposal, and if an adjusted PR can be made soon, we can get it in for Swift 4. Thanks!</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0183-substring-affordances.md">SE-0183</a>: <em><code class="language-plaintext highlighter-rouge">Substring</code> performance affordances</em> by Ben Cohen is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000391.html">under review</a>.</p>
<p>From the email:</p>
<blockquote>
<p>Context: One more small refinement proposal for Swift 4 strings. We are specifically not opening the floodgates for new proposals yet, this is this simply one potential small-scope refinement to an existing Swift 4 feature.</p>
</blockquote>
<p>From the proposal:</p>
<blockquote>
<p>This proposal modifies a small number of methods in the standard library that
are commonly used with the <code class="language-plaintext highlighter-rouge">Substring</code> type:</p>
<ul>
<li>Modify the <code class="language-plaintext highlighter-rouge">init</code> on floating point and integer types, to construct them from <code class="language-plaintext highlighter-rouge">StringProtocol</code> rather than <code class="language-plaintext highlighter-rouge">String</code>.</li>
<li>Change <code class="language-plaintext highlighter-rouge">join</code> to be an extension <code class="language-plaintext highlighter-rouge">where Element: StringProtocol</code></li>
<li>Have <code class="language-plaintext highlighter-rouge">Substring.filter</code> to return a <code class="language-plaintext highlighter-rouge">String</code></li>
</ul>
<p>[…]</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Kelvin Ma <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/038013.html">proposed a draft proposal</a> to improve Swift pointers. More specifically, he wants to address inconsistency and improve the convenience of the <code class="language-plaintext highlighter-rouge">Unsafe*Pointer</code> APIs. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/038060.html">Dave Abrahams</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170717/038127.html">Michael Ilseman</a> expressed support for the idea, though a formal proposal will need more work. You can find the draft <a href="https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06">in this gist</a>.</p>
<blockquote>
<p>Swift currently offers two sets of pointer types — singular pointers such as <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code>, and vector (buffer) pointers such as <code class="language-plaintext highlighter-rouge">UnsafeMutable</code><strong><code class="language-plaintext highlighter-rouge">Buffer</code></strong><code class="language-plaintext highlighter-rouge">Pointer</code>. This implies a natural separation of tasks the two kinds of pointers are meant to do. For example, buffer pointers implement <code class="language-plaintext highlighter-rouge">Collection</code> conformance, while singular pointers do not.</p>
<p>However, some aspects of the pointer design contradict these implied roles. It is possible to allocate an arbitrary number of instances from a type method on a singular pointer, but not from a buffer pointer. The result of such an operation returns a singular pointer, even though a buffer pointer would be more appropriate to capture the information about the <em>number</em> of instances allocated. It’s possible to subscript into a singular pointer, even though they are not real <code class="language-plaintext highlighter-rouge">Collection</code>s. Many of the memorystate methods on <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> work on vectors of items, while others, such as <code class="language-plaintext highlighter-rouge">move()</code> return a single instance. Some parts of the current design turn UnsafePointers into downright <em>Dangerous</em>Pointers, leading users to believe that they have allocated or freed memory when in fact, they have not.</p>
<p>This proposal seeks to iron out these inconsistencies, and offer a more convenient, more sensible, and less bug-prone API for Swift pointers.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/887533322150305793">the truth about how dogs wear pants</a>.</p>
Issue #78
https://swiftweeklybrief.com/issue-78
2017-07-13T00:00:00-07:00
2017-07-13T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week the third beta of Xcode 9 (and thus Swift 4) was released, there are a couple of new proposals in review, and the IBM Runtimes compiler team announced a prototype JIT compiler for server-side Swift, which will be open sourced in the near future. This is super cool, but if I’m being honest I’m more excited about the potential enhancements to multi-line string literals. 😄</p>
<p>In other news, there are currently <a href="https://apple.github.io/swift-evolution/">15 accepted proposals</a> for Swift 4 that have not been implemented. I’m sure many are in-progress, but it looks likely that some of these will be pushed to a future release.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="http://www2.bignerdranch.com/l/299472/2017-06-21/8rxl/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_78" target="_blank">Ramp up your skills — and your career</a></h4>
<p>Go from junior to senior developer in just a week, with the experts who have taught iOS from the very beginning.</p>
<p><small><a href="http://www2.bignerdranch.com/l/299472/2017-06-21/8rxl/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_78" target="_blank">bignerdranch.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5337">SR-5337</a>: Improve diagnostic for <code class="language-plaintext highlighter-rouge">var</code> in parameter position</li>
<li><a href="https://bugs.swift.org/browse/SR-5383">SR-5383</a>: Display appropriate message when trying to build system module packages</li>
<li><a href="https://bugs.swift.org/browse/SR-5324">SR-5324</a>: Better diagnostic when instance member of outer type is referenced from nested type</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In Episode 19: <a href="https://spec.fm/podcasts/swift-unwrapped">WWDC Reactions</a>, we share our thoughts on the announcements and events from the week. Better late than never! Listen to find out why we had to wait so long. 😄</p>
<h3 id="news-and-community">News and community</h3>
<p>New betas of Xcode 9 and Swift 4, and all the platform OSes are <a href="https://developer.apple.com/news/?id=07102017a">now available</a>.</p>
<p>Some <a href="https://github.com/apple/swift/pull/6874/files">updates to the CODE_OWNERS.txt</a> were made, so take note for when you need to find the right person to review your pull requests. Of note, Chris Lattner is still listed as being responsible for “everything in Swift not covered by someone else” — good thing he’s <a href="https://twitter.com/clattner_llvm/status/877341760812232704">currently unemployed</a>! 😉</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Arjun Nayini <a href="https://github.com/apple/swift/pull/8354">merged changes</a> to the stdlib to make 0-ary tuples (that is, <code class="language-plaintext highlighter-rouge">()</code>) conform to <code class="language-plaintext highlighter-rouge">Equatable</code>. (<a href="https://bugs.swift.org/browse/SR-4172">SR-4172</a>) Rejoice, <code class="language-plaintext highlighter-rouge">() == ()</code> will now compile. And it only took 3.5 months! 😅 Luckily, it <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/038032.html"><em>did not</em></a> require a formal swift-evolution review.</p>
<p>John Holdsworth opened two pull requests (<a href="">#1103</a>, <a href="https://github.com/apple/swift-corelibs-foundation/pull/1113">#1113</a>) for corelibs-foundation to get https working on Android.</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/10928">made changes</a> to the ClangImporter to prevent importing compatibility methods named <code class="language-plaintext highlighter-rouge">print</code> because they make things harder for people trying to use <code class="language-plaintext highlighter-rouge">Swift.print</code>. Amen. 🙌</p>
<p>As part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>, Doug Gregor <a href="https://github.com/apple/swift/pull/10916">added a new frontend flag</a>, <code class="language-plaintext highlighter-rouge">-enable-recursive-constraints</code>. <em>“Introduce <code class="language-plaintext highlighter-rouge">-enable-recursive-constraints</code> to disable the error about direct recursion within a protocol definition. The implementation of recursive protocol constraints is incomplete, but might be useful for experimentation.”</em></p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/1264">opened a pull request</a> to implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md">SE-0181</a>. (See below for details.)</p>
<p>Philippe Hausler <a href="https://github.com/apple/swift/pull/10914">added</a> benchmarks for common <code class="language-plaintext highlighter-rouge">NSString</code> APIs that are exposed on <code class="language-plaintext highlighter-rouge">String</code>.</p>
<p>Bartek Chlebek <a href="https://github.com/apple/swift-corelibs-foundation/pull/1101">implemented</a> <code class="language-plaintext highlighter-rouge">OperationQueue.current</code> in corelibs-foundation.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>: <em>String Index Overhaul</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170703/037942.html">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted. There was a lively discussion about it, but in the end everyone seems to agree that this is the right thing to do.</p>
<p>As always, I’d like to thank you for your help in making Swift a better language.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0181-package-manager-cpp-language-version.md">SE-0181</a>: <em>Package Manager C/C++ Language Standard Support</em> by Ankit Aggarwal is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000389.html">under review</a>.</p>
<blockquote>
<p>This proposal adds support for declaring the language standard for C and C++ targets in a SwiftPM package.</p>
<p>The C++ language standard is one of the most important build setting needed to compile C++ targets. We want to add some mechanism to declare it until we get the complete build settings feature, which is deferred from the Swift 4 release.</p>
<p>[…]</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0182-newline-escape-in-strings.md">SE-0182</a>: <em>String Newline Escaping</em> by John Holdsworth, David Hart, and Adrian Zubarev is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-July/000390.html">under review</a>.</p>
<blockquote>
<p>This proposal is a refinement of <a href="0168-multi-line-string-literals.md">SE-0168</a> which introduces the ability to escape newlines in single and multi-line strings to improve readability and maintenance of source material containing excessively long lines.</p>
<p>Swift-evolution thread: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035923.html">Discussion thread</a></p>
<p>Escaping newlines in multi-line strings was removed from the <a href="0168-multi-line-string-literals.md">SE-0168</a> proposal by the Core Team […]</p>
<p>Adding them to multi-line strings would have introduced an inconsistency with respect to conventional string literals. This proposal conforms both multi-line and conventional string construction to allow newline escaping, enabling developers to split text over multiple source lines without introducing new line breaks. This approach enhances source legibility. […] Incorporating a string continuation character is well founded, used in other development languages, and carries little risk of confusing naive users.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Younes Manton <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170710/037970.html">sent an email</a> announcing a prototype JIT compiler for server-side Swift, created by a small group of developers from the IBM Runtimes compiler team:</p>
<blockquote>
<p>Last year a small group of developers from the IBM Runtimes compiler team
undertook a project to explore JIT compilation for Swift, primarily aimed
at server-side Swift. The compilation model we settled on was a hybrid
approach that combined static compilation via <code class="language-plaintext highlighter-rouge">swiftc</code> with dynamic
compilation via a prototype JIT compiler based on Eclipse OMR. [1]</p>
<p>This prototype JIT compiler (targeting Linux specifically) functioned by
having itself loaded by a Swift process at runtime, patching Swift
functions so that they may be intercepted, recompiling them from their SIL
representations, and redirecting callers to the JIT compiled version. In
order to accomplish this we needed to make some changes to the static
compiler and the target program’s build process.</p>
<p>[…]</p>
<p>(As for the prototype itself, we intend to open source it either in its
current state [based on Swift 3.0 and an early version of OMR] or in a more
up-to-date state in the very near future.)</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/daniel_dunbar/status/884507290170216448">babe of my existence</a>. 😄</p>
Issue #77
https://swiftweeklybrief.com/issue-77
2017-07-06T00:00:00-07:00
2017-07-06T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>After some time off and a break from the weekly, I’m back! Before we get started, I’d like to send a final massive thanks to the other <a href="https://swiftweeklybrief.com/authors/">Swift Weekly writers and contributors</a> for doing such a great job the past few weeks. This team is great and they worked super hard to bring you the best Swift news, and even helped with this issue. Alright — let’s get to it!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.buddybuild.com/#utm_source=newsletter&utm_medium=email&utm_campaign=Swift_Weekly_0717/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_77" target="_blank">Buddybuild — a CI/CD service built for Swift developers</a></h4>
<p>Buddybuild is a continuous integration, continuous deployment and user feedback platform built specifically for mobile development teams. Buddybuild takes minutes to get setup, and automates the process of configuring a reliable and robust infrastructure for teams to build, test, and deploy their apps. <a href="https://www.buddybuild.com/customers/">Thousands of companies</a>, like Slack, Meetup and Mozilla trust buddybuild with their mobile development because it allows them to focus on what’s important - building apps users love. <strong>Start your free 3 week trial today, and stay focused on building apps users love.</strong></p>
<p><small><a href="https://www.buddybuild.com/#utm_source=newsletter&utm_medium=email&utm_campaign=Swift_Weekly_0717/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_77" target="_blank">buddybuild.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/72298">Episode 18: Community Open Source Spotlight</a>, JP and I take a break from Swift itself to shine the spotlight on the open source community and highlight some lesser-known open source Swift projects.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ole Begemann was kind enough to <a href="https://oleb.net/blog/2017/06/chris-lattner-wwdc-swift-panel/">write up part of Chris Lattner’s commentary</a> from the <a href="https://news.realm.io/news/wwdc-2017-swift-panel/">WWDC Swift Panel</a> a few weeks ago. Swift’s long-term plan is exciting! You can read the <a href="https://news.ycombinator.com/item?id=14673059">Hacker News thread</a> for even more commentary and discussion.</p>
<p>Ben Scheirman <a href="http://benscheirman.com/2017/06/ultimate-guide-to-json-parsing-with-swift-4/">wrote a great post</a> that looks at Swift’s new Encoder/Decoder implementation, focusing on JSON parsing.</p>
<p>Simon Gladman’s <a href="https://itunes.apple.com/gb/book/core-image-for-swift/id1073029980?mt=13">Core Image for Swift</a> book is <a href="https://twitter.com/flexmonkey/status/881789384735039489">now free</a>! 👍</p>
<p><a href="https://twitter.com/chriseidhof">Chris Eidhof</a> wrote a <a href="http://chris.eidhof.nl/post/reducers/">post</a> where he refactors an asynchronous view controller using the reducer pattern.</p>
<p>LLVM’s bug tracker now has a <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-June/114845.html">“beginner”</a> keyword. If you’re a new contributor to LLVM, it’s easier than ever to find and tackle these more beginner-level bugs. The Swift compiler uses a great deal of LLVM’s functionality, so contributing to LLVM helps Swift too!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Bartek Chlebek <a href="https://github.com/apple/swift-corelibs-foundation/pull/1048">merged</a> an implementation of <code class="language-plaintext highlighter-rouge">JSONEncoder</code> in corelibs-foundation so that it’s available on Linux, not just Darwin. (<a href="https://bugs.swift.org/browse/SR-5195">SR-5195</a>)</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/10765">fixed a bug</a> with class members marked <code class="language-plaintext highlighter-rouge">@objc</code> that avoids building conformance lookup tables unnecessarily.</p>
<p>Joe Groff opened a <a href="https://github.com/apple/swift/pull/10741">pull request</a> to implement handling generic computed properties in Swift’s new KeyPaths.</p>
<p>Itai Ferber opened a <a href="https://github.com/apple/swift/pull/10766">pull request</a> with a workaround for conditional conformance in the new <code class="language-plaintext highlighter-rouge">JSONEncoder</code>. This addresses <a href="https://bugs.swift.org/browse/SR-5206">SR-5206</a>, which describes a situation where the encoded results could be different depending on which <code class="language-plaintext highlighter-rouge">Container.encode</code> method is called.</p>
<p>Itai Ferber also <a href="https://github.com/apple/swift/pull/10723">submitted a fix</a> for an issue where the generated <code class="language-plaintext highlighter-rouge">CodingKeys</code> type is not available in function signatures. (<a href="https://bugs.swift.org/browse/SR-5215">SR-5215</a>)</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/10773">fixed</a> a compiler crash when a key path literal was used in an expression with <code class="language-plaintext highlighter-rouge">Any</code> or <code class="language-plaintext highlighter-rouge">AnyObject</code> contextual type.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week! As always, you can <a href="https://apple.github.io/swift-evolution/">check the status page</a> for details.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>The mailing lists were much more quiet than usual this week! I guess developers are too busy playing with the new SDKs, filing radars for Xcode 9, and getting their apps ready for the new OS releases. The Core Team is certainly busy fixing bugs and polishing Swift 4.</p>
<p>Soroush Khanlou <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170703/037896.html">pitched an idea</a> for a new <code class="language-plaintext highlighter-rouge">guard</code>/<code class="language-plaintext highlighter-rouge">catch</code> construct in the language. You can find a draft <a href="https://gist.github.com/khanlou/8bd9c6f46e2b3d94f0e9f037c775f5b9">in this gist</a>.</p>
<blockquote>
<p>This proposal introduces a <code class="language-plaintext highlighter-rouge">guard</code>/<code class="language-plaintext highlighter-rouge">catch</code> statement to Swift. This statement is congruent to the existing <code class="language-plaintext highlighter-rouge">guard</code>/<code class="language-plaintext highlighter-rouge">else</code> statement while adding error catching support.</p>
<p>Swift’s native error handling mechanisms are powerful and convenient when the user works in a throwing context, such as functions and closures that can throw. Outside a throwing context, the user’s only recourse is to use Swift’s <code class="language-plaintext highlighter-rouge">do</code>/<code class="language-plaintext highlighter-rouge">catch</code> syntax to catch, pattern match, and handle thrown errors.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/slava_pestov/status/882799504327491584">Finally home after two weeks…</a></p>
Issue #76
https://swiftweeklybrief.com/issue-76
2017-06-29T00:00:00-07:00
2017-06-29T00:00:00-07:00
Garric Nahapetian
https://twitter.com/garricn
https://github.com/garricn.png?size=100
garricn
<p>It was a busy week on the main <a href="https://github.com/apple/swift">apple/swift</a> repo. Here are some stats from GitHub Insights:</p>
<blockquote>
<p>Excluding merges, 39 authors have pushed 156 commits to master and 284 commits to all branches. On master, 401 files have changed and there have been 12,589 additions and 9,215 deletions..</p>
</blockquote>
<p>It’s great to see so much work being done so soon after WWDC. The core team and other contributors are making significant progress on the road to the official Swift 4 launch.</p>
<p>iOS 11 beta 2, tvOS 11 beta 2, and Swift Playgrounds 2 beta 2 were all released. Download them <a href="https://developer.apple.com/download/">here</a>, and keep filing radars!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="http://www2.bignerdranch.com/l/299472/2017-06-21/8rxl/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_76" target="_blank">Ramp up your skills — and your career</a></h4>
<p>Go from junior to senior developer in just a week, with the experts who have taught iOS from the very beginning.</p>
<p><small><a href="http://www2.bignerdranch.com/l/299472/2017-06-21/8rxl/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_76" target="_blank">bignerdranch.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/70319">Episode 17: Testing in Swift</a>, Jesse and JP discuss how Swift and its set of open source tools are tested to ensure that every release breaks as little as possible. 😜</p>
<h3 id="news-and-community">News and community</h3>
<p>Greg Heo <a href="https://swiftunboxed.com/stdlib/json-encoder-encodable/">wrote a post</a> that looks at how Swift <code class="language-plaintext highlighter-rouge">Encoder</code> and <code class="language-plaintext highlighter-rouge">Encodable</code> work. There’s been a lot of open source activity related to this new feature, so understanding how it works will help when trying to digest related PRs.</p>
<p>Matt Godbolt’s Compiler Explorer now <a href="https://twitter.com/Catfish_Man/status/877991651548975104">supports Swift</a>.</p>
<p>David Owens <a href="https://owensd.io/2017/06/02/apous-early-preview/">released a preview</a> for an extension to Visual Studio Code that supports Swift.</p>
<p>The Swift backend for the Swift-Evolution app, <a href="https://itunes.apple.com/us/app/evolution-app/id1210898168?mt=8">Evo</a>, is <a href="https://twitter.com/swift_evolution/status/878322333471068160">now open source</a>.</p>
<p>Steven Hepting <a href="https://twitter.com/stevenhepting/status/878339681485635585">explains</a> how Swift’s <code class="language-plaintext highlighter-rouge">sort()</code> method is optimized. Find the <a href="https://github.com/apple/swift/blob/02e2bd5380af69948d2324b936bfc61e1454d8ea/stdlib/public/core/Sort.swift.gyb#L232-L301">source code here</a>.</p>
<p><a href="https://www.meetup.com/Learn-Swift-Queens-Meetup/">Learn Swift Queens</a> & <a href="https://www.meetup.com/Learn-Swift-Portland/">Learn Swift Portland</a>, just launched. That’s 11 <a href="https://wordpress.com/post/swiftcoders.org/178">Learn Swift {CITY}</a> meet ups worldwide! Which city will be next?</p>
<p><a href="https://github.com/br1sk/brisk">Brisk, a macOS app for submitting radars</a> released <a href="https://github.com/br1sk/brisk/releases/tag/1.0.0">version 1.0</a> and a quick <a href="https://github.com/br1sk/brisk/releases/tag/1.0.1">1.0.1 follow-up release</a>. Check out the release notes and keeping filing radars!</p>
<p>More <a href="https://twitter.com/s1ddok/status/879406585939984386">fallout</a> from Tuplegate. This was interesting to me because <a href="https://github.com/garricn/GGNObservable/blob/master/GGNObservable/Classes/Observable.swift#L53">I use this exact same pattern</a>. As <a href="https://twitter.com/slava_pestov/status/879446070190800896">Slava points out</a> in the thread, there’s still <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012299.html">room for improvement</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Ben Cohen <a href="https://github.com/apple/swift-evolution/pull/728">opened a pull request</a> to add Substring affordances to <code class="language-plaintext highlighter-rouge">Hashable</code> containers (See below for mailing list discussion).</p>
<p>Itai Ferber <a href="https://github.com/apple/swift/pull/10538">merged a pull request</a> that fixes <a href="https://bugs.swift.org/browse/SR-5277">SR-5277</a>. This allows classes to share an Encoder/Decoder with its super class. For further explanation, check out this <a href="https://twitter.com/garricn/status/878426105585127425">thread</a>.</p>
<p>Philippe Hausler <a href="https://github.com/apple/swift/pull/10584">merged a pull request</a> that fixes <a href="https://bugs.swift.org/browse/SR-5292">SR-5292</a>. This fixes a crasher in Foundation when working with slices of slices.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/10556">merged a pull request</a> that adds support for optional chaining / force unwrapping when dealing with KeyPaths.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/10565">merged a pull request</a> that improves the handling of concrete types, type aliases, and recursion, and which fixes <a href="https://bugs.swift.org/browse/SR-4295">SR-4295</a>, <a href="https://bugs.swift.org/browse/SR-4757">SR-4757</a>, <a href="https://bugs.swift.org/browse/SR-4786">SR-4786</a>, <a href="https://bugs.swift.org/browse/SR-5014">SR-5014</a>, and <a href="https://bugs.swift.org/browse/SR-4737">SR-4737</a>.</p>
<p>Dave Abrahams <a href="https://github.com/apple/swift/pull/9806">opened a pull request</a> that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>, the String index Overhaul (See below).</p>
<p>The manual displayed when running <code class="language-plaintext highlighter-rouge">man swift</code> on the command line <a href="https://github.com/apple/swift/pull/10241">has been updated</a>.</p>
<p>Maxim Moiseev <a href="https://github.com/apple/swift/pull/9466">merged a pull request</a> that fixes backward compatibility for <code class="language-plaintext highlighter-rouge">flatMap</code> on <code class="language-plaintext highlighter-rouge">[String]</code>. Check out this related <a href="https://twitter.com/codafi_/status/878330155642396673">Swift Puzzle by Robert Widmann</a>.</p>
<p>David Farler <a href="https://github.com/apple/swift-clang/pull/95">merged a pull request</a> that upstreams Apple’s (previously) internal index-while-building changes released with Xcode 9.</p>
<p>If you ever wonder what the details are for a <code class="language-plaintext highlighter-rouge">rdar://</code> that a particular PR fixes, <a href="https://twitter.com/garricn/status/879551154316689408">feel free to ask</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>: <em>String Index Overhaul</em> is back <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037653.html">in review</a> after some revisions.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170626/037730.html">made a pitch</a> for a <code class="language-plaintext highlighter-rouge">!!</code> operator, which she calls “Unwrap or Die”. You can find a draft in <a href="https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b">this gist</a>.</p>
<blockquote>
<p>Using an operator to provide feedback on the context of a failed unwrap has become a commonly implemented approach in the Swift developer Community. What are your thoughts about adopting this widely-used operator into the standard library?</p>
</blockquote>
<p>Ben Cohen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170626/037776.html">made a pitch</a> regarding <code class="language-plaintext highlighter-rouge">Substring</code> performance affordances.</p>
<blockquote>
<p>As outlined in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md">SE-0163</a>, the more general question of implicit conversion from <code class="language-plaintext highlighter-rouge">Substring</code> to <code class="language-plaintext highlighter-rouge">String</code> was deferred pending feedback on the initial implementation. To date, the feedback we’ve received hasn’t suggested that such an implicit conversion is necessary — that migrations from 3.2 to 4.0 haven’t led to an extensive need to perform <code class="language-plaintext highlighter-rouge">Substring</code> -> <code class="language-plaintext highlighter-rouge">String</code> conversion. Any further input, either on or off list, about this particular aspect of migration would be very gratefully received.</p>
<p>[…]</p>
</blockquote>
<p>Itai Ferber sent <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037672.html">a message on Swift-Evolution</a> asking for feedback regarding <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a> and letting the community know that suggestions have already been implemented and will continue to be considered.</p>
<p>Robert Bennett made an <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037676.html">interesting pitch</a> for declaring <code class="language-plaintext highlighter-rouge">let</code> in protocols. I didn’t realize this problem existed.</p>
<blockquote>
<p>I’m bumping into an annoying problem with protocols. In a <code class="language-plaintext highlighter-rouge">class</code> or <code class="language-plaintext highlighter-rouge">struct</code> it is common to have a <code class="language-plaintext highlighter-rouge">let</code> instance variable and assign it in <code class="language-plaintext highlighter-rouge">init</code>. Unfortunately there is no way to translate this into a protocol with <code class="language-plaintext highlighter-rouge">init</code> in an extension.</p>
<p>[…]</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Taking can <a href="https://twitter.com/harlanhaskins/status/878499165663240192">sometimes</a> feel as good as giving.</p>
Issue #75
https://swiftweeklybrief.com/issue-75
2017-06-22T00:00:00-07:00
2017-06-22T00:00:00-07:00
Greg Heo
https://twitter.com/gregheo
https://github.com/gregheo.png?size=100
gregheo
<blockquote>
<p>There once was a language called Swift<br />
Proposals and fix-its caused drift<br />
to existing code bases,<br />
if statements, switch cases;<br />
But newsletters help bridge the rift<br /></p>
</blockquote>
<p>I don’t know about you but I’m still recovering from all the WWDC excitement. 😓</p>
<p>Keeping us on our toes, the folks at Apple have released a second round of OS betas and Xcode seeds. Check out the <a href="https://developer.apple.com">developer portal</a> and the Xcode 9 Beta 2 release notes in particular for the latest on improvements and known issues in the bundled Swift 4.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.eventbrite.com/o/plausible-labs-12068803363/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_75" target="_blank">Advanced Swift Workshops</a></h4>
<p>Sharpen your Swift skills and learn in depth topics in this one day workshop. World renowned guy and occasional Swift expert Mike Ash will lead you through an exploration of protocols, generics, reflection, and C bridging. July 13th in Washington, DC, and July 24th in New York City.</p>
<p><small><a href="https://www.eventbrite.com/o/plausible-labs-12068803363/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_75" target="_blank">eventbrite.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<p>Writing tests is a great way to learn about the standard library and language, and also helps the project by preventing future regressions.</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-4824">SR-4824</a>: Add tests to check Collection constraints are being enforced</li>
<li><a href="https://bugs.swift.org/browse/SR-5040">SR-5040</a>: Convert “exclude” related functional tests to unit test</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In <a href="https://spec.fm/podcasts/swift-unwrapped/72297">Episode 16: Error Handling in Swift — A History</a>, your hosts say the words “rethrows” and “types” many times, reminisce about Objective-C, and uncover the history of error handling in Swift.</p>
<h3 id="news-and-community">News and community</h3>
<p>Swift team superstar <a href="https://twitter.com/jckarter/status/875401073447419904">Joe Groff</a> is taking a Twitter break. Joe has always been helpful and responsive to the community over Twitter, and we wish him a good break and safe return! 🚣</p>
<p>Speaking of Joe, <a href="https://www.youtube.com/watch?v=Ntj8ab-5cvE">his former intern</a> <a href="https://twitter.com/clattner_llvm/status/877341760812232704">Chris Lattner</a> (who you might have heard of) is back on the job market. While he has an impressive <a href="https://twitter.com/clattner_llvm/status/877353276676612102">seven years of Swift experience</a>, I suspect most companies will be looking for someone with ten. <code class="language-plaintext highlighter-rouge">¯\_(ツ)_/¯</code></p>
<p>Now that Xcode 9 and Swift 4 are in beta, it’s good to look back at all the proposals that made it into the language. Check out <a href="https://www.raywenderlich.com/163857/whats-new-swift-4">What’s New in Swift 4?</a> by <a href="https://twitter.com/ecerney">Eric Cerney</a> for an excellent summary.</p>
<p><a href="https://twitter.com/aciidb0mb3r/status/877653585844031493">Ankit Aggarwal</a> wrote a post on the Swift blog, <a href="https://swift.org/blog/swift-package-manager-manifest-api-redesign/">Swift Package Manager Manifest API Redesign</a>, describing the new manifest API. Swift package descriptions are written in Swift, and the new API / format now follows the language design guidelines.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Philippe Hausler <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037499.html">noted some feedback</a> about <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md">SE-0170: NSNumber bridging and Numeric types</a> with respect to floats and doubles. If you’ve been burned by floating-point precision in the past, check out <a href="https://github.com/apple/swift/commit/c358afe6555e5e32633e879f96a3664dc7a5f3dc">the commit helping “Double and Float bridges to be more lenient”</a>.</p>
<p>The Swift migrator library was merged into the repository! At its core, the migrator takes a source file as input and producs a <em>remap file</em> describing the proposed changes. Check out all the details in the <a href="https://github.com/apple/swift/tree/master/lib/Migrator">Swift migrator library</a> folder.</p>
<p>Everyone’s favorite Swift 4 protocol <code class="language-plaintext highlighter-rouge">Encodable</code> <a href="https://github.com/apple/swift/pull/10321">gets some upgrades</a> to support non-strong (weak, unowned, unmanaged) properties.</p>
<p>The second bug ever filed in the Swift issue tracker has been fixed! 🎉 <a href="https://bugs.swift.org/browse/SR-2">SR-2</a> and <a href="https://bugs.swift.org/browse/SR-4196">SR-4196</a> describe how wrapping switch cases in conditional <code class="language-plaintext highlighter-rouge">#if</code>/<code class="language-plaintext highlighter-rouge">#endif</code> blocks doesn’t work properly, and this has been <a href="https://github.com/apple/swift/pull/9457/commits/5d478bdb3b7638f5df6f0e1f4e574bececae9b80">fixed in a recent commit</a>.</p>
<p>Xcode 9 lets you Sanitize All The Things with the new <a href="https://developer.apple.com/documentation/code_diagnostics/undefined_behavior_sanitizer">Undefined Behavior Sanitizer</a> and the <a href="https://developer.apple.com/documentation/code_diagnostics/main_thread_checker">Main Thread Checker</a> joining the existing address sanitizer and thread sanitizer. Code for these new features was <a href="https://github.com/apple/swift-lldb/pull/211/commits">merged into swift-lldb</a>, so have a look at how they work if you’re curious. 🔍</p>
<h3 id="proposal-news">Proposal news</h3>
<p>Following up on a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015920.html">post from last year</a>, <a href="https://github.com/erica">Erica Sadun</a> and associates <a href="https://github.com/AliSoftware">Olivier Halligon</a>, <a href="https://github.com/calebd">Caleb Davenport</a>, and <a href="https://github.com/KingOfBrian">Brian King</a> submitted a <a href="https://github.com/erica/swift-evolution/blob/2f2778797ceb9edc0b8acd3b68af5f81f9a95775/proposals/XXXX-role-keywords.md">draft proposal to add “role keywords”</a> for protocol extension methods.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a> was meant to make obvious the difference between multiple parameters to a function <code class="language-plaintext highlighter-rouge">(String, Int)</code> and a single tuple parameter <code class="language-plaintext highlighter-rouge">(String, Int)</code>. They sure do look the same, don’t they? As Doug Gregor noted on the mailing list, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170619/037616.html">this change to the compiler led to some complications</a>:</p>
<blockquote>
<p>Swift 4 implemented more of SE-0110, which caused a fairly serious usability regression, particularly with closures.</p>
<p>[…]</p>
<p>The Swift core team feels that these usability regressions are unacceptable for Swift 4. There are a number of promising solutions that would provide a better model for closures and address the usability regression, but fully designing and implementing those are out of scope for Swift 4. Therefore, we will “back out” the SE-0110 change regarding function arguments from Swift 4.</p>
</blockquote>
<p>No one can tell the future and it’s hard to know the effect of a proposal on all the Swift code out there in the world — but that’s why we have snapshot builds and betas. As for the <a href="http://ericasadun.com/2017/06/20/more-on-se-0110-important-fallout-please-read/">fallout around SE-0110</a>, I think we all join the community in encouraging contributor <a href="https://twitter.com/austinzheng/status/877054901620101120">Austin Zheng</a> to stick around. ❤️</p>
<p>No new proposals but as always, you can check out the <a href="https://apple.github.io/swift-evolution/">Swift Evolution status page</a> for all the details.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Remember <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104: Protocol-oriented integers</a>? <a href="https://github.com/xwu">Xiaodi Wu</a> posted some <a href="https://gist.github.com/xwu/d68baefaae9e9291d2e65bd12ad51be2">thoughtful notes and suggestions</a> on improving the implementation.</p>
<p>Halen Wooten kicked off a <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170619/004829.html">great thread on swift-dev</a> on how to be an effective contributor. I know the mailing list interface can be a bit gnarly, but check out <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170619/thread.html#4829">the entire thread</a> for some good tips. From <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170619/004833.html">documentation</a> to <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170619/004835.html">avoiding clean builds to save time</a>, I hope these tips get collected into some kind of <em>Getting Started</em> guide?</p>
<h3 id="finally">Finally</h3>
<p>What kind of language would <em>you</em> build after learning the lessons of Swift? <a href="https://twitter.com/slava_pestov/status/875150641269571584">A very simple one</a>, <a href="https://twitter.com/slava_pestov/status/875153089174446080">perhaps even without access control</a>? 😱</p>
Issue #74
https://swiftweeklybrief.com/issue-74
2017-06-15T00:00:00-07:00
2017-06-15T00:00:00-07:00
Ben Asher
https://twitter.com/benasher44
https://github.com/benasher44.png?size=100
benasher44
<p>It has been a week since WWDC; have you had a chance to see what your Swift 4 upgrade path looks like yet? Mine started with an increase in redundant protocol conformance warnings, and I found one <a href="https://bugs.swift.org/browse/SR-5153">minor regression</a>. That said, it has been pretty smooth so far, especially compared to the two weeks I spent on the Swift 3 upgrade last year!</p>
<p>Also, keep in mind that Swift 3.2 is the Swift 4 compiler running in Swift 3 compatibility mode (<code class="language-plaintext highlighter-rouge">-swift-version 3</code>, which clicked for me sometime during WWDC 😅). Understanding this can be really helpful when putting together a ticket for <a href="https://bugs.swift.org">bugs.swift.org</a>.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-4866">SR-4866</a>: Stack overflow: Parsing phony empty paren expressions</li>
<li><a href="https://bugs.swift.org/browse/SR-4830">SR-4830</a>: Propagate colors from compiler output</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 15: <a href="https://spec.fm/podcasts/swift-unwrapped/70809">What’s New in Swift 4, Part 2</a></p>
<p>JP Simard and Jesse Squires continue their discussion on what to expect with Swift 4.</p>
<h3 id="news-and-community">News and community</h3>
<p>John Sundell <a href="https://www.swiftbysundell.com/posts/exploring-the-new-string-api-in-swift-4">wrote about the new Swift 4 <code class="language-plaintext highlighter-rouge">String</code> APIs</a>. The post includes lots of useful examples that show where you might start using them in your day-to-day Swift.</p>
<p>Slava Pestov proposed a <a href="https://twitter.com/slava_pestov/status/873751462630760449">Swift puzzle on Twitter</a>: <em>What does this output and why?</em> <code class="language-plaintext highlighter-rouge">print(type { })</code> (<a href="https://twitter.com/nicklockwood/status/873796388768841728">answer here</a>)</p>
<p>Slava <a href="https://twitter.com/slava_pestov/status/873744097353256961">also highlighted</a> that the Swift compiler team has fixed <strong>more than 5,500 crashers</strong> since <a href="https://github.com/apple/swift/commit/d8ce0b80cbb7732cb32b245f9fadd47c11a4b163">this commit in 2014</a>. 🎉</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/10195">fixed a bug in Swift 4 and 3.1</a> related to superclass initializer delegation where Swift might incorrectly reject a <code class="language-plaintext highlighter-rouge">self.init</code> call as an escaping use of <code class="language-plaintext highlighter-rouge">self</code> for certain kinds of superclass initializers.</p>
<p>Devin Coughlin continued work on Swift 4 memory exclusivity by <a href="https://github.com/apple/swift/pull/10191">adding analysis for <code class="language-plaintext highlighter-rouge">inout</code> params</a>.</p>
<p>Nate Cook made <a href="https://github.com/apple/swift/pull/10229">lots of documentation revisions</a> for the Swift 4 stdlib.</p>
<p>Dave Abrahams opened a PR with some <a href="https://github.com/apple/swift/pull/10223">performance optimizations for <code class="language-plaintext highlighter-rouge">String</code></a>.</p>
<p>Roman Levenstein <a href="https://github.com/apple/swift/pull/10263">cherry-picked a patch</a> from master to the Swift 4 branch that reduces the standard library code size by about 5-6 percent.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week! Check the <a href="https://apple.github.io/swift-evolution/">status page for details</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>There is some discussion about the role of the Swift Evolution mailing lists as it relates to promoting useful discussion and review of proposals and, given how this is guided by the Swift release cycle/stages, how one should bring up ideas for serious discussion that may not be “in-scope” for current release stage.</p>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037339.html">writes</a>:</p>
<blockquote>
<p>Everyone: this is a great thread, and I appreciate the candid thoughts here. This is something Ben Cohen and I started chatting about offline and we’ll definitely bring it up for discussion with the rest of the Core Team.</p>
<p>[…]</p>
<p>Getting to Xiaodi’s observation, the evolution list is really the most effective as a working list for bringing forward in-scope proposals. There’s a ton of different topics people want to talk about — and their is some obvious angst about getting to those — but at the end of the day there is only so much bandwidth from everyone to pay attention to these discussions and to get seriously invested in them. Maybe moving to Discourse (which is something we still want to do, but have had limited bandwidth to implement) will provide the “off-list” communication channels analogous to the ones Xiaodi describes that keeps those discussions in the Swift.org discussion forums but clearly separates discussion for in-scope proposals versus the side discussions people want to have on topics they are interested in.</p>
<p>[…]</p>
</blockquote>
<p>If you’re interested in the future of Swift Evolution, this is a worthwhile read about how the process has served to promote useful discussion around “in-scope” ideas and how it needs improvement when it comes to discussing ideas that may not fit into the current Swift release stage.</p>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution//Week-of-Mon-20170612/037514.html">responded to an ongoing thread</a> about revisiting <a href="https://lists.swift.org/pipermail/swift-evolution//Week-of-Mon-20170612/037514.html">SE-0110</a>:</p>
<blockquote>
<p>We discussed this in the core team meeting today. Consensus seems to be that a change needs to be made to regain syntactic convenience here. Discussion was leaning towards allowing (at least) the parenthesized form, but more discussion is needed.</p>
<p>One (tangential) thing that came up is that tuple element names in tuple <em>patterns</em> should probably be deprecated and removed at some point. Without looking, what variables does this declare?:</p>
<p><code class="language-plaintext highlighter-rouge">let (a : Int, b : Float) = foo()</code></p>
<p>?</p>
</blockquote>
<p>We covered this back in <a href="https://swiftweeklybrief.com/issue-72/">issue #72</a>. In Swift 4, N-ary tuples are no longer expanded to N arguments in a closure (the “tuple splat behavior”). This means closures will receive a single tuple parameter and you’ll have to expand them manually. This has (obviously) proved to be much less ergonomic and poorer developer experience. It’s nice to see the Core Team reconsider this change! And who said swift-evolution wasn’t great? 😉</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/jckarter/status/874397984712163331">A few words</a> for Swift 2 🍺.</p>
Issue #73
https://swiftweeklybrief.com/issue-73
2017-06-09T00:00:00-07:00
2017-06-09T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Wow, what a week! Today is the final day of <a href="https://developer.apple.com/videos/wwdc2017/">WWDC 2017</a>. Swift 4, which is bundled with <a href="https://developer.apple.com/xcode/">Xcode 9</a>, has been released in its first developer beta. Xcode and Swift both have a number of huge improvements and new features — it’s a fantastic release. So far, the <a href="https://twitter.com/ericasadun/status/871819962888802304">community</a> <a href="https://twitter.com/SmileyKeith/status/871852588844556288">response</a> <a href="https://twitter.com/fpillet/status/871987276187828224">has</a> <a href="https://twitter.com/chriseidhof/status/873066951739703296">been</a> <a href="https://twitter.com/tonyarnold/status/873017116298846208">really</a> <a href="https://twitter.com/ayanonagon/status/871850052498489344">positive</a>. Congrats to the Xcode, Swift, and dev tools teams at Apple!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 14: <a href="https://spec.fm/podcasts/swift-unwrapped/70808">What’s new in Swift, Part 1</a></p>
<p>We discuss some of the new features and improvements in Swift 4!</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple <a href="https://www.apple.com/newsroom/2017/06/swift-playgrounds-expands-coding-education-to-robots-drones-and-musical-instruments/">announced</a> that Swift Playgrounds is gaining support for programming toy robots and drones. They are partnering with a number of companies, like Lego, Sphero, and many more. This is pretty amazing and looks super fun. You can find a <a href="https://www.youtube.com/watch?v=v7926MzvXOQ">video here</a>.</p>
<p>Erica Sadun’s book, <a href="http://ericasadun.com/2017/06/01/swift-style-wwdc-sale/">Swift Style</a>, is on sale this week.</p>
<p>objc.io has released a new book, <a href="https://www.objc.io/blog/2017/06/02/optimizing-collections/">Optimizing Collections</a>. Written by <a href="https://twitter.com/lorentey">Károly Lőrentey</a>, the book is about writing very efficient custom collections in Swift.</p>
<p><a href="https://developer.apple.com/news/?id=06052017d">Xcode 9 beta and new SDKs</a> have been released.</p>
<h3 id="wwdc-videos-on-swift">WWDC videos on Swift</h3>
<ul>
<li><a href="https://developer.apple.com/videos/play/wwdc2017/402/">What’s new in Swift</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2017/408/">What’s new in Swift Playgrounds</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2017/416/">Teaching with Swift Playgrounds</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2017/212/">What’s new in Foundation</a></li>
<li><a href="https://developer.apple.com/videos/play/wwdc2017/407/">Understanding undefined behavior</a></li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/10175">merged changes</a> to fix some undefined behavior — fixed using Xcode’s new undefined behavior sanitizer (UBSan).</p>
<p>Roman Levenstein <a href="https://github.com/apple/swift/pull/10096">make some minor tweaks</a> to reduce the code size of the Standard Library by 1.5 percent!</p>
<p>The Swift Server APIs Working Group has <a href="https://github.com/swift-server/http">published a new repository</a> for the development of cross-platform HTTP APIs.</p>
<p>Ben Cohen <a href="https://github.com/apple/swift/pull/10161">requested a pick</a> in the <code class="language-plaintext highlighter-rouge">swift-4.0-branch</code> for his substring comparison performance improvements. Nate Cook <a href="https://github.com/apple/swift/pull/10156">also picked</a> some dictionary improvements into <code class="language-plaintext highlighter-rouge">swift-4.0-branch</code>. There have been <a href="https://github.com/apple/swift/pulls?utf8=✓&q=is%3Apr%20%5B4.0%5D%20in%3Atitle">a number of picks</a> into Swift 4 already, hopefully the others that have been requested make it in soon. We should see these improvements in the upcoming betas.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/10162">fixed</a> a handful of crashers. 👏</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">SE-0180</a>: <em>String Index Overhaul</em> by Dave Abrahams is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-June/000384.html">under review</a></p>
<blockquote>
<p>Today <code class="language-plaintext highlighter-rouge">String</code> shares an <code class="language-plaintext highlighter-rouge">Index</code> type with its <code class="language-plaintext highlighter-rouge">CharacterView</code> but not with its <code class="language-plaintext highlighter-rouge">UTF8View</code>, <code class="language-plaintext highlighter-rouge">UTF16View</code>, or <code class="language-plaintext highlighter-rouge">UnicodeScalarView</code>. This proposal redefines <code class="language-plaintext highlighter-rouge">String.UTF8View.Index</code>, <code class="language-plaintext highlighter-rouge">String.UTF16View.Index</code>, and <code class="language-plaintext highlighter-rouge">String.CharacterView.Index</code> as typealiases for <code class="language-plaintext highlighter-rouge">String.Index</code>, and exposes a public <code class="language-plaintext highlighter-rouge">encodedOffset</code> property and initializer that can be used to serialize and deserialize positions in a <code class="language-plaintext highlighter-rouge">String</code> or <code class="language-plaintext highlighter-rouge">Substring</code>.</p>
<p>[…]</p>
<p>The result is a great deal of API surface area for apparently little gain in ordinary code, that normally only interchanges indices among views when the positions match up exactly (i.e. when the conversion is going to succeed). Also, the resulting code is needlessly awkward.</p>
<p>[…]</p>
<p>All <code class="language-plaintext highlighter-rouge">String</code> views will use a single index type (<code class="language-plaintext highlighter-rouge">String.Index</code>), so that positions can be interchanged without awkward explicit conversions.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0180-string-index-overhaul.md">Continue reading…</a></p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170605/004751.html">sent out an update</a> about the to-be-open-sourced refactoring tools and other announcements at WWDC:</p>
<blockquote>
<p>This afternoon at WWDC we announced a new refactoring feature in Xcode 9 that supports Swift, C, Objective-C, and C++. We also announced we will be open sourcing the key parts of the engine that support file-level transformations, as well as the compiler pieces for the new index-while-building feature in Xcode.</p>
<p>We will be releasing the sources in stages, likely over the next few weeks:</p>
<ul>
<li>For the refactoring support for Swift, there are some cleanups we’d like to do as well as some documentation we’d like to author before we push these sources back. Argyrios Kyrtzidis and his team from Apple will be handling that effort.</li>
<li>For the refactoring support for C/C++/Objective-C, these are changes we’d like to work with the LLVM community to upstream to the LLVM project. These will likely be first staged to the swift-clang repository on GitHub, but that is not their intended final destination. Duncan Exon Smith and his team from Apple will be handling that effort.</li>
<li>We’ll also be open sourcing the compiler support for indexing-while-building, which include changes to both Clang and Swift. Argyrios and his team will be driving that effort. For the clang changes they will likely be first staged to swift-clang, and then discussed with the LLVM community to upstream them to mainline Clang.</li>
<li>Finally, we will be open sourcing the remaining pieces of the Swift migrator. Argyrios and his team will be handling the push back of changes there, and those changes will only be impacting the swift repository.</li>
</ul>
<p>As usually, we’ll also be pushing back changes to have Swift work with the latest Apple SDKs. We’re expecting that push back to happen early next week. When that happens we will temporarily lock commit access to the repositories. Details about that will be sent out later in a later email. Until then, the downloadable toolchains from Swift.org will continue to work with Xcode 8.3.2. After we do the push back the downloadable toolchains will be moved to be baselined on the Xcode 9.0 betas. This shift is necessary as changes to the overlays depend on the latest SDKs.</p>
</blockquote>
<p>Rick Ballard <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170605/037002.html">sent out an update</a> on the Swift 4 package manager:</p>
<blockquote>
<p>Hello Swift Package Manager community,</p>
<p>I’d like to give you an update on the state of SwiftPM in Swift 4. We’ve implemented a number of evolution proposal this Spring:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md">SE-0152</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md">SE-0158</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md">SE-0151</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md">SE-0146</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md">SE-0175</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md">SE-0150</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md">SE-0162</a> […]</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md">SE-0149</a> […]</li>
</ul>
<p>In addition to these proposals, we’ve made other significant improvements:</p>
<ul>
<li>On macOS, package manifest interpretation and the package build are now sandboxed, to help mitigate the effects of maliciously crafted manifests.</li>
<li>Many error messages and diagnostics have been improved, including information about conflicts during dependency resolution.</li>
<li>Xcode project generation has been improved, and now allows schemes to reference package targets across regenerations of the project.</li>
<li>There have been a host of smaller improvements and bugfixes.</li>
</ul>
<p>Xcode 9 lays the groundwork for first-class, native support in Xcode for Swift packages with the preview version of its new build system. This build system provides the flexibility and extensibility needed to allow Xcode to support new build models, such as Swift packages. Additionally, considerable work has gone into the SwiftPM library vended by the SwiftPM project, which will support integrating Swift packages into tools like Xcode.</p>
<p>So what’s left in SwiftPM 4? First, we will be implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md">SE-0179</a>, support for a <code class="language-plaintext highlighter-rouge">swift package run</code> command. Beyond that, we expect to start winding down this release and looking ahead to the next, though we are still open to suggestions or evolution proposals for modest features and fixes.</p>
<p>[…]</p>
<p>Other features we will likely consider for the next release cycle include support for package resources (such as image assets), license and metadata support, explicit support for handling source control forking, and a generic mechanism for invoking build tools that the package manager doesn’t natively support. Finally, we do anticipate supporting a centralized package index at some point in the future, and we may begin laying the groundwork for that in the upcoming year.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170605/037002.html">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/NeoNacho/status/871143591258734594">self storage</a>.</p>
Issue #72
https://swiftweeklybrief.com/issue-72
2017-06-01T00:00:00-07:00
2017-06-01T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>We are only a few days away from <a href="https://www.apple.com/apple-events/june-2017/">WWDC 2017</a>! This week the Swift repository saw its <a href="https://github.com/apple/swift/pull/10000">10,000th pull request</a>. Things have been more quiet than usual, but we did get a great update to the <a href="https://twitter.com/simjp/status/869636941402128384">WWDC iOS app</a>. 😅 I did not get a ticket, but I will be hanging out in San Jose for most of the week — if you are attending it would be great to meet in person! Aside from WWDC, there are a number of other events happening. For the Swift community, check out <a href="https://www.eventbrite.com/e/wwdc-2017-swift-panel-tickets-34611623297">Realm’s WWDC Swift Panel</a> and the <a href="https://swiftcoders.eventfarm.com/">SwiftCoders meet & greet at AltConf</a>. See you next week!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-5018">SR-5018</a>: Mark <code class="language-plaintext highlighter-rouge">+new</code> as <code class="language-plaintext highlighter-rouge">SWIFT_UNAVAILABLE</code> when <code class="language-plaintext highlighter-rouge">-init</code> is <code class="language-plaintext highlighter-rouge">SWIFT_UNAVAILABLE</code>.</li>
<li><a href="https://bugs.swift.org/browse/SR-4949">SR-4949</a>: No error for using <code class="language-plaintext highlighter-rouge">as</code> patterns with CoreFoundation types</li>
</ul>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 13: <a href="https://spec.fm/podcasts/swift-unwrapped/70310">WWDC Predictions</a></p>
<p>This week, we share our hopes and expectations for the Swift language at WWDC 2017!</p>
<h3 id="news-and-community">News and community</h3>
<p>Caleb Davenport <a href="https://twitter.com/calebd/status/867739062706286592">highlighted</a> a somewhat undesirable change coming in Swift 4. Due to proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a> (but really <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md">SE-0029</a>), N-ary tuples are no longer expanded to N arguments in a closure (the “tuple splat behavior”). This means closures will receive a single tuple parameter and you’ll have to expand them manually. Joe Groff <a href="https://twitter.com/jckarter/status/867750246935216128">noted</a> that this was a source of bad type-checker performance and <a href="https://twitter.com/jckarter/status/867766410172182528">sympathized</a> about rolling back this syntactic sugar.</p>
<p>In a recent episode of the SwiftCoders podcast, Garric Nahapetian <a href="https://swiftcoders.podbean.com/?p=7021942">interviews Robert Widmann</a> (aka <a href="https://twitter.com/CodaFi_">@CodaFi_</a>), a Swift compiler intern and Swift open source contributor.</p>
<p>Apple have released a free, beginner-level, 900 page book <a href="https://itunes.apple.com/us/book/app-development-with-swift/id1219117996?mt=11">“App Development with Swift”</a> and <a href="https://itunes.apple.com/us/book/app-development-with-swift/id1219118093?mt=11">related teaching materials</a>. In total, it looks like there are 2 books and 5 teacher guides in the series. Hat tip <a href="https://twitter.com/cocoawithlove/status/869514258265980929">@cocoawithlove</a>.</p>
<p>Thanks to <a href="https://twitter.com/simjp">JP Simard</a> for showing me a Swift IDE for macOS called <a href="https://robotaryapp.com">Robotary</a>, which you can use to program <a href="http://www.lego.com/en-us/mindstorms/products/mindstorms-ev3-31313">LEGO MINDSTORMS EV3</a> robots. It’s been around for some time and hasn’t been updated since last September, but it looks pretty cool. 😎 Also — lego robots. 😱</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Dave Abrahams opened a <a href="https://github.com/apple/swift/pull/9806">pull request</a> with his overhaul changes to <code class="language-plaintext highlighter-rouge">String.Index</code>. See the mailing list section below for details on the proposal.</p>
<p>Amr Aboelela <a href="https://github.com/apple/swift/pull/9785">wrote</a> a <code class="language-plaintext highlighter-rouge">build-toolchain</code> script for Android, similar to the <a href="https://github.com/apple/swift/blob/master/utils/build-toolchain">existing</a> <code class="language-plaintext highlighter-rouge">build-toolchain</code> script for Darwin. This should be useful for anyone experimenting with Swift on Android.</p>
<p>Ben Cohen <a href="https://github.com/apple/swift/pull/10030">added</a> benchmarks for equating/comparing substrings.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md">SE-0179</a>: <em>Swift <code class="language-plaintext highlighter-rouge">run</code> Command</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000383.html">accepted with revisions</a>.</p>
<blockquote>
<p>The proposal has been accepted with revision for Swift 4. There was unanimous support for the proposal in general, but there was discussion on three major points:</p>
<ol>
<li>The utility of having both “run – …” and “run command arg1 arg2” forms.</li>
<li>Whether to build by default.</li>
<li>The confusion of having two commands which “change the working directory’.</li>
</ol>
<p>1) The <code class="language-plaintext highlighter-rouge">--</code> command syntax.</p>
<p>We decided we will not support the: <code class="language-plaintext highlighter-rouge">swift run -- arg1 arg2 arg3</code> syntax, for packages with only one executable, because we felt it was not sufficiently useful versus spelling the command name, and we didn’t want to unnecessarily have two ways to do the same thing. This behavior would be additive if it proved to be worth adding down the road.</p>
<p>We will support the no argument <code class="language-plaintext highlighter-rouge">swift run</code> form in the proposal, since it is unambiguous.</p>
<p>2) Whether to build by default.</p>
<p>This behavior is consistent with our existing behavior for <code class="language-plaintext highlighter-rouge">swift test</code>, and so we believe this is the correct behavior for this proposal.</p>
<p>3) The confusion over the <code class="language-plaintext highlighter-rouge">--chdir</code> and <code class="language-plaintext highlighter-rouge">--in-dir</code> arguments.</p>
<p>We agreed with the feedback that this was confusing, and so decided to:</p>
<ul>
<li>Rename the existing <code class="language-plaintext highlighter-rouge">--chdir</code> argument to <code class="language-plaintext highlighter-rouge">--package-path</code> and change it to simply define the package to work on instead of as a side effect of changing directories. We chose –package-path over –package to leave room for <code class="language-plaintext highlighter-rouge">--package <NAME></code> syntax in the future, should we have an index. We will make this change and deprecate <code class="language-plaintext highlighter-rouge">--chdir</code> in Swift 4, and remove it at a later date.</li>
<li>Remove the <code class="language-plaintext highlighter-rouge">--in-dir</code> argument, and instead leave it up to commands themselves to manage interaction with the working directory.</li>
<li>Explicitly specify the behavior of <code class="language-plaintext highlighter-rouge">swift run</code> to always execute the command in the directory from with <code class="language-plaintext highlighter-rouge">swift run</code> was run.</li>
</ul>
<p>In combination, these choices allow <code class="language-plaintext highlighter-rouge">swift run foo ...</code> to generally behave as it would if the package’s products had been built, installed, and run via the shell normally. We believe this allows <code class="language-plaintext highlighter-rouge">swift run ...</code> to integrate with the shell as naturally as possible.</p>
<p>Thank you to everyone who participated!</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p>There was no email on the lists, but <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0177-add-clamped-to-method.md">SE-0177</a>: <em>Add <code class="language-plaintext highlighter-rouge">clamp(to:)</code> to the stdlib</em> was <a href="https://github.com/apple/swift-evolution/commit/27848f930e25feaeeea0188fc34c926181a5b82e#diff-4987d3dddf79dfdceaa0718c5fd2ecac">returned for revision</a>. Given that this hasn’t been communicated to swift-evolution (a review never started in the first place), my guess is that this is simply out-of-scope for Swift 4. That, or everyone is too busy preparing for WWDC. 😅</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Dave Abrahams <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/036839.html">pitched a proposal</a> to overhaul <code class="language-plaintext highlighter-rouge">String.Index</code>. You can find the <a href="https://github.com/dabrahams/swift-evolution/blob/string-index-overhaul/proposals/NNNN-string-index-overhaul.md">draft here</a> and the <a href="https://github.com/apple/swift/pull/9806">pull request here</a> that implements the changes!</p>
<blockquote>
<p>Today <code class="language-plaintext highlighter-rouge">String</code> shares an <code class="language-plaintext highlighter-rouge">Index</code> type with its <code class="language-plaintext highlighter-rouge">CharacterView</code> but not with its <code class="language-plaintext highlighter-rouge">UTF8View</code>, <code class="language-plaintext highlighter-rouge">UTF16View</code>, or <code class="language-plaintext highlighter-rouge">UnicodeScalarView</code>. This proposal redefines <code class="language-plaintext highlighter-rouge">String.UTF8View.Index</code>, <code class="language-plaintext highlighter-rouge">String.UTF16View.Index</code>, and <code class="language-plaintext highlighter-rouge">String.CharacterView.Index</code> as typealiases for <code class="language-plaintext highlighter-rouge">String.Index</code>, and exposes a public <code class="language-plaintext highlighter-rouge">encodedOffset</code> property and initializer that can be used to serialize and deserialize positions in a <code class="language-plaintext highlighter-rouge">String</code> or <code class="language-plaintext highlighter-rouge">Substring</code>.</p>
<p>[…]</p>
<p>The result is a great deal of API surface area for apparently little gain in ordinary code, that normally only interchanges indices among views when the positions match up exactly (i.e. when the conversion is going to succeed). Also, the resulting code is needlessly awkward.</p>
<p><a href="https://github.com/dabrahams/swift-evolution/blob/string-index-overhaul/proposals/NNNN-string-index-overhaul.md">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/SwiftMonads/status/869992691358089216">we cannot be trusted with state</a>.</p>
Issue #71
https://swiftweeklybrief.com/issue-71
2017-05-25T00:00:00-07:00
2017-05-25T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Things have certainly been more quiet than usual as we approach <a href="https://developer.apple.com/wwdc">WWDC</a>. Discussions on the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170522/thread.html">mailing lists</a> (and even Twitter!) have been sparse. Only <a href="https://apple.github.io/swift-evolution/">two proposals</a> are awaiting or actively in review and it’s unlikely we’ll see any more proposals for Swift 4.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-4949">SR-4949</a>: No error for using <code class="language-plaintext highlighter-rouge">as</code> patterns with CoreFoundation types</li>
<li><a href="https://bugs.swift.org/browse/SR-4824">SR-4824</a>: Add tests to check <code class="language-plaintext highlighter-rouge">Collection</code> constraints are being enforced</li>
<li><a href="https://bugs.swift.org/browse/SR-4595">SR-4595</a>: Tests generate lots of warnings</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 12: <a href="https://spec.fm/podcasts/swift-unwrapped/69638">Swift Evolution</a></p>
<p>We debate if Swift evolution is pulling its weight, and if it’s possible for Swift to remain “open” without the cost.</p>
<h3 id="news-and-community">News and community</h3>
<p>Erica Sadun wrote about <a href="http://ericasadun.com/2017/05/23/5-easy-dispatch-tricks/">5 Easy Dispatch Tricks</a> in Swift. There are some great tips here to improve your experience with Swift Dispatch.</p>
<p>David Owens released and is continuing development on a Swift implementation of the Language Server Protocol spec. Find it <a href="https://github.com/owensd/swift-lsp">on GitHub</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>George Karpenkov <a href="https://github.com/apple/swift/pull/9450">added</a> support for the <code class="language-plaintext highlighter-rouge">-sanitize=fuzzer</code> flag. Similarly to Clang, the flag enables coverage instrumentation, and links <code class="language-plaintext highlighter-rouge">libLLVMFuzzer.a</code> to the produced binary. You can learn more about LLVM’s libFuzzer on the <a href="http://blog.llvm.org/2015/04/fuzz-all-clangs.html">LLVM blog</a> and at the <a href="http://llvm.org/docs/LibFuzzer.html">libFuzzer docs</a>. Pretty cool!</p>
<p>Itai Ferber <a href="https://github.com/apple/swift/pull/9791">merged</a> changes and enhancements to the new <code class="language-plaintext highlighter-rouge">Codable</code> APIs. This is part of the work for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a>.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/9925">fixed a bug</a> where <code class="language-plaintext highlighter-rouge">lazy</code> properties could become stored <a href="https://github.com/apple/swift/pull/9920">and another</a> where they required an explicit <code class="language-plaintext highlighter-rouge">self</code>.</p>
<p>Dave Abrahams <a href="https://github.com/apple/swift/pull/9924">added</a> substring comparison benchmarks.</p>
<p>Not new, but just recently merged, Johannes Weiß <a href="https://github.com/apple/swift-corelibs-foundation/pull/873">added support</a> to statically build corelibs-foundation.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week! Check the <a href="https://apple.github.io/swift-evolution/">status page for details</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>It might be hard to believe but not much has happened on swift-evolution or the other lists this week. I’m starting to worry about what I’m going to write for next week’s issue! 😅</p>
<h3 id="finally">Finally</h3>
<p>And finally — WWDC is approaching. <a href="https://twitter.com/EverythingGoats/status/864679358123962368">Goats to stay calm</a>.</p>
Issue #70
https://swiftweeklybrief.com/issue-70
2017-05-19T00:00:00-07:00
2017-05-19T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>What’s better than one issue of Swift Weekly Brief? Two, of course! My apologies for the confusion and bugs with the mailing list this week! Things are back on track now. So enjoy this special Friday edition!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 11: <a href="https://spec.fm/podcasts/swift-unwrapped/69191">Ownership Manifesto</a></p>
<p>This week we dive into the Ownership manifesto and give a brief overview of the complex topic of memory ownership revisions currently underway.</p>
<h3 id="news-and-community">News and community</h3>
<p>Benjamin Encz <a href="http://blog.benjamin-encz.de/post/simple-undo-redo-swift/">wrote an article</a> on implementing an undo/redo stack in Swift using value types as an alternative to <code class="language-plaintext highlighter-rouge">NSUndoManager</code>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Tony Allevato has opened a <a href="https://github.com/apple/swift/pull/9619">pull request</a> to synthesize <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> for complex enums and structs. This is the implementation for his yet-to-be-reviewed <a href="https://github.com/apple/swift-evolution/pull/706">draft proposal</a>. This would reduce common <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> conformance code that developers must routinely write. It’s not clear if this will make it into Swift 4 as the proposal hasn’t even been assigned an SE number.</p>
<p>Slava Pestov <a href="https://twitter.com/slava_pestov/status/865473324679168000">fixed</a> a 3-year-old bug (<a href="https://bugs.swift.org/browse/SR-349">SR-349</a>) with 20 dupes. (<a href="https://github.com/apple/swift/pull/9765">PR #9765</a>)</p>
<p>Not only was <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0178-character-unicode-view.md">SE-0178</a> reviewed and accepted, but also already <a href="https://github.com/apple/swift/pull/9675">implemented</a> by Dave Abrahams.</p>
<p>Itai Ferber <a href="https://github.com/apple/swift/pull/9715">merged</a> changes to add <code class="language-plaintext highlighter-rouge">Codable</code> conformance to common Foundation types. This work is for proposals <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md">SE-176</a>: <em>Enforce Exclusive Access to Memory</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000378.html">accepted pending revision review</a>.</p>
<blockquote>
<p>This proposal has been accepted with revisions. Feedback was strongly positive. Some participants raised concern about the overhead of dynamic checking. The core team shares this concern but feels that there will be adequate opportunities later to make pragmatic decisions about when to enable dynamic checking.</p>
<p>Most of the proposal is accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The proposal implementors suggest adopting a stronger rule governing the use of non-escaping closures which will also allow Swift to make firm guarantees about the use of static enforcement when a variable does not escape. The core team tentatively supports this new rule but believes it is a substantial enough revision that it requires a separate review period.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0178-character-unicode-view.md">SE-0178</a>: <em>Add <code class="language-plaintext highlighter-rouge">unicodeScalars</code> property to <code class="language-plaintext highlighter-rouge">Character</code></em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000377.html">reviewed</a>:</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">Character</code> element type of <code class="language-plaintext highlighter-rouge">String</code> is currently a black box that provides
little functionality besides comparison, literal construction, and to be used
as an argument to <code class="language-plaintext highlighter-rouge">String.init</code>.</p>
<p>Many operations on <code class="language-plaintext highlighter-rouge">String</code> could be neatly/readably implemented as operations
on each character in the string, if <code class="language-plaintext highlighter-rouge">Character</code> exposed its scalars more
directly. Many useful things can be determined by examining the scalars in a
grapheme (for example is this an ASCII character?).</p>
</blockquote>
<p>And <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170515/036714.html">accepted</a>:</p>
<blockquote>
<p>The proposal is accepted without revision. The proposal was uncontentious both on swift-evolution and in the Core Team review.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md">SE-0163</a>: <em>String Revision: Collection Conformance, C Interop, Transcoding</em> by Ben Cohen and Dave Abrahams is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000376.html">under review</a>.</p>
<blockquote>
<p>This proposal is to implement a subset of the changes from the <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md">Swift 4
String
Manifesto</a>.</p>
<p>Specifically:</p>
<ul>
<li>Make <code class="language-plaintext highlighter-rouge">String</code> conform to <code class="language-plaintext highlighter-rouge">BidirectionalCollection</code></li>
<li>Make <code class="language-plaintext highlighter-rouge">String</code> conform to <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code></li>
<li>Create a <code class="language-plaintext highlighter-rouge">Substring</code> type for <code class="language-plaintext highlighter-rouge">String.SubSequence</code></li>
<li>Create a <code class="language-plaintext highlighter-rouge">StringProtocol</code> protocol to allow for generic operations over both types.</li>
<li>Consolidate on a concise set of C interop methods.</li>
<li>Revise the transcoding infrastructure.</li>
<li>Sink Unicode-specific functionality into a <code class="language-plaintext highlighter-rouge">Unicode</code> namespace.</li>
</ul>
<p>Other existing aspects of <code class="language-plaintext highlighter-rouge">String</code> remain unchanged for the purposes of this
proposal.</p>
</blockquote>
<p>As mentioned above, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md">SE-176</a>: <em>Enforce Exclusive Access to Memory</em> was accepted pending revisions. A <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000379.html">new review period</a> for only the revisions has started:</p>
<blockquote>
<p>Most of this proposal was previously accepted. An implementation issue has been discovered with the use of dynamic enforcement on inout parameters. The proposal implementors suggest adopting a stronger rule governing the use of non-escaping closures which will also allow Swift to make firm guarantees about the use of static enforcement when a variable does not escape. The core team tentatively supports this new rule but believes it is a substantial enough revision that it requires a separate review period.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0179-swift-run-command.md">SE-0179</a>: <em>Swift <code class="language-plaintext highlighter-rouge">run</code> Command</em> by David Hart is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000380.html">under review</a>.</p>
<blockquote>
<p>The proposal introduces a new <code class="language-plaintext highlighter-rouge">swift run</code> command to build and run an executable defined in the current package.</p>
<p>It is common to want to build and run an executable during development. For now, one must first build it and then execute it from the build folder.</p>
<p>To improve the development workflow, the proposal suggests introducing a new first-level <code class="language-plaintext highlighter-rouge">swift run</code> command that will build if necessary and then run an executable defined in the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ole Begemann <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170515/036731.html">shared</a> a Swift playground that he created to show off the new features in Swift 4. <a href="https://github.com/ole/whats-new-in-swift-4">Get it here</a>.</p>
<blockquote>
<p>The playground requires Swift 4 (duh!). You need to install the latest Swift 4.0 snapshot from <a href="https://swift.org/download/#snapshots">https://swift.org/download/#snapshots</a> and, after installing it, select the toolchain in Xcode.</p>
<p>I plan to keep the playground updated over the summer as more features get implemented.</p>
</blockquote>
<p>This is such a great idea and such an easy way to experiment with unreleased versions of Swift.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ericasadun/status/864659925863202817">Apple Smack Us</a>.</p>
Issue #69
https://swiftweeklybrief.com/issue-69
2017-05-11T00:00:00-07:00
2017-05-11T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>We’re less than a month away from WWDC. While the swift-evolution proposal train seems to finally be slowing down, it seems like the Swift team is just as busy as ever as the end of the Swift 4 release cycle approaches.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-4827">SR-4827</a>: Incorrect result resolving type for Objective-C block</li>
<li><a href="https://bugs.swift.org/browse/SR-4858">SR-4858</a>: <code class="language-plaintext highlighter-rouge">IndexPath.hashValue</code> broken on Linux</li>
<li><a href="https://bugs.swift.org/browse/SR-4824">SR-4824</a>: Add tests to check Collection constraints are being enforced</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 10: <a href="https://spec.fm/podcasts/swift-unwrapped/68158">The Variety Show</a></p>
<p>This week we discuss multi-line strings, reduce with inout, one-sided ranges, and more!</p>
<h3 id="news-and-community">News and community</h3>
<p>Sommer Panage discusses how to make writing UI code simpler with Swift in her talk, <a href="https://news.realm.io/news/sommer-panage-writing-your-ui-swiftly/">Writing Your UI Swiftly</a> from <a href="https://www.tryswift.co">try! Swift Tokyo 2017</a>. The video was posted last month, but I’ve finally got around to watching it! It’s really great, I highly recommend it.</p>
<p>Nate Cook also gave a great talk, <a href="https://news.realm.io/news/nate-cook-tryswift-tokyo-unsafe-swift-and-pointer-types/">Swift’s Pointy Bits: Unsafe Swift & Pointer Types</a>, at <a href="https://www.tryswift.co">try! Swift Tokyo 2017</a>. Nate explores and explains what “safety” really means in Swift. Again, this video isn’t extremely new, but I just watched it this week. Awesome talk.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Ben Cohen <a href="https://github.com/apple/swift/pull/9374">added</a> <code class="language-plaintext highlighter-rouge">Collection</code> constraints via protocol where clauses requiring <code class="language-plaintext highlighter-rouge">Indices</code> and <code class="language-plaintext highlighter-rouge">SubSequence</code> match the traversal. This resolved 8 ABI FIXMEs!</p>
<p>Robin Kunde <a href="https://github.com/apple/swift/pull/9070">merged</a> diagnostic notes and fixits for confusable unicode characters.</p>
<p>John McCall <a href="https://github.com/apple/swift/pull/9431">merged</a> refinements to dynamic exclusivity, continuing work outlined in the <a href="https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md">Ownership Manifesto</a>.</p>
<p>Michael Ilseman <a href="https://github.com/apple/swift/pull/9265">implemented</a> support for Unicode 9 grapheme breaking (i.e. emoji). Whatever that means. 😆</p>
<p>Jordan Rose opened a <a href="https://github.com/apple/swift/pull/9401">pull request</a> to make all CoreFoundation types conform to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> using <code class="language-plaintext highlighter-rouge">CFHash</code> and <code class="language-plaintext highlighter-rouge">CFEqual</code> as the implementation. This will be available in Swift 4, even when using “Swift 3 mode”.</p>
<p>Erik Eckstein <a href="https://github.com/apple/swift/pull/9353">merged</a> changes to allow <code class="language-plaintext highlighter-rouge">Character</code> literals that fit into 64 bits, be folded into a single integer constant. It makes character literals much faster (3x improvement for the CharacterLiteralsSmall benchmark) and it removes a lot of redundant code (~80% for the CharacterLiteralsSmall benchmark).</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md">SE-0174</a>: <em>Change <code class="language-plaintext highlighter-rouge">filter</code> to return an associated type</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000374.html">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted. Thank you to everyone who participated in the review!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md">SE-0175</a>: <em>Package Manager Revised Dependency Resolution</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000375.html">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted for Swift 4. Thank you to everyone who participated in the review!</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ben Cohen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170508/036582.html">pitched a draft proposal</a> to add a <code class="language-plaintext highlighter-rouge">unicodeScalar</code> view to <code class="language-plaintext highlighter-rouge">Character</code>, similar to that on <code class="language-plaintext highlighter-rouge">String</code>.</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">Character</code> element type of <code class="language-plaintext highlighter-rouge">String</code> is currently a black box that provides little functionality besides comparison, literal construction, and to be used as an argument to <code class="language-plaintext highlighter-rouge">String.init</code>.</p>
<p>Many operations on String could be neatly/readily implemented as operations on each character in the string, if <code class="language-plaintext highlighter-rouge">Character</code> exposed its scalars more directly. Many useful things can be determined by examining the scalars in a grapheme (for example is this an ASCII character?).</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/859114207077322752">ambiguous use of ‘abs’</a>.</p>
Issue #68
https://swiftweeklybrief.com/issue-68
2017-05-04T00:00:00-07:00
2017-05-04T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Quite a lot of work has been done to implement recently accepted Swift Evolution proposals, as well as improving their diagnostics and error messages. Interestingly, some of this work has been done by first-time contributors, which is amazing to see!</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 9: <a href="https://spec.fm/podcasts/swift-unwrapped/67089">String Manifesto</a></p>
<p>This week JP Simard and Jesse Squires discuss the String Manifesto!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/9090">implemented</a> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156</a>: <em>Class and Subtype existentials</em>.</p>
<p>Becca Royal-Gordon <a href="https://github.com/apple/swift/pull/9148">opened a pull request</a> to improve diagnostics for multi-line string literals (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">SE-0168</a>).</p>
<p>Brian King <a href="https://github.com/apple/swift/pull/9098">implemented</a> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md">SE-0169</a>: <em>Improve Interaction Between <code class="language-plaintext highlighter-rouge">private</code> Declarations and Extensions</em>. 🚀</p>
<p>Robert Widmann has redone <a href="https://github.com/apple/swift/pull/8908">exhaustiveness checking</a>, fixing a <em>lot</em> of SR-bugs in the process.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md">SE-0170</a>: <em>NSNumber bridging and Numeric types</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036226.html">accepted</a> for Swift 4.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md">SE-0173</a>: <em>Add <code class="language-plaintext highlighter-rouge">MutableCollection.swapAt(_:_:)</code></em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036229.html">accepted</a> with revisions and has also been implemented.</p>
<blockquote>
<p>The proposal is accepted, including the revision to change the method name from <code class="language-plaintext highlighter-rouge">swap(_:with:)</code> to <code class="language-plaintext highlighter-rouge">swapAt(_:_)</code> that came out of the Core Team meeting.</p>
<p>The consensus on <code class="language-plaintext highlighter-rouge">swift-evolution</code> was to add the method, with division mostly on the naming of the method. The Core Team reviewed the proposed options as well as consulted <a href="https://swift.org/documentation/api-design-guidelines/">the API design guidelines</a> to resolve the issue.</p>
<p>Two important points from the guidelines serve to us well here:</p>
<p>“Omit all labels when arguments can’t be usefully distinguished”</p>
<p>and:</p>
<p>“When the first argument forms part of a prepositional phrase, give it an argument label… An exception arises when the first two arguments represent parts of a single abstraction. In such cases, begin the argument label after the preposition, to keep the abstraction clear.”</p>
<p>The combination of these rules leads to the method name <code class="language-plaintext highlighter-rouge">swapAt(_:_:)</code>, which the Core Team believes was most in line with the guidelines.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0176-enforce-exclusive-access-to-memory.md">SE-0176</a>: <em>Enforce Exclusive Access to Memory</em> by John McCall is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000372.html">under review</a>.</p>
<blockquote>
<p>In Swift 3, it is possible to modify a variable while it’s being used or modified by another part of the program. This can lead to unexpected and confusing results. It also forces a great deal of conservatism onto the implementation of the compiler and the standard libraries, which must generally ensure the basic soundness of the program (no crashes or undefined behavior) even in unusual circumstances.</p>
<p>We propose that Swift should instead enforce a general rule that potential modifications of variables must be exclusive with any other access to that variable.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0174-filter-range-replaceable.md">SE-0174</a>: <em>Change <code class="language-plaintext highlighter-rouge">filter</code> to return an associated type</em> by Ben Cohen is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000370.html">under review</a>.</p>
<blockquote>
<p>This proposal changes the <code class="language-plaintext highlighter-rouge">filter</code> operation on <code class="language-plaintext highlighter-rouge">Sequence</code> to return an associated type, and adds a default implementation to <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code> to return the same type as the filtered collection.</p>
<p>The recently accepted <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md">SE-0165</a> introduced a version of <code class="language-plaintext highlighter-rouge">filter</code> on <code class="language-plaintext highlighter-rouge">Dictionary</code> that returned a <code class="language-plaintext highlighter-rouge">Dictionary</code>. This had both performance and usability benefits: in most cases, a <code class="language-plaintext highlighter-rouge">Dictionary</code> is what the user wanted from the filter, and creating one directly from the filter operation is much more efficient than first creating an array then creating a <code class="language-plaintext highlighter-rouge">Dictionary</code> from it.</p>
<p>However, this does result in some inconsistencies. Users may be surprised that this one specific collection returns <code class="language-plaintext highlighter-rouge">Self</code>, while other collections that would benefit from the same change still return <code class="language-plaintext highlighter-rouge">[Element]</code>. And some collections, such as <code class="language-plaintext highlighter-rouge">String</code>, might also benefit from usability and performance win similar to <code class="language-plaintext highlighter-rouge">Dictionary</code>. Additionally, these wins will be lost in generic code – if you pass a <code class="language-plaintext highlighter-rouge">Dictionary</code> into an algorithm that takes a <code class="language-plaintext highlighter-rouge">Sequence</code>, then when you filter it, you will still get an <code class="language-plaintext highlighter-rouge">Array</code>.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0175-package-manager-revised-dependency-resolution.md">SE-0175</a>: <em>Package Manager Revised Dependency Resolution</em> by Rick Ballard is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-May/000373.html">under review</a>.</p>
<blockquote>
<p>This proposal makes the package manager’s dependency resolution behavior clearer and more intuitive. It removes the pinning commands (<code class="language-plaintext highlighter-rouge">swift package pin</code> & <code class="language-plaintext highlighter-rouge">swift package unpin</code>), replaces the <code class="language-plaintext highlighter-rouge">swift package fetch</code> command with a new <code class="language-plaintext highlighter-rouge">swift package resolve</code> command with improved behavior, and replaces the optional <code class="language-plaintext highlighter-rouge">Package.pins</code> file with a <code class="language-plaintext highlighter-rouge">Package.resolved</code> file which is always created during dependency resolution.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>There has once again been some discussion around <code class="language-plaintext highlighter-rouge">Optional</code>, <code class="language-plaintext highlighter-rouge">throws</code> and the <code class="language-plaintext highlighter-rouge">Result</code> type. Although we probably won’t see changes here <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036353.html">in the near future</a>, it’s interesting to see this keeps resurfacing and the ideas maturing.</p>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036353.html">writes</a>:</p>
<blockquote>
<p>[..] the current error-handling system will not be going away, for the reasons Jaden has stated <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036345.html">above</a>.</p>
<p>Maybe we will grow typed throws at some point; maybe <code class="language-plaintext highlighter-rouge">Result</code> will get added to the standard library with some nice affordances to map between <code class="language-plaintext highlighter-rouge">throw</code>ing and <code class="language-plaintext highlighter-rouge">Result</code>-producing types; but we’re well beyond the point where we can rip out major features that have been generally well-received.</p>
</blockquote>
<p>In the earlier discussion on revamping <code class="language-plaintext highlighter-rouge">Optional</code> and <code class="language-plaintext highlighter-rouge">throws</code>, John McCall <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036256.html">writes</a>:</p>
<blockquote>
<p>We’ve definitely considered including a <code class="language-plaintext highlighter-rouge">Result</code> type, but our sense was that in an ideal world almost no code would be using it. It’s hard to imagine an ordinary API that ought to be returning a <code class="language-plaintext highlighter-rouge">Result</code> rather than <code class="language-plaintext highlighter-rouge">throw</code>ing, and once you’ve defined that away, the major remaining use case is just to shift computation around, like with a completion handler. That explicit computation-shifting pattern is something we’re hoping to largely define away with something like <code class="language-plaintext highlighter-rouge">C#</code>’s <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code>, which would leave <code class="language-plaintext highlighter-rouge">Result</code> as mostly just an implementation detail of such APIs. We didn’t want to spend a great deal of time designing a type that would end up being so marginal, especially if the changing role would lead us into different directions on the design itself. We also didn’t want to design a type that would become an obstacle to potential future language changes like, say, typed <code class="language-plaintext highlighter-rouge">throws</code>.</p>
<p>The downside, of course, is that as long as we lack that <code class="language-plaintext highlighter-rouge">async</code>/<code class="language-plaintext highlighter-rouge">await</code> design, computation-shifting isn’t real great.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — Xcode might not be <a href="https://twitter.com/steipete/status/859832487719182343">as genius as you think</a>. 🤔</p>
Issue #67
https://swiftweeklybrief.com/issue-67
2017-04-27T00:00:00-07:00
2017-04-27T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>A lot of proposals are being addressed this week, and Apple is working hard on an awesome Swift 4 release — and beyond.
Also, it’s almost May which means we’re now just over a month away from WWDC! It will be here before you know it.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">SE-0168</a> has been <a href="https://github.com/apple/swift/pull/8813">implemented</a>, but you can still <a href="https://bugs.swift.org/browse/SR-4701">help out improving diagnostics and adding fixits</a> to improve the usage for yourself and others.</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 8: <a href="https://spec.fm/podcasts/swift-unwrapped/66634">Archival Serialization & Swift Encoders</a></p>
<p>This week, JP Simard and Jesse Squires take a closer look at <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a> which seek to improve serialization and encoding in Swift.</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple <a href="https://swift.org/blog/swift-source-compatibility-test-suite/">announced</a> a test suite for Swift source compatibility, where you can add <em>your</em> open source project to the test suite. A regression has already <a href="https://twitter.com/slava_pestov/status/857457182803021824">been found</a> (and has been fixed)! 😱</p>
<blockquote>
<p>The goal is to have a strong source compatibility test suite containing thousands of projects. We look forward to project owners helping to achieve this goal by including their open source Swift projects in the test suite.</p>
</blockquote>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170424/004440.html">asked for help</a> implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md">SE-0169</a>. Get involved!</p>
<blockquote>
<p>Both proposals were only recently accepted, but would be good to get in for Swift 4. Unfortunately, the engineers on my team at Apple are fairly saturated in the near term with other tasks. If there is any interest from members of the community in taking on implementing (part of) either of these SE proposals in the near term that would be extremely welcome.</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Gelareh Taban posted <a href="https://github.com/swift-server/work-group/pull/80">minutes</a> for the 5th Swift Server APIs Security Stream Meeting.</p>
<p>Joe Shajrawi <a href="https://github.com/apple/swift/pull/8909">opened a pull request</a> to reduce code size:</p>
<blockquote>
<p>Under <code class="language-plaintext highlighter-rouge">-Onone</code> we have 3X binary size reduction, under <code class="language-plaintext highlighter-rouge">-O</code> a 2X binary size reduction. The text area is reduced by around 80% and 60% respectively.</p>
</blockquote>
<p>John Holdsworth, who co-authored <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">SE-0168</a>: <em>Multi-Line String Literals</em> has already <a href="https://github.com/apple/swift/pull/8813">implemented</a> the proposal. 🎉</p>
<p>Aleksey Gaponov opened <a href="https://github.com/apple/swift/pull/8718">a pull request</a> to allow covariance in protocol conformance.</p>
<p><a href="https://github.com/apple/swift/pull/8939">Thanks to</a> Ben Cohen, you will soon be able to say <code class="language-plaintext highlighter-rouge">T.Element == ...</code> instead of <code class="language-plaintext highlighter-rouge">T.Iterator.Element == ...</code> in your where clauses.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155</a>: <em>Normalize Enum Case Representation</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html">accepted with revisions</a>.</p>
<blockquote>
<p>Feedback from the community was positive about most aspects of the proposal. However, there was substantial disagreement about the right direction for pattern matching. The core team discussed this issue in depth.</p>
<p>Pattern matching is central to the use of enum types. It’s the only way you can use an enum value, besides general operations like passing it to a function or the special affordances for <code class="language-plaintext highlighter-rouge">Optional</code>s. Pattern matching is as central to enums as stored property access is to structs, and it’s fair to be worried about anything that would make it substantially more onerous. Unconditionally requiring associated-value labels in case patterns would certainly do that, and several members of the core team expressed concern that it would be bad enough to discourage the use of associated-value labels completely — in effect, subverting the entire language feature being proposed.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035972.html">Continue reading…</a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md">SE-0165</a>: <em>Dictionary & Set Enhancements</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035955.html">accepted with revisions</a>.</p>
<blockquote>
<p>The proposal is accepted with some revisions regarding naming:</p>
<ol>
<li>
<p>The key/value sequence of init that does not take a closure resolving key conflicts will be named <code class="language-plaintext highlighter-rouge">init(uniqueKeysWithValues:)</code>. The core team felt that either possible implementation – a default way of coalescing keys, or <code class="language-plaintext highlighter-rouge">fatalError</code>-ing on conflicts – could be surprising to users in ways that could easily be missed in testing. A failable initializer would probably result in frequent force-unwrapping. Giving the initializer an argument label that clearly states the uniqueness requirement fulfills the goal of making sure the caller is aware of the requirement.</p>
</li>
<li>
<p>The initializer that takes a sequence of pairs and a closure for conflicts will be named <code class="language-plaintext highlighter-rouge">init(_:uniquingKeysWith:)</code>, and the two merge methods (mutating and non-mutating) named <code class="language-plaintext highlighter-rouge">merge(_:uniquingKeysWith:)</code> and <code class="language-plaintext highlighter-rouge">merging(_:uniquingKeysWith:)</code>.</p>
</li>
<li>
<p>The group-by method on <code class="language-plaintext highlighter-rouge">Sequence</code> will be made into an initializer on <code class="language-plaintext highlighter-rouge">Dictionary</code>: <code class="language-plaintext highlighter-rouge">init<S: Sequence, E>(grouping elements: S, by: (E) -> Key) where Value == [E], S.Iterator.Element == E</code></p>
</li>
</ol>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>: <em>Swift Archival & Serialization</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000367.html">accepted with revisions</a>.</p>
<blockquote>
<p>The proposal is accepted with some minor modifications. Specifically, the core protocols and types will be sunk down into the Swift standard library for more tight integration with the Swift language and compiler, and the operations specifically involving Foundation’s <code class="language-plaintext highlighter-rouge">Data</code> type will be removed. The proposal document has been updated with more detail.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a>: <em>Swift Encoders</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000368.html">accepted</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md">SE-0171</a>: <em>Reduce with <code class="language-plaintext highlighter-rouge">inout</code></em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000364.html">accepted</a> for Swift 4.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md">SE-0172</a>: <em>One-sided Ranges</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000363.html">accepted</a> for Swift 4.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0173-swap-indices.md">SE-0173</a>: <em>Add <code class="language-plaintext highlighter-rouge">MutableCollection.swap(_:with:)</code></em> by Ben Cohen is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000366.html">under review</a>.</p>
<blockquote>
<p>As part of the introduction of the Law of Exclusivity, the current <code class="language-plaintext highlighter-rouge">swap(_:_:)</code> function must be addressed, as this most common uses of <code class="language-plaintext highlighter-rouge">swap</code> directly violate the law. This proposal introduces an alternative: a method on <code class="language-plaintext highlighter-rouge">MutableCollection</code> that takes two indices for swapping two elements in the same collection.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170417/004408.html">asked for input</a> on how to handle renamed types when mixing and matching Swift 3 and Swift 4 code.</p>
<blockquote>
<p>Should we just always import C/ObjC types under their Swift 4 names, and use typealiases in Swift 3 mode?</p>
<p>There are some downsides:</p>
<ul>
<li>We currently keep people from using Swift 4 names in Swift 3 code, and we wouldn’t be able to do that, since the actual declaration of the type always needs to be available.</li>
<li>We’d probably want to tweak the “aka” printing in diagnostics to not look through these typealiases. That’s not hard, though.</li>
<li>We can’t keep doing this once we have ABI stability. Hopefully framework owners aren’t going to continue changing Swift names of types, but we’ll probably need to implement my “C name in the mangling” plan anyway, just in case.</li>
</ul>
</blockquote>
<p>Rick Ballard <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170424/036203.html">pitched a proposal</a> to improve the Swift Package Manager’s dependency resolution… coincidentally <a href="https://twitter.com/rballard/status/857392666660683777">after listening</a> to the <a href="https://spec.fm/podcasts/swift-unwrapped">Swift Unwrapped podcast</a> on this topic!</p>
<blockquote>
<p>We have a proposal we’d like feedback on to revise how Swift Package Manager dependency resolution, updating, and pinning works. These changes weren’t planned in the roadmap we published a few months ago, but it’s become clear since then that we have some holes in our dependency resolution behavior that need fixing. We’ve also come to the conclusion that our original design for pinning was overcomplicated and should be revised.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>Robert Widmann “<a href="https://twitter.com/CodaFi_/status/857229845314588672">decided</a> to take a class in CoBOL to see what all the fuss is about with these modern imperative, stateful languages”
😂</p>
Issue #66
https://swiftweeklybrief.com/issue-66
2017-04-20T00:00:00-07:00
2017-04-20T00:00:00-07:00
Greg Heo
https://twitter.com/gregheo
https://github.com/gregheo.png?size=100
gregheo
<blockquote>
<p>Saving you thousands of clicks<br />
And finding the highlights and picks<br />
From the large convolution<br />
called <em>Swift Evolution</em><br />
It’s <em>Swift Weekly Brief</em>, sixty-six<br /></p>
</blockquote>
<p>The Swift community and core team are pressing on with proposals, pull requests, pitches, and of course posts to the mailing lists about everyone’s favorite topic: access control! 😳</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 7: <a href="https://spec.fm/podcasts/swift-unwrapped/65851">Access Control - The Saga Continues</a></p>
<p>In this week’s episode of <em>Swift Unwrapped</em>, your hosts Messrs. Simard and Squires discuss the roller coaster that is the evolution of access control in Swift: where have we come from, where are we now, and where are we headed in the future? Tune in and become enlightened. 💡</p>
<h3 id="news-and-community">News and community</h3>
<p>The Xcode team is pushing on with <a href="https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW853">yet another point release in 8.3.2</a>. Looks like there are a <a href="https://twitter.com/thequinntaylor/status/854481021965713408">good number</a> of <a href="https://twitter.com/jckarter/status/854540059197952000">bug</a> <a href="https://twitter.com/SmileyKeith/status/854469488242155520">fixes</a> and even build time <a href="https://twitter.com/craigtheatheist/status/854491688030490625">performance improvements</a> (<a href="https://twitter.com/NolanOBrien/status/854503063184330752">maybe?</a>) 🤔</p>
<p>The master branch of Swift gets merged into the Swift 4.0 branch occasionally, and Swift 4 release manager <a href="https://github.com/tkremenek">Ted Kremenek</a> announced <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170417/004405.html">the final re-branching date: June 1</a>:</p>
<blockquote>
<p>Changes will continue to be pulled into Swift 4 after that date, but the intent is for Swift 4 then to be in gradual convergence and to allow master to incorporate changes that will be included in future releases.</p>
</blockquote>
<p>Swift Evolution has a <a href="https://apple.github.io/swift-evolution/">great web dashboard</a>, but as they say on the Internet: is there an app for that? Yes! Check out <a href="https://itunes.apple.com/us/app/evolution-app/id1210898168?mt=8">Evolution App</a> from <a href="https://twitter.com/tholanda">Thiago Holanda</a>, and you’ll always have Swift access control proposals at your fingertips.</p>
<p>There’s already a new point release of <a href="https://github.com/br1sk/brisk">Brisk</a>, the delightful macOS app for submitting radars. Thanks <a href="https://twitter.com/SmileyKeith">Keith Smiley</a>!</p>
<p>And if you love radars so much, maybe you’re one of the chosen ones selected to try the shiny new <a href="https://twitter.com/an0/status/854066062605897728">Bug Reporter beta</a>? It’s great to see Apple improving its communication channel for developers! 📡</p>
<h3 id="access-control-pitches">Access Control Pitches</h3>
<p>Although I had hoped this section (perhaps this entire issue, even) could be spun off into a separate <em>Swift Access Control</em> newsletter, it looks like that’s not in the cards:</p>
<blockquote>
<p>The core team considers the access-control matter closed for Swift 4 and will not be reviewing any further proposals in this area. (<a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html">source</a>)</p>
</blockquote>
<p>Still, this is an issue the community is passionate about getting right and there were some more proposals floated this week:</p>
<ul>
<li>
<p>Erica Sadun and Jeffrey Bergier on <a href="https://github.com/erica/swift-evolution/blob/ef5f2a388eb07c7928dc1c803c4ca9bab6c26f90/proposals/zzzz-scoping.md">Flexible Access Control Scoping</a></p>
</li>
<li>
<p>Maxim Veksler’s post, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035751.html">Yet another access control pitch: Don’t</a></p>
</li>
<li>
<p>And I’ll link again to <em>Swift Weekly Brief</em> grand poobah Jesse Squires’s post, <a href="http://www.jessesquires.com/thoughts-on-swift-access-control/">Thoughts on Swift access control</a>.</p>
</li>
</ul>
<p>I think it’s worthwhile to think about <em>what</em> you want and need in terms of access control, and then <em>how</em> to achieve that in current Swift. The matter is closed for now, so we’ll be working with what we have for a while.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> has been implemented! 🎉 Check out the massive <a href="https://github.com/apple/swift/pull/3796">pull request</a> for all the history and details.</p>
<p>Along the road to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156</a>: <em>Class and Subtype existentials</em> is combining the concepts of <code class="language-plaintext highlighter-rouge">class</code> and <code class="language-plaintext highlighter-rouge">AnyObject</code>. As one of the <a href="https://github.com/apple/swift/pull/8770/commits/5993b63944d73e58c051ecd2570666efef940a10">commit messages</a> says: “Soon, Swift.AnyObject will become a protocol composition type with no protocols and a class constraint.”</p>
<p>You’ll find all the details in the <a href="https://github.com/apple/swift/pull/8770">“AnyObject removal preparations” pull request</a>. Send <a href="https://twitter.com/slava_pestov/status/854490613575700480">@slava_pestov</a> some positive thoughts as you scroll through the massive diff! 😓</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md">SE-0161</a>: <em>Smart KeyPaths: Better Key-Value Coding for Swift</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000356.html">accepted</a>.</p>
<p>The meat of this proposal is elevating key paths from plain old strings created safely with <code class="language-plaintext highlighter-rouge">#keyPath</code>, to a full type. Aside from the path itself, it could also hold data such as “type, mutability, property name(s), and ability to set/get values.”</p>
<p>This proposal went through a syntax revision to change <code class="language-plaintext highlighter-rouge">#keyPath</code> to the lighter weight backslash <code class="language-plaintext highlighter-rouge">\</code>, like you’re “escaping” the reference to a property rather than accessing the property directly.</p>
<blockquote>
<p>The <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html">first review</a> established the main substance of the proposal, while the second review focused mostly on the more lightweight <code class="language-plaintext highlighter-rouge">\</code> syntax.</p>
<p>The core team felt that the leading <code class="language-plaintext highlighter-rouge">\</code> is our best option for introducing keypaths. It is lightweight, yet provides a visual “escape” to indicate that the evaluation of the entities being referenced is being delayed. As noted in the result of the <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html">first review</a>, this is part of a longer-term plan to use the <code class="language-plaintext highlighter-rouge">\</code> for unapplied method references, bringing the two closely-related features into syntactic alignment over time and providing an opportunity to stage in the important but currently-source-breaking changes accepted in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md">SE-0042</a>.</p>
</blockquote>
<p>There’s already a <a href="https://github.com/apple/swift/pull/8875">pull request</a> that includes a skeleton implementation of the standard library API.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md">SE-0163</a>: <em>String Revision: Collection Conformance, C Interop, Transcoding</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000359.html">accepted with revisions</a>.</p>
<p>A lot of good stuff in this proposal comes from the <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md">String Processing For Swift 4</a> document (formerly known as the <em>Swift String Manifesto</em>). The one change I’m most excited about: strings will conform to <code class="language-plaintext highlighter-rouge">BidirectionalCollection</code> and <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code>! 🎉</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md">SE-0164</a>: <em>Remove final support in protocol extensions</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000355.html">accepted</a>.</p>
<p>I often struggle to explain functions in protocol extensions to Swift newcomers: is it like a superclass implementation? Do you “override” them? How does dispatch work compared to methods defined directly within a type? This proposal removes one confusing bit and disallows the <code class="language-plaintext highlighter-rouge">final</code> keyword for functions in protocol extensions.</p>
<blockquote>
<p>In the current version of Swift, the final keyword does not modify dispatch behavior in any way, and it does not generate an error message. This keyword has no use in Swift’s current protocol model. Functions in protocol extensions cannot be overridden and will always use direct dispatch.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">SE-0168</a>: <em>Multi-Line String Literals</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035923.html">accepted</a>.</p>
<p>As part of the march towards a top-tier Perl-class string processing language, multi-line string literals are coming to Swift! 😉</p>
<p>You’ll be able to use a triple quote <code class="language-plaintext highlighter-rouge">"""</code> to open and close string literals. Just be careful about spacing, as “Every line inside the literal must begin with the exact sequence of spaces and tabs that precedes the closing delimiter”:</p>
<figure class="highlight"><pre><code class="language-html" data-lang="html"> """
<span class="nt"><tab><space></span>this is OK
<span class="nt"><space><space></span>this is an error
<span class="nt"><space><tab></span>this is also an error
<span class="nt"><tab></span>under-indenting is an error too
<span class="nt"><tab><space><space></span>but you can go nuts after the indentation all you want
<span class="nt"><tab><space><tab></span>you do you
<span class="nt"><tab><space></span>"""</code></pre></figure>
<p>There are plenty of fiddly details, and you should check out the <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000360.html">full approval post</a> to read all about them.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md">SE-0169</a>: <em>Improve Interaction Between <code class="language-plaintext highlighter-rouge">private</code> Declarations and Extensions</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000357.html">accepted</a>.</p>
<p>Using the <code class="language-plaintext highlighter-rouge">private</code> keyword will now have a slightly wider scope: extensions to a type will be able to access private members declared in the same file.</p>
<p>Same file, same type, need access? <code class="language-plaintext highlighter-rouge">private</code>.
Same file, different type, need access? <code class="language-plaintext highlighter-rouge">fileprivate</code>.</p>
<blockquote>
<p>The core team feels that this proposal makes private access align more closely with the goals of the language:</p>
<ul>
<li>It supports the notion that extensions are a code-organization tool: one should be able to break up a type’s definition into several extensions to improve the clarity of that code, without having to open up access or otherwise view the members in different extensions as completely-distinct entities. The core team expects future language evolution to reinforce the notion that extensions are more of a code organization tool than distinct entities, e.g., allowing stored properties to be introduced in an extension.</li>
<li>It makes private more usable as the default sub-internal access level, which supports progressive disclosure of the access control system and better matches with programmer’s expectations about what private access means.</li>
<li>It makes fileprivate more meaningful, because it is only needed for those cases where one is reaching across types (or among types and globals) within a file. It will also become more rare, which matches well with its longer, descriptive name.</li>
</ul>
</blockquote>
<p>I’m already thinking up alternate names like <em>typefileprivate</em> and <em>reallyprivate</em>. Sorry.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0170-nsnumber_bridge.md">SE-0170</a>: <em>NSNumber bridging and Numeric types</em> by Philippe Hausler is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000351.html">under review</a>.</p>
<p><code class="language-plaintext highlighter-rouge">NSNumber</code> is a very un-Swifty type: it rolls in all kinds of integer and floating point types into one big type. This proposal suggests ways to clean up the <code class="language-plaintext highlighter-rouge">NSNumber</code> bridging and handle underflow and overflow gracefully.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">NSNumber</code> has been a strange duck in the Swift world especially when it has come to bridging and interacting with other protocols…<code class="language-plaintext highlighter-rouge">as?</code> for NSNumber should mean “Can I safely express the value stored in this opaque box called a <code class="language-plaintext highlighter-rouge">NSNumber</code> as the value I want?”.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0171-reduce-with-inout.md">SE-0171</a>: <em>Reduce with inout</em> by Chris Eidhof is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000352.html">under review</a>.</p>
<p>The <code class="language-plaintext highlighter-rouge">reduce</code> method passes along partial results to the next iteration, making copies each time. This proposal suggests adding a “reduce into” variant that uses an <code class="language-plaintext highlighter-rouge">inout</code> parameter instead to be more efficient in some cases:</p>
<blockquote>
<p>A new variant of <code class="language-plaintext highlighter-rouge">reduce</code> should be added to the standard library. Instead of taking a <code class="language-plaintext highlighter-rouge">combine</code> function that is of type <code class="language-plaintext highlighter-rouge">(A, Iterator.Element) -> A</code>, the full type and implementation of the added <code class="language-plaintext highlighter-rouge">reduce</code> will be:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">Sequence</span> <span class="p">{</span>
<span class="kd">func</span> <span class="n">reduce</span><span class="o"><</span><span class="kt">A</span><span class="o">></span><span class="p">(</span><span class="n">into</span> <span class="nv">initial</span><span class="p">:</span> <span class="kt">A</span><span class="p">,</span> <span class="n">_</span> <span class="nv">combine</span><span class="p">:</span> <span class="p">(</span><span class="k">inout</span> <span class="kt">A</span><span class="p">,</span> <span class="kt">Iterator</span><span class="o">.</span><span class="kt">Element</span><span class="p">)</span> <span class="o">-></span> <span class="p">())</span> <span class="o">-></span> <span class="kt">A</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">result</span> <span class="o">=</span> <span class="n">initial</span>
<span class="k">for</span> <span class="n">element</span> <span class="k">in</span> <span class="k">self</span> <span class="p">{</span>
<span class="nf">combine</span><span class="p">(</span><span class="o">&</span><span class="n">result</span><span class="p">,</span> <span class="n">element</span><span class="p">)</span>
<span class="p">}</span>
<span class="k">return</span> <span class="n">result</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0172-one-sided-ranges.md">SE-0172</a>: <em>One-sided Ranges</em> by Ben Cohen, Dave Abrahams, and Becca Royal-Gordon is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000358.html">under review</a>.</p>
<p>Currently in Swift, creating a slice of a collection means typing <code class="language-plaintext highlighter-rouge">startIndex</code> and <code class="language-plaintext highlighter-rouge">endIndex</code> a lot, like <code class="language-plaintext highlighter-rouge">s[s.startIndex..<i]</code>, or using the prefix and suffix methods.</p>
<blockquote>
<p>This proposal introduces the concept of a “one-sided” range, created via prefix/postfix versions of the existing range operators. [The proposed solution is to] introduce a one-sided range syntax, where the “missing” side is inferred to be the start/end:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// half-open right-handed range</span>
<span class="k">let</span> <span class="nv">greeting</span> <span class="o">=</span> <span class="n">s</span><span class="p">[</span><span class="o">..<</span><span class="n">i</span><span class="p">]</span>
<span class="c1">// closed right-handed range</span>
<span class="k">let</span> <span class="nv">withComma</span> <span class="o">=</span> <span class="n">s</span><span class="p">[</span><span class="o">...</span><span class="n">i</span><span class="p">]</span>
<span class="c1">// left-handed range (no need for half-open variant)</span>
<span class="k">let</span> <span class="nv">location</span> <span class="o">=</span> <span class="n">s</span><span class="p">[</span><span class="n">i</span><span class="o">...</span><span class="p">]</span></code></pre></figure>
<p>There’s even a <a href="https://github.com/apple/swift/pull/8710/commits/9fc37d1f39111487387a303a841ebaac8f69f425">work-in-progress diff</a> if you want to see what this might look like in real life.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Since the mailing lists include folks from many countries and experience levels, it’s important to be precise on what you mean. Here’s a communications pro-tip from core team member Dave Abrahams:</p>
<blockquote>
<p>[P]lease don’t use the word “safe” this way around here as it
conflicts with the definition used by Swift. As defined by Swift, safety has nothing to do with whether something might trap or whether it’s spelled with a “!”, but about whether it can corrupt memory (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170410/035791.html">source</a>)</p>
</blockquote>
<p>To round off this special <em>access control</em> edition of the newsletter, what lessons can we learn from the <em>private vs fileprivate vs the world</em> saga? David Hart <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035871.html">suggests a “breeding ground”</a> where we could try out proposed features in real life before making them official.</p>
<p>Javascript has something similar with <a href="https://babeljs.io">Babel</a>, which transforms “next generation” Javascript into something that runs in current implementations. The Perl community does something similar, where they often backport Perl 6 features as Perl 5 modules so a wider audience can try them out.</p>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170417/035910.html">points out we <em>do</em> have a beta period</a>, in the WWDC-to-September timeline when the vast majority of developers get their hands on official Xcode betas with Swift 4. And is he—core team member and orignal creator of the language—happy with access control?</p>
<blockquote>
<p>[I]t remains to be seen, but I strongly believe that we’ve ended up in a good place with access control. The process was painful, but worthwhile to reach a great result.</p>
</blockquote>
<p>I like to picture him dropping the mic at this point. 🎤🖐</p>
<h3 id="finally">Finally</h3>
<p>I knew <a href="https://en.wikipedia.org/wiki/Type_punning">type punning</a> was a thing, but Swift nerds <a href="https://twitter.com/jckarter/status/854029235299639303">take it to a whole other level</a>. 🤣</p>
Issue #65
https://swiftweeklybrief.com/issue-65
2017-04-13T00:00:00-07:00
2017-04-13T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>More proposals are making it through the review process this week as “phase 2” discussions of the Swift 4 development cycle come to a close, most notably <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">SE-0168</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md">SE-0169</a>. Proposal SE-0168 would add support for (highly desired!) multi-line <code class="language-plaintext highlighter-rouge">String</code> literals. No longer would we be forced to resort to string concatenation like animals. Proposal SE-0169 is a follow-up to the rejection of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a> and seems to be our last hope for modifying access control in Swift, or repairing it depending on your perspective. There is a light at the end of the access control tunnel! Or maybe those are the headlights of an oncoming train, not sure. 😆</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://realm.io/news/craft-collaborative-apps-with-realm/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_65" target="_blank">Crafting Collaborative Apps with Realm</a></h4>
<p>From try! Swift Tokyo 2017, Marius Rackwitz introduces the open-source Realm Mobile Database and demos how Realm Mobile Platforms completes it with server-side components. Together, this allows you to treat synchronization and network as an implementation detail of your technology stack, making features like live collaboration easily available to any developer. He shows how you can build apps in a reactive manner on top of a database which takes care of the rest.</p>
<p><small><a href="https://realm.io/news/craft-collaborative-apps-with-realm/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_65" target="_blank">realm.io</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 6: <a href="https://spec.fm/podcasts/swift-unwrapped/65229">Swift 3.1 Release & SwiftPM Improvements</a></p>
<p>This week we discuss our thoughts on the Swift 3.1 release and the Swift Package Manager improvements that came with it!</p>
<h3 id="news-and-community">News and community</h3>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170410/004367.html">announced</a> that an <a href="https://swift.org/abi-stability/">official ABI dashboard</a> is now available on Swift.org.</p>
<blockquote>
<p>One of the top priorities for Swift right now is compatibility across future Swift versions. One major component of this is ABI stability, which enables binary compatibility between applications and libraries compiled with different versions of Swift.</p>
</blockquote>
<p>From Ted:</p>
<blockquote>
<p>The tasks currently tracked on the dashboard are fairly low-level details concerning the ABI itself. These include details that should be re-reviewed and finalized, or finishing up areas we know are incomplete.</p>
</blockquote>
<p><a href="https://twitter.com/tonisuter">Toni Suter</a> is working on cross-platform Swift IDE called <a href="https://tifig.net">Tifig</a>. It looks like its still in the very early stages, but worth checking out and keeping an eye on. 😎 <em>“Tifig is a Swiss German word and means ‘swift’.”</em></p>
<p>Should you <a href="https://bugreport.apple.com">file a radar</a> or <a href="https://bugs.swift.org/">open a JIRA task</a> for bugs you find? It’s not always clear. Filing bugs in JIRA for Swift is pretty painless, but radar is awful. This week <a href="https://twitter.com/SmileyKeith/status/852203916561268736">Keith Smiley</a> announced a new macOS app for radar, <a href="https://github.com/br1sk/brisk">Brisk</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Mark Lacey is <a href="https://github.com/apple/swift/pull/8725">working on something</a> really cool to solve a large class of “expression too complex” issues. (h/t <a href="https://twitter.com/slava_pestov/status/852341449316225025">Slava Pestov</a>)</p>
<p>Michael Ilseman <a href="https://github.com/apple/swift/pull/8730">merged</a> a pull request for the “unicode rethink” branch that results in a 3x speedup for small strings by “exploding” the code units, that is, by making a fixed-size array and unpacking into it.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/8650">started implementing</a> preliminary Sema and AST support for subclass existentials for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156</a>.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/commit/57c607e33990db400e6758cf213c0bd0d3a4b303">finished</a> the implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md">SE-0160</a>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md">SE-0160</a>: <em>Limiting <code class="language-plaintext highlighter-rouge">@objc</code> inference</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000349.html">accepted</a>.</p>
<blockquote>
<p>The feedback on the second round of review was very light and uniformly positive.</p>
<p>The proposal has been implemented in <a href="https://github.com/apple/swift/pull/8379">#8379</a>. Early experience migrating a nontrivial Cocoa app (~200k LOC, roughly half Swift and half Objective-C) resulted in a 5.7% decrease in code size (Release build) and required only 40 new <code class="language-plaintext highlighter-rouge">@objc</code> annotations, 37 of which were indicated by the new compiler warnings, 2 of which manifested as post-migration errors, and the last of which was found with the new (opt-in) runtime warnings.</p>
<p>Thank you to Doug Gregor for the proposal, and also the implementation of this improvement!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md">SE-0162</a>: <em>Package Manager Custom Target Layouts</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000350.html">accepted</a> (and <a href="https://github.com/apple/swift-package-manager/pull/1077">implemented</a>!).</p>
<blockquote>
<p>The feedback we received prior to and during the review was very positive.</p>
<p>Thanks to everyone who participated!</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>: <em>Swift Archival & Serialization</em> by Itai Ferber, Michael LeHew, and Tony Parker is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000346.html">under review</a>.</p>
<blockquote>
<p>Foundation’s current archival and serialization APIs (<code class="language-plaintext highlighter-rouge">NSCoding</code>, <code class="language-plaintext highlighter-rouge">NSJSONSerialization</code>, <code class="language-plaintext highlighter-rouge">NSPropertyListSerialization</code>, etc.), while fitting for the dynamism of Objective-C, do not always map optimally into Swift. This document lays out the design of an updated API that improves the developer experience of performing archival and serialization in Swift.</p>
<p>Specifically:</p>
<ul>
<li>It aims to provide a solution for the archival of Swift <code class="language-plaintext highlighter-rouge">struct</code> and <code class="language-plaintext highlighter-rouge">enum</code> types</li>
<li>It aims to provide a more type-safe solution for serializing to external formats, such as JSON and plist</li>
</ul>
<p>The primary motivation for this proposal is the inclusion of native Swift <code class="language-plaintext highlighter-rouge">enum</code> and <code class="language-plaintext highlighter-rouge">struct</code> types in archival and serialization.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0167-swift-encoders.md">SE-0167</a>: <em>Swift Encoders</em> by Itai Ferber, Michael LeHew, and Tony Parker is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000345.html">under review</a>.</p>
<blockquote>
<p>As part of the proposal for a Swift archival and serialization API (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>), we are also proposing new API for specific new encoders and decoders, as well as introducing support for new <code class="language-plaintext highlighter-rouge">Codable</code> types in <code class="language-plaintext highlighter-rouge">NSKeyedArchiver</code> and <code class="language-plaintext highlighter-rouge">NSKeyedUnarchiver</code>.</p>
<p>This proposal composes the latter two stages laid out in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>.</p>
<p>With the base API discussed in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0166-swift-archival-serialization.md">SE-0166</a>, we want to provide new encoders for consumers of this API, as well as provide a consistent story for bridging this new API with our existing <code class="language-plaintext highlighter-rouge">NSCoding</code> implementations. We would like to offer a base level of support that users can depend on, and set a pattern that third parties can follow in implementing and extending their own encoders.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md">SE-0168</a>: <em>Multi-Line String Literals</em> by John Holdsworth, Becca Royal-Gordon, and Tyler Cloutier is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000347.html">under review</a>.</p>
<blockquote>
<p>This proposal introduces multi-line string literals to Swift source code. This has been discussed a few times on swift-evolution most recently putting forward a number of different syntaxes that could achieve this goal each of which has their own use case and constituency for discussion.</p>
<p>Multi-line String literals are a common programming-language feature that is, to date, still missing in Swift. Whether generating XML/JSON messages or building usage messages in Swift scripts, providing string literals that extend over multiple lines offers a simple way to represent text without having to manually break lines using string concatenation. Concatenation is ungainly and may result in slow compilation.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md">SE-0169</a>: <em>Improve Interaction Between <code class="language-plaintext highlighter-rouge">private</code> Declarations and Extensions</em> by David Hart and Chris Lattner is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000348.html">under review</a>.</p>
<blockquote>
<p>In Swift 3, a declaration marked <code class="language-plaintext highlighter-rouge">private</code> may be accessed by anything nested in the scope of the private declaration, for example a private property or method defined on a struct may be accessed by methods defined within that struct.</p>
<p>This model was introduced by <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a> and with nearly a year of experience using this model, it has worked well in almost all cases. The primary case it falls down is when the implementation of a type is split into a base definition and a set of extensions. Because of the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a> model, extensions to the type are not allowed to access private members defined on that type.</p>
<p>This proposal recommends extending <code class="language-plaintext highlighter-rouge">private</code> access control so that members defined in an extension of a type have the same access as members defined on the type itself, so long as the type and extension are in the same source file. We expect this to dramatically reduce the number of uses of <code class="language-plaintext highlighter-rouge">fileprivate</code> in practice.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Project Lead Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035247.html">sent out an email</a> regarding Swift 4, phase 2:</p>
<blockquote>
<p>In mid-February we <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html">kicked of “stage 2”</a> for the discussion of evolution proposals for Swift 4.</p>
<p>The timetable set forth was to have discussions for “stage 2” go through April 1. The intent of that timetable was to (a) timebox discussions on proposals to help <em>focus</em> them within the theme/focus areas of the release and to (b) provide time after discussion to <em>implement</em> approved proposals for Swift 4.</p>
<p>While the April 1 date for the end of stage 2 has passed, it is clear that by looking at where we are in the development of Swift 4 and what remains to be done that there are still important discussions happening on swift-evolution concerning changes possibly impacting Swift 4. Those discussions should continue and given the opportunity to converge. That said, we have reached to point where we need to be increasingly circumspect on what topics remain in scope for Swift 4.</p>
<p>At this point, discussions about changes impacting Swift 4 should generally focus in the following areas:</p>
<p>Anything fitting in the “stage 1” phase for the release, such as (among others) the <code class="language-plaintext highlighter-rouge">String</code> re-evaluation and the memory ownership model remain priority topics to discuss.</p>
<p><em>Existing</em> topics we have already covered during “stage 2” also remain relevant to discuss for the release, although the scope of actual change we will consider for Swift 4 is rapidly diminishing. The distinction of what is “out-of-scope” may not always be clear to everyone, and the Core Team will try and provide clear guidance as discussions happen on swift-evolution where appropriate to indicate whether or not something is in scope for Swift 4.</p>
<p>Looking beyond Swift 4, serious discussion about Swift 5 will likely start up in July as the themes and focus areas of that release are identified.</p>
<p>Thank you to everyone who has contributed to the discussions so far to help shape Swift 4!</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — a <a href="https://twitter.com/jckarter/status/851472257067040768">new access control proposal</a>. 😂 It’s funny because it’s true. 😅</p>
Issue #64
https://swiftweeklybrief.com/issue-64
2017-04-06T00:00:00-07:00
2017-04-06T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>The great access control <del>battle</del> debate is finally over! Just kidding. Of course, the <del>holy war</del> discussion is ongoing. While <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a> was rejected with much dismay, there are final talks on how to remedy the access control situation in Swift before its too late. <a href="https://twitter.com/simjp/status/849097584316751873">Friction-driven development</a> wins again! 😉 In other news, a number of new proposals are under review as we marinate in the Swift 4 phase 2 development cycle.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://iosdevweekly.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_64" target="_blank">iOS Dev Weekly</a></h4>
<p>Dave Verwer from iOS Dev Weekly here. I’m a big fan of the Swift Weekly Brief so when I saw they were looking for support, I thought I should do that! Keep up the good work Jesse!</p>
<p><small><a href="https://iosdevweekly.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_64" target="_blank">iosdevweekly.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 5: <a href="https://spec.fm/podcasts/swift-unwrapped/61854">Objective-C Interoperability</a></p>
<p>There’s been a much stronger focus on calling Objective-C from Swift than the other way around, but in episode talk we’ll cover both directions and the parts of the Swift language involved in the process.</p>
<h3 id="news-and-community">News and community</h3>
<p>Yours truly wrote a post about the current Swift access control debates and changes, <a href="http://www.jessesquires.com/thoughts-on-swift-access-control/">Thoughts on Swift access control: And the opportunity costs of Swift evolution</a>. I provide a brief history and analysis of exactly how we got to this point, and what I think is the best way forward.</p>
<p>JP Simard <a href="https://twitter.com/simjp/status/848288462952316928">noticed</a> references to “rename” actions in <a href="https://github.com/apple/swift/tree/master/tools/SourceKit">SourceKit</a> in Xcode 8.3, and predicted we’ll see refactoring support for Swift in Xcode 9. He also <a href="https://twitter.com/simjp/status/848288609006309376">pointed out</a> that the “Swift Syntax Structured Editing Library” that <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170206/004066.html">was announced</a> a couple of months ago is an even bigger indication of refactoring support. If true, this would be a huge relief for developers. This is something I’ve wanted from Xcode for years (!) now. Let’s hope we see this at WWDC in a few months!</p>
<p>Speaking of JP Simard, he released <a href="https://github.com/jpsim/SourceKitten/releases/tag/0.17.1">SourceKitten 0.17.1</a>, which includes Swift 3.1 support.</p>
<p>Greg Heo wrote <a href="https://swiftunboxed.com/lang/reduce/">a fantastic post</a> explaining the <code class="language-plaintext highlighter-rouge">reduce(_:_:)</code> function. His prose is eloquent. His visuals and diagrams are excellent. And of course, no article is complete without a poem:</p>
<blockquote>
<p>Filter, reduce, and map:<br />
Collections transformed at a tap.<br />
These functional friends,<br />
your code they will cleanse,<br />
with immutable inputs, no trap.<br /></p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>We’ll skip this section this week as there’s been too much happening on swift-evolution. Ain’t nobody got time for that. 😄</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0161-key-paths.md">SE-0161</a>: <em>Smart KeyPaths: Better Key-Value Coding for Swift</em> by David Smith, Michael LeHew, and Joe Groff was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000334.html">reviewed</a> and then <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html">returned</a> for a <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000343.html">second review</a>.</p>
<p>The proposal:</p>
<blockquote>
<p>We propose a family of concrete <em>Key Path</em> types that represent uninvoked references to properties that can be composed to form paths through many values and directly get/set their underlying values.</p>
<p><strong>We Can Do Better than String</strong><br />
On Darwin platforms Swift’s existing <code class="language-plaintext highlighter-rouge">#keyPath()</code> syntax provides a convenient way to safely <em>refer</em> to properties. Unfortunately, once validated, the expression becomes a <code class="language-plaintext highlighter-rouge">String</code> which has a number of important limitations:</p>
<ul>
<li>Loss of type information (requiring awkward <code class="language-plaintext highlighter-rouge">Any</code> APIs)</li>
<li>Unnecessarily slow to parse</li>
<li>Only applicable to <code class="language-plaintext highlighter-rouge">NSObjects</code></li>
<li>Limited to Darwin platforms</li>
</ul>
<p><strong>Use/Mention Distinctions</strong><br />
While methods can be referred to without invoking them (<code class="language-plaintext highlighter-rouge">let x = foo.bar</code> instead of <code class="language-plaintext highlighter-rouge">let x = foo.bar()</code>), this is not currently possible for properties and subscripts. Making indirect references to a properties’ concrete types also lets us expose metadata about the property, and in the future additional behaviors.</p>
<p><strong>More Expressive KeyPaths</strong><br />
We would also like to support being able to use <em>Key Paths</em> to access into collections, which is not currently possible.</p>
</blockquote>
<p>From the revision email:</p>
<blockquote>
<p>The proposal was very well-received <em>except</em> that reviewers felt that the <code class="language-plaintext highlighter-rouge">#keyPath</code> syntax was far too heavy for this new language construct, and preferred the lighter-weight syntax of the pre-review drafts. This proposal is returned for revision to address the syntax.</p>
<p>The heavyweight <code class="language-plaintext highlighter-rouge">#keyPath</code> syntax was requested by the core team after reviewing earlier drafts, which used a far lighter syntax:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// (Rejected) syntax from pre-review drafts</span>
<span class="k">let</span> <span class="nv">firstFriendsNameKeyPath</span> <span class="o">=</span> <span class="kt">Person</span><span class="o">.</span><span class="n">friends</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span><span class="o">.</span><span class="n">name</span>
<span class="nf">print</span><span class="p">(</span><span class="n">luke</span><span class="p">[</span><span class="nv">keyPath</span><span class="p">:</span> <span class="o">.</span><span class="n">friends</span><span class="p">[</span><span class="mi">0</span><span class="p">]</span><span class="o">.</span><span class="n">name</span><span class="p">])</span></code></pre></figure>
<blockquote>
<p>The core team’s specific concern was that these key path expressions (e.g., <code class="language-plaintext highlighter-rouge">Person.friends[0].name</code>) don’t make it sufficiently clear that the actual property accesses are being delayed, and that the contextual cues (“Person.” vs. “luke.”) are insufficient to disambiguate for the human reader. Hence, the request for a different (more explicit) syntax.</p>
<p>Reviewers rightly point out that it is natural for key-paths to use the same syntax as unapplied instance method references, e.g., <code class="language-plaintext highlighter-rouge">Person.someInstanceMethod</code> produces a value of some function type with the <code class="language-plaintext highlighter-rouge">Self</code> type curried, e.g., <code class="language-plaintext highlighter-rouge">(Person) -> (param-types) -> result-type</code>. The core team agrees with this sentiment. The core team also felt that Swift’s existing unapplied method references suffer from the same clarity problems as the initial key-path syntax, i.e., that it isn’t sufficiently clear that the actual application of <code class="language-plaintext highlighter-rouge">self</code> is being delayed.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000342.html">Continue reading…</a></p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a>: <em>Fix Private Access Levels</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000337.html">rejected</a>.</p>
<blockquote>
<p>The core team had a lengthy discussion of this proposal as well as related ideas that came up during (and prior to) the review.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a> specifically sought to revert the main user-facing part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>, which gave <code class="language-plaintext highlighter-rouge">private</code> lexical-scoping semantics and introduced <code class="language-plaintext highlighter-rouge">fileprivate</code>. The core team felt that there was sufficient evidence that more-restrictive-than-fileprivate access control is in use within the Swift community and in established patterns, such that it would be harmful to remove the functionality introduced by <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a> at this point.</p>
<p>The core team discussed the idea of renaming to keywords that was brought up in the thread as a way to address many of the concerns raised in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a> while providing the same language semantics. Specifically:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">private</code> -> <code class="language-plaintext highlighter-rouge">scoped</code></li>
<li><code class="language-plaintext highlighter-rouge">fileprivate</code> -> <code class="language-plaintext highlighter-rouge">private</code></li>
</ul>
<p>The core team determined that such a change, while (technically) easy to automatically migrate, would introduce far too much churn in Swift code bases moving from Swift 3 to Swift 4, compromising the source stability goals set out for Swift 4.</p>
<p>Finally, the core team discussed a different potential design for “private” that admits a limited form of type-based access control within files. We will open a separate discussion thread on Swift Evolution, with the subject “Type-based ‘private’ access within a file”, and are seeking further discussion there and a motivated volunteer to turn it into a new proposal for Swift 4.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155</a>: <em>Normalize Enum Case Representation</em> by Daniel Duan and Joe Groff is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000336.html">under review</a>.</p>
<blockquote>
<p>In Swift 3, associated values of an enum case are represented by a tuple. This implementation causes inconsistencies in case declaration, construction and pattern matching in several places.</p>
<p>Enums, therefore, can be made more “regular” when we replace tuple as the representation of associated case values. This proposal aims to define the effect of doing so on various parts of the language.</p>
<p>Swift-evolution thread: <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033626.html">Normalize Enum Case Representation (rev. 2)</a></p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0162-package-manager-custom-target-layouts.md">SE-0162</a>: <em>Package Manager Custom Target Layouts</em> by Ankit Aggarwal is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000339.html">under review</a>.</p>
<blockquote>
<p>This proposal enhances the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest APIs to support custom target layouts, and removes a convention which allowed omission of targets from the manifest.</p>
<p>The Package Manager uses a convention system to infer targets structure from disk layout. This works well for most packages, which can easily adopt the conventions, and frees users from needing to update their <code class="language-plaintext highlighter-rouge">Package.swift</code> file every time they add or remove sources. Adopting the conventions is more difficult for some packages, however – especially existing C libraries or large projects, which would be difficult to reorganize. We intend to give users a way to make such projects into packages without needing to conform to our conventions.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0163-string-revision-1.md">SE-0163</a>: <em>String Revision: Collection Conformance, C Interop, Transcoding</em> by Ben Cohen and Dave Abrahams is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000340.html">under review</a>.</p>
<blockquote>
<p>This proposal is to implement a subset of the changes from the <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md">Swift 4 String Manifesto</a>.</p>
<p>Specifically:</p>
<ul>
<li>Make <code class="language-plaintext highlighter-rouge">String</code> conform to <code class="language-plaintext highlighter-rouge">BidirectionalCollection</code></li>
<li>Make <code class="language-plaintext highlighter-rouge">String</code> conform to <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code></li>
<li>Create a <code class="language-plaintext highlighter-rouge">Substring</code> type for <code class="language-plaintext highlighter-rouge">String.SubSequence</code></li>
<li>Create a <code class="language-plaintext highlighter-rouge">Unicode</code> protocol to allow for generic operations over both types.</li>
<li>Consolidate on a concise set of C interop methods.</li>
<li>Revise the transcoding infrastructure.</li>
</ul>
<p>Other existing aspects of <code class="language-plaintext highlighter-rouge">String</code> remain unchanged for the purposes of this proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0164-remove-final-support-in-protocol-extensions.md">SE-0164</a>: <em>Remove final support in protocol extensions</em> by Brian King is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000341.html">under review</a>.</p>
<blockquote>
<p>This proposal disallows the <code class="language-plaintext highlighter-rouge">final</code> keyword when declaring functions in protocol extensions.</p>
<p>In the current version of Swift, the <code class="language-plaintext highlighter-rouge">final</code> keyword does not modify dispatch behavior in any way, and it does not generate an error message. This keyword has no use in Swift’s current protocol model. Functions in protocol extensions cannot be overridden and will always use direct dispatch.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0165-dict.md">SE-0165</a>: <em>Dictionary & Set Enhancements</em> by Nate Cook is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-April/000344.html">under review</a>.</p>
<blockquote>
<p>This proposal comprises a variety of commonly (and less commonly) suggested improvements to the standard library’s <code class="language-plaintext highlighter-rouge">Dictionary</code> type, from merging initializers to dictionary-specific <code class="language-plaintext highlighter-rouge">filter</code> and <code class="language-plaintext highlighter-rouge">mapValues</code> methods. The proposed additions to <code class="language-plaintext highlighter-rouge">Dictionary</code>, and the corresponding changes to <code class="language-plaintext highlighter-rouge">Set</code>, are detailed in the sections below.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>As mentioned above in the rejection of SE-0159, Doug Gregor has <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034903.html">opened a new discussion</a> about implementing type-based ‘private’ access within a file — which will hopefully settle Swift’s access control story for good.</p>
<blockquote>
<p>In rejecting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a>, the core team described a potential direction we would like to investigate for “private” access control that admits a limited form of type-based access control within files. The core team is seeking some discussion here and a motivated volunteer to put together a proposal along these lines for review in the Swift 4 time-frame (i.e., very soon). To be clear, the core team isn’t sure this is the right direction to go… but it appears promising and we would <em>love</em> to be able to settle the access-control issue.</p>
<p>The design, specifically, is that a “private” member declared within a type “X” or an extension thereof would be accessible from:</p>
<ul>
<li>An extension of “X” in the same file</li>
<li>The definition of “X”, if it occurs in the same file</li>
<li>A nested type (or extension thereof) of one of the above that occurs in the same file</li>
</ul>
<p>This design has a number of apparent benefits:</p>
<ul>
<li><code class="language-plaintext highlighter-rouge">private</code> becomes the right default for “less than whole module” visibility, and aligns well with Swift coding style that divides a type’s definition into a number of extensions.</li>
<li><code class="language-plaintext highlighter-rouge">fileprivate</code> remains for existing use cases, but now it’s use it more rare, which has several advantages:
<ul>
<li>It fits well with the “progressive disclosure” philosophy behind Swift: you can use <code class="language-plaintext highlighter-rouge">public</code>/<code class="language-plaintext highlighter-rouge">internal</code>/<code class="language-plaintext highlighter-rouge">private</code> for a while before encountering and having to learn about <code class="language-plaintext highlighter-rouge">fileprivate</code> (note: we thought this was going to be true of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>, but we were clearly wrong)</li>
<li>When <code class="language-plaintext highlighter-rouge">fileprivate</code> occurs, it means there’s some interesting coupling between different types in the same file. That makes <code class="language-plaintext highlighter-rouge">fileprivate</code> a useful alert to the reader rather than, potentially, something that we routinely use and overlook so that we can separate implementations into extensions.</li>
</ul>
</li>
<li><code class="language-plaintext highlighter-rouge">private</code> is more closely aligned with other programming languages that use type-based access control, which can help programmers just coming to Swift. When they reach for <code class="language-plaintext highlighter-rouge">private</code>, they’re likely to get something similar to what they expect—with a little Swift twist due to Swift’s heavy use of extensions.</li>
<li>Loosening the access restrictions on <code class="language-plaintext highlighter-rouge">private</code> is unlikely to break existing code.</li>
</ul>
<p>There are likely some drawbacks:</p>
<ul>
<li>Developers using patterns that depend on the existing lexically-scoped access control of <code class="language-plaintext highlighter-rouge">private</code> may find this new interpretation of <code class="language-plaintext highlighter-rouge">private</code> to be insufficiently strict</li>
<li>Swift’s access control would go from “entirely lexical” to “partly lexical and partly type-based”, which can be viewed as being more complicated</li>
</ul>
<p>Thoughts? Volunteer?</p>
</blockquote>
<p>As I mentioned in my <a href="http://www.jessesquires.com/thoughts-on-swift-access-control/">blog post</a>, I regret the changes that brought the <code class="language-plaintext highlighter-rouge">fileprivate</code> and <code class="language-plaintext highlighter-rouge">open</code> access controls to Swift and wish we could have considered any changes to this cohesively as part of a <a href="https://oleb.net/blog/2017/03/swift-themed-releases/">Swift theme</a>. However, I believe this compromise the best way — or, <em>least terrible way</em> 😬 — forward given the circumstances and constraints.</p>
<p>There’s a lot of debate <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/thread.html">on the lists</a>. View points primarily fall into a two categories: (1) don’t do anything and reconsider these changes as part of a broader, holistic redesign of access control and submodules, or (2) implement the Core Team’s suggestion above. Other viewpoints suggest radical renames and redefinitions of the access control keywords, which simply isn’t going to happen because of Swift 4’s source compatibility goals.</p>
<p>The problem with (1) is that it doesn’t seem feasible to defer modifications to access control and address them later, due to churn, potential impact on ABI stability, and the overall roadmap for Swift — there is much more important and impactful work to be done.</p>
<p>From <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034949.html">John McCall</a>:</p>
<blockquote>
<p>This is why we asked swift-evolution to consider this last tweak: it is realistically the last opportunity to do it.</p>
</blockquote>
<p>From <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034940.html">Doug Gregor</a>:</p>
<blockquote>
<p>The core team felt strongly that we couldn’t change these keywords. Source stability is important to Swift 4, and “don’t break source compatibility so much” is one of the top requests we hear from Swift developers, much more so than requests for specific new language features.</p>
</blockquote>
<p>From <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034925.html">Xiaodi Wu</a>:</p>
<blockquote>
<p>I’m disappointed in this turn of events. While I thought that accepting SE-0159 would have been a better outcome than rejecting it, I am certain that this is an inferior choice to both of those outcomes.</p>
<p>The key problem isn’t principally <em>what</em> this proposed private is. It is that, if adopted, this would be the third flavor of private in as many years. It is a new design with its own kinks (what to do about <code class="language-plaintext highlighter-rouge">private extension</code>, for example?) and the resultant churn would be most unfortunate.</p>
</blockquote>
<p>From <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/034924.html">Daniel Duan</a>:</p>
<blockquote>
<p>I’m concerned that we will have access control changes in a future version yet again, when light-weight modules, or other type of enforced namespace is introduced. Does the core team have any foresight on how this change would interact with such things? I had the same concern for SE-0159 as well.</p>
<p>There’s a implicit drawback to all access control changes that migrator/fix-its cannot fix: we organize our code with tools in the language. Some colleague of mine had came up with schemes that combines file scope and Swift 3 <code class="language-plaintext highlighter-rouge">private</code> to hide details among separate protocol extensions, for example. Code ends up in certain places for a reason and updating access control invalidate those reasons.</p>
<p>I hesitate to support any changes until we have some ideas for what “ultimate glory” looks like.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170403/035016.html">Chris Lattner</a> chimed in, obviously taking a break from designing his yellow self-driving Tesla. 😉</p>
<blockquote>
<p>Another way to explain this is as a relaxation of the Swift 3 access control, that would allow private members in a type to also be accessible in extensions to that type, so long as they are in the same file.</p>
<p>While I typically try to avoid chiming in on early discussions like this, I pretty strongly believe that this is a good solution for the reasons you mention […]</p>
<p>From a pragmatic perspective, I feel like this is a great solution that really does solve the problems we have with current access control, all without breaking source compatibility. This is also a major progression from where we are, and doesn’t appear to cut off any future directions (e.g. submodules) since those are cross-file concepts that live between internal/public or between fileprivate/internal.</p>
<p>Just MHO, but I think that the rhetorical attempts to paint this as being similar to “protected” are unsound.</p>
</blockquote>
<p>In other discussions, Michael Gottesman <a href="https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20170403/005143.html">replied</a> to a thread on swift-users with some tips on how to narrow down where compiler crashes are happening to help debug. Some pretty helpful tips here!</p>
<h3 id="finally">Finally</h3>
<p>And finally — the <code class="language-plaintext highlighter-rouge">isn't</code> <a href="https://twitter.com/harlanhaskins/status/848172027760574465">operator</a>. Now <em>this</em> is a change I could get behind for Swift 4. 😂</p>
Issue #63
https://swiftweeklybrief.com/issue-63
2017-03-30T00:00:00-07:00
2017-03-30T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>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 <a href="https://bugs.swift.org">report any bugs, regressions, or other issues</a> that you run into.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://realm.io/news/marin-todorov-building-reactive-apps-with-realm-episode-1-swift-ios/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_63" target="_blank">Building Reactive Apps with Realm</a></h4>
<p>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.</p>
<p><small><a href="https://realm.io/news/marin-todorov-building-reactive-apps-with-realm-episode-1-swift-ios/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_63" target="_blank">realm.io</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 4: <a href="https://spec.fm/podcasts/swift-unwrapped/61852">Bridging with Objective-C</a></p>
<p>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.</p>
<h3 id="news-and-community">News and community</h3>
<p>Swift 3.1 was <a href="https://swift.org/blog/swift-3-1-released/">officially released</a>!</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Swift 3.1 includes the following proposals:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md">SE-0045: Add prefix(while:) and drop(while:) to stdlib</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md">SE-0141: Availability by Swift version</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080: Failable Numeric Conversion Initializers</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0147-move-unsafe-initialize-from.md">SE-0147: Move UnsafeMutablePointer.initialize(from:) to UnsafeMutableBufferPointer</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md">SE-0082: Package Manager Editable Packages</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md">SE-0145: Package Manager Version Pinning</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md">SE-0152: Package Manager Tools Version</a></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md">SE-0151: Package Manager Swift Language Compatibility Version</a></li>
</ul>
<p>Xcode 8.3 <a href="https://developer.apple.com/news/?id=03272017b">was released</a> along with updates to all of Apple’s platforms. Xcode 8.3 ships with Swift 3.1.</p>
<p>It looks like <a href="https://twitter.com/simjp/status/846790346306576384">JP Simard has already found an issue</a> in Xcode 8.3. <em>“Xcode 8.3 produces binaries 3x larger than Xcode 8.2 due to a 4x increase in bitcode.”</em> Oops. 😳 (<a href="http://www.openradar.me/31302382">rdar://31302382</a>)</p>
<p>Bas Broek <a href="https://basthomas.github.io/swift-evolution-without-swift-evolution">wrote a post</a> on the cost of Swift evolution, highlighting <a href="https://twitter.com/slava_pestov/status/845493232788160512">this Twitter thread</a> with Austin Zheng and Slava Pestov. This is something <a href="https://speakerdeck.com/jessesquires/140-proposals-in-30-minutes?slide=42">I’ve discussed before</a> 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 <a href="https://oleb.net/blog/2017/03/swift-themed-releases/">theme</a>. As Slava <a href="https://twitter.com/slava_pestov/status/845543712956440577">points out</a>, 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 href="https://speakerdeck.com/jessesquires/140-proposals-in-30-minutes?slide=21">a ton</a> of proposals.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Philippe Hausler (<a href="https://github.com/phausler">@phausler</a>) opened a <a href="https://github.com/apple/swift/pull/8283">pull request</a> to rework the backing storage for <code class="language-plaintext highlighter-rouge">CharacterSet</code> to be more performant and bridge correctly to Objective-c and CoreFoundation.</p>
<p>Doug Gregor (<a href="https://twitter.com/dgregor79">@dgregor79</a>) <a href="https://github.com/apple/swift/pull/8379">implemented</a> the majority of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md">SE-0160</a>: <em>Limiting <code class="language-plaintext highlighter-rouge">@objc</code> inference</em>.</p>
<p>Hugh Bellamy (<a href="https://github.com/hughbe">@hughbe</a>) 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 <a href="https://github.com/apple/swift/pull/8426">update</a> to get the <code class="language-plaintext highlighter-rouge">update-checkout</code> script working on Windows.</p>
<p>Slava Pestov (<a href="https://twitter.com/slava_pestov">@slava_pestov</a>) <a href="https://github.com/apple/swift/pull/8351">merged</a> SILGen fixes for <em>static</em> <code class="language-plaintext highlighter-rouge">Self</code>-returning methods. This is a crazy fix that I don’t completely understand. 😅 The first line of the commit says it all, <em>“Take a seat and pour yourself a beer because this is going to get pretty intense.”</em></p>
<h3 id="proposals">Proposals</h3>
<p>No official proposal decisions, although the review periods for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md">SE-0160</a> have ended. We’re still waiting on official emails from the Core Team.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>There’s still been heavy debate on the lists over <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a>: <em>Fix Private Access Levels</em>. The core arguments that I covered <a href="/issue-62/">last week</a> 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. 😄</p>
<p>Ben Cohen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170327/034652.html">pitched</a> a <a href="https://github.com/airspeedswift/swift-evolution/blob/3a822c799011ace682712532cfabfe32e9203fbb/proposals/0161-StringRevision1.md">draft proposal</a> that intends to implement a subset of changes from the <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md">Swift 4 String Manifesto</a>.</p>
<blockquote>
<p>This proposal is to implement a subset of the changes from the Swift 4 String Manifesto.</p>
<p>Specifically:</p>
<ul>
<li>Make <code class="language-plaintext highlighter-rouge">String</code> conform to <code class="language-plaintext highlighter-rouge">BidirectionalCollection</code></li>
<li>Make <code class="language-plaintext highlighter-rouge">String</code> conform to <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code></li>
<li>Create a <code class="language-plaintext highlighter-rouge">Substring</code> type for <code class="language-plaintext highlighter-rouge">String.SubSequence</code></li>
<li>Create a <code class="language-plaintext highlighter-rouge">Unicode</code> protocol to allow for generic operations over both types.</li>
<li>Consolidate on a concise set of C interop methods.</li>
<li>Revise the transcoding infrastructure.</li>
</ul>
<p>Other existing aspects of <code class="language-plaintext highlighter-rouge">String</code> remain unchanged for the purposes of this proposal.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/843658422788616196">static typing</a>.</p>
Issue #62
https://swiftweeklybrief.com/issue-62
2017-03-23T00:00:00-07:00
2017-03-23T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code> was open-sourced, a number of proposals were accepted, Swift releases have themes, and a new proposal for fixing access controls in Swift is now under review!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.hackingwithswift.com/store/server-side-swift/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_62" target="_blank">Server-Side Swift</a></h4>
<p>Hello, it’s Paul Hudson from Hacking with Swift again, and after four weeks you’re probably sick of seeing me here. So, I’ll cut to the chase and get out of your way — I wrote a book about Server-Side Swift, and I think you’d like it.</p>
<p><small><a href="https://www.hackingwithswift.com/store/server-side-swift/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_62" target="_blank">hackingwithswift.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>Episode 3: <a href="https://spec.fm/podcasts/swift-unwrapped/61851">Source Stability (What is a Source Breaking Change?)</a></p>
<p>Every Swift developer who has migrated code bases from Swift 1.x to 2.x, or even the more tedious 2.x to 3.x knows the pain of migrating to new Swift versions. In this episode we cover the intricacies of source stability and source-breaking changes. What exactly is a source-breaking change? It’s not as straight-forward as you may think!</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="http://lists.llvm.org/pipermail/llvm-dev/2017-March/111025.html">LLVM 4.0.0</a> was <a href="http://releases.llvm.org/4.0.0/docs/ReleaseNotes.html">released</a> this week. Congrats to those involved!</p>
<p>Ole Begemann wrote a post, <a href="https://oleb.net/blog/2017/03/swift-themed-releases/">Swift Releases Have Themes</a>, about a thoughtful message from Swift Core Team member Ben Cohen. Ole thinks Ben’s message on swift-evolution deserves more attention, and I agree! It is a couple of weeks old, so sorry for missing this in last week’s issue! 😳 Ole quotes the entire message and provides some commentary. Definitely read this. It’s important for the community to be aware of and help pursue the themes of each Swift release.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>In the <a href="/issue-61/">last</a> <a href="/issue-60/">couple</a> of issues, we discussed the removal and resurrection of <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code>. This week, Ted Kremenek <a href="https://github.com/apple/swift/pull/8258">made the tool open source</a>!</p>
<p>Manav Gabhawala (<a href="https://github.com/manavgabhawala">@manavgabhawala</a>) opened a <a href="https://github.com/apple/swift/pull/8144">pull request</a> that implements a robin hood algorithm for hash collisions in <code class="language-plaintext highlighter-rouge">Set</code> and <code class="language-plaintext highlighter-rouge">Dictionary</code>. It looks like this will improve performance and fix 3 SR issues, although we’re still waiting on benchmark results from the swift-ci bot.</p>
<p>Ankit Aggarwal (<a href="https://github.com/aciidb0mb3r">@aciidb0mb3r</a>) <a href="https://github.com/apple/swift-package-manager/pull/1024">implemented</a> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md">SE-0158</a>, redesigning the Swift Package Manager API. The API now adheres to the Swift 3 guidelines! 🎉</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156</a>: <em>Class and Subtype existentials</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000331.html">accepted</a>.</p>
<blockquote>
<p>The proposal was very well-received and is accepted with one modification: the ordering rules for existential types that involve <code class="language-plaintext highlighter-rouge">AnyObject</code> or a <code class="language-plaintext highlighter-rouge">class</code> type will be removed.</p>
<p>The ordering rules were intended to improve code clarity by requiring that the <code class="language-plaintext highlighter-rouge">class</code> (or <code class="language-plaintext highlighter-rouge">AnyObject</code>) constraint come first - <code class="language-plaintext highlighter-rouge">AnyObject & P</code> would be well-formed but <code class="language-plaintext highlighter-rouge">P & AnyObject</code> would be an error—enforcing more uniformity for Swift code and echoing a similar restriction that already exists for class definitions, where the superclass must come first. However, the ability to compose typealiases complicated the ordering rules considerably, and - <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033365.html">as noted</a> by Matthew Johnson - don’t provide the guarantee that the class constraint will always be first. Therefore, the core team felt that the resulting ordering rules introduced more complexity than they provided clarity, and therefore do not belong in the language.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>: <em>Support recursive constraints on associated types</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034266.html">accepted</a>.</p>
<blockquote>
<p>The feedback on the proposal was unfailingly positive. Accordingly, the proposal has been accepted without further modification.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md">SE-0158</a>: <em>Package Manager Manifest API Redesign</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000330.html">accepted</a> for Swift 4.</p>
<blockquote>
<p>The proposal is accepted with the following revisions:</p>
<ul>
<li>The <code class="language-plaintext highlighter-rouge">To</code> in <code class="language-plaintext highlighter-rouge">upToNextMajor</code> and <code class="language-plaintext highlighter-rouge">upToNextMinor</code> will be capitalized.</li>
<li><code class="language-plaintext highlighter-rouge">upToNextMajor()</code> and <code class="language-plaintext highlighter-rouge">upToNextMinor()</code> will name the first parameter <code class="language-plaintext highlighter-rouge">from:</code> for clarity.</li>
<li><code class="language-plaintext highlighter-rouge">.only</code> will be removed, as it was duplicative versus <code class="language-plaintext highlighter-rouge">.exact</code>.</li>
<li>We will have cases for <code class="language-plaintext highlighter-rouge">.branch</code> and <code class="language-plaintext highlighter-rouge">.revision</code> version specifiers, but will not provide special package initializers with named parameters for these.</li>
</ul>
<p>This proposal was generally supported, though it did require some discussion and minor revision, and some users are eager for future proposals adding new API not covered by this proposal.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a>: <em>Fix Private Access Levels</em> by David Hart is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000332.html">under review</a>.</p>
<blockquote>
<p>This proposal presents the problems that came with the the access level modifications in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a> and proposes reverting to Swift 2 behaviour.</p>
<p>Since the release of Swift 3, the access level change of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a> was met with dissatisfaction by a substantial proportion of the general Swift community. Those changes can be viewed as <em>actively harmful</em>, the new requirement for syntax/API changes.</p>
<p>The <code class="language-plaintext highlighter-rouge">private</code> keyword is a “soft default” access modifier for restricting access within a file. Scoped access is not a good behavior for a “soft default” because it is extremely common to use several extensions within a file. A “soft default” (and therefore <code class="language-plaintext highlighter-rouge">private</code>) should work well with this idiom. It is fair to say that changing the behavior of <code class="language-plaintext highlighter-rouge">private</code> such that it does not work well with extensions meets the criteria of actively harmful in the sense that it subtly encourages overuse of scoped access control and discourages the more reasonable default by giving it the awkward name <code class="language-plaintext highlighter-rouge">fileprivate</code>.</p>
<p>[…]</p>
<p>The <code class="language-plaintext highlighter-rouge">private</code> keyword should be reverted back to its Swift 2 file-based meaning and the <code class="language-plaintext highlighter-rouge">fileprivate</code> keyword should be deprecated.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0160-objc-inference.md">SE-0160</a>: <em>Limiting <code class="language-plaintext highlighter-rouge">@objc</code> inference</em> by Doug Gregor is <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034267.html">under review</a>. Notably, the review manager is Chris Lattner. 😄</p>
<blockquote>
<p>One can explicitly write <code class="language-plaintext highlighter-rouge">@objc</code> on any Swift declaration that can be expressed in Objective-C. As a convenience, Swift also <em>infers</em> <code class="language-plaintext highlighter-rouge">@objc</code> in a number of places to improve interoperability with Objective-C and eliminate boilerplate. This proposal scales back the inference of <code class="language-plaintext highlighter-rouge">@objc</code> to only those cases where the declaration <em>must</em> be available to Objective-C to maintain semantic coherence of the model, e.g., when overriding an <code class="language-plaintext highlighter-rouge">@objc</code> method or implementing a requirement of an <code class="language-plaintext highlighter-rouge">@objc</code> protocol. Other cases currently supported (e.g., a method declared in a subclass of <code class="language-plaintext highlighter-rouge">NSObject</code>) would no longer infer <code class="language-plaintext highlighter-rouge">@objc</code>, but one could continue to write it explicitly to produce Objective-C entry points.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>As expected, there is a lot of debate in the review of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md">SE-0159</a>: <em>Fix Private Access Levels</em> on the lists. The community is somewhat mixed, but it seems there is mostly strong support for the proposal. As I’ve mentioned before, I strongly support this proposal as well. I think the introduction of <code class="language-plaintext highlighter-rouge">fileprivate</code> (and later, <code class="language-plaintext highlighter-rouge">open</code>) introduced unnecessary complexity in Swift’s access control story for very little tangible benefits. (I’d like to see <code class="language-plaintext highlighter-rouge">open</code> removed as well, but I highly doubt that will happen. 😄)</p>
<p>In support of the proposal, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034161.html">Xiaodi Wu writes</a>:</p>
<blockquote>
<p>[…] the proposed solution itself is succinct, unambiguous, and easily understood. It does not argue that the new access level in Swift 3 has no merit, but rather that it has defects sufficient to merit a reversal to what we had before. The migration path is clear and unlikely to cause major problems. Therefore, as I agree with the arguments, I support the proposal.</p>
<p>[…]</p>
<p>However, real-world experience now demonstrates that <code class="language-plaintext highlighter-rouge">fileprivate</code> is <em>not</em> rarely seen. In fact, as the data above bear out, it is very hard not to use <code class="language-plaintext highlighter-rouge">fileprivate</code> when writing code in at least one very common Swift style (i.e. using same-file extensions). The point is well taken–but in the end it isn’t germane to the argument–that <em>some</em> styles of Swift code do not have to use <code class="language-plaintext highlighter-rouge">fileprivate</code>. The point is that the core team’s acceptance of the design was based on a prediction that did not turn out to be true: namely, that idiomatic Swift would rarely need <code class="language-plaintext highlighter-rouge">fileprivate</code>. As a consequence, more users now have to contend with more access modifiers than anticipated.</p>
<p>I disagree that there needs to be much more said about “complexity”–it is self-evident that four access modifiers are more complex than three. (And yes, I agree with previous arguments on this list that only two access modifiers are really necessary at all: internal and public.)</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034161.html">Continue reading…</a></p>
</blockquote>
<p>In opposition to the proposal, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034190.html">Matthew Johnson writes</a>:</p>
<blockquote>
<p>I am also -1. I think there are two issues to be considered. One is scoped access itself and the other is the names of the access levels.</p>
<p>I think a reasonable case can be made that changing the meaning of private and introducing fileprivate was a mistake. We probably should have left private alone and chosen a new name for scoped access. There was abundant bikeshedding over this at the time, but now we have the benefit of experience. I believe we should have simply called scoped access control <code class="language-plaintext highlighter-rouge">scoped</code>. It’s clear that some people would still oppose scoped access but I also don’t think we’d be revisiting this topic if we hadn’t changed the meaning of <code class="language-plaintext highlighter-rouge">private</code>. The passionate dislike of the feature seems to me mostly related to stealing the <code class="language-plaintext highlighter-rouge">private</code> keyword.</p>
<p>I support correcting the naming mistake eventually. I’m neutral as to whether Swift 4 is the right time to do that. We just introduced a lot of churn in Swift 3. There is still inconsistency in Swift’s access control system as well as unmet needs (especially around submodules). It may be better to leave things alone for a release and make the change as part of a larger set of changes when access control and submodules are part of a release “theme”.</p>
<p>I am extremely unconvinced that having a scoped access level is actively harmful. It introduces another choice in the language but no individual programmers or teams are forced to use the additional flexibility if they don’t want to. It would be very easy for linters to prohibit scoped access if there are teams that don’t want to use it. It is one extra degree of control for new programmers to learn but properly taught it helps programmers learn to think about encapsulation. This is a good thing.</p>
<p>[…]</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034190.html">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/slava_pestov/status/844752650025426944">move fast and break things</a>. 😏</p>
Issue #61
https://swiftweeklybrief.com/issue-61
2017-03-16T00:00:00-07:00
2017-03-16T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week on <a href="https://spec.fm/podcasts/swift-unwrapped/61850">Swift Unwrapped</a> we discuss SourceKit and the tumultuous tales of the community getting SourceKit compiling on Linux. Ted Kremenek announced that <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code> will <em>remain</em> in Xcode, and Itai Ferber shared draft proposals for new Swift-focused archival and serialization APIs for Foundation.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.hackingwithswift.com/store/swift-power-pack/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_61" target="_blank">Swift Power Pack</a></h4>
<p>Hello, it’s Paul Hudson again, still with Hacking with Swift, and still helping to support this awesome newsletter. Perhaps I should hire a marketing team. In the meantime, check out my Swift Power Pack – you get my first six books at the discounted bundle price of just $100.</p>
<p><small><a href="https://www.hackingwithswift.com/store/swift-power-pack/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_61" target="_blank">hackingwithswift.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>In this week’s episode — <a href="https://spec.fm/podcasts/swift-unwrapped/61850">SourceKit (Compiling by default)</a> — we dive into the framework we love to hate to love: SourceKit. We wrap up with an overview of method dispatch in Swift. As always, let us know what you think. If you have a second, <a href="https://itunes.apple.com/us/podcast/swift-unwrapped/id1209817203">rate us on iTunes</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ayaka Nonaka’s (<a href="https://twitter.com/ayanonagon">@ayanonagon</a>) talk from Swift Summit, <a href="https://www.skilled.io/u/swiftsummit/contributing-to-the-swift-compiler"><em>Contributing to the Swift compiler</em></a>, is now available. This talk is absolutely great. It was one of my favorites from Swift Summit. If you are interested in contributing, but not sure where to start, this is a must-watch video! You can find the <a href="https://speakerdeck.com/ayanonagon/contributing-to-swift">slides here</a>.</p>
<p><a href="/issue-60/">Last week</a> the community was concerned about the removal of <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code>. Brian Gesiak (<a href="https://twitter.com/modocache">@modocache</a>) wrote a post, <a href="http://modocache.io/swift-stdlib-tool"><em>Why do I care about swift-stdlib-tool?</em></a>, to explain why this is command line tool is so important for the community. After what I can only imagine were <strong>a lot</strong> of radars, Ted Kremenek <a href="https://twitter.com/tkremenek/status/841179077130170368">confirmed</a> that Xcode 8.3 will ship with <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code>. 🎉</p>
<p>John Regehr wrote an awesome article, <a href="https://blog.regehr.org/archives/1453"><em>A Tourist’s Guide to the LLVM Source Code</em></a>. This isn’t new (written in January 2017) but I’m sure it’s recent enough to still be relevant. Thanks to <a href="https://twitter.com/modocache/status/841014140290363392">Brian Gesiak</a> for sharing this week. If your interest in Swift runs deeper than Swift itself and you want to get involved in <a href="http://llvm.org">LLVM</a>, this looks like a fantastic resource.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Robert Widmann (<a href="https://github.com/CodaFi">@CodaFi</a>) <a href="https://github.com/apple/swift/pull/8059">resolved</a> 22 compiler crashers and then followed that up by <a href="https://github.com/apple/swift/pull/8066">fixing</a> 24 more! 😱 Slava (known for smashing tons of bugs) better watch out! 😆</p>
<p>Slava Pestov (<a href="https://github.com/slavapestov">@slavapestov</a>) <a href="https://github.com/apple/swift/pull/8091">fixed</a> a <a href="https://bugs.swift.org/browse/SR-3541">crash</a> when calling a method on a generic base class with a concrete subclass, which has been broken since <a href="https://twitter.com/slava_pestov/status/841814023507136512">at least Swift 2</a>.</p>
<p>Erik Eckstein (<a href="https://github.com/eeckstein">@eeckstein</a>) <a href="https://github.com/apple/swift/pull/8018">merged changes</a> to IRGen to emit type metadata and (value) witness tables lazily, which could result in binary size reductions up to 20 percent! 🙌</p>
<blockquote>
<p>This gives big code size wins for unused types and also for types, which are never used in a generic context. Also it reduces the amount of symbols in the symbol table. The size wins heavily depend on the project. I have seen binary size reductions from 0 to 20% on real world projects.</p>
</blockquote>
<p>Andrew Bennett (<a href="https://github.com/therealbnut">@therealbnut</a>) <a href="https://github.com/apple/swift/pull/7420">added</a> benchmarks for <code class="language-plaintext highlighter-rouge">dropLast</code> and <code class="language-plaintext highlighter-rouge">suffix</code> in the stdlib.</p>
<p>The <a href="https://github.com/swift-server">Swift server work group</a> held their second HTTP stream meeting. Chris Bailey (<a href="https://github.com/seabaylea">@seabaylea</a>) has <a href="https://github.com/swift-server/work-group/pull/74">posted</a> the initial meeting notes, though they are currently empty.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates on proposals this week! Check <a href="https://apple.github.io/swift-evolution/">the status page</a> for details.</p>
<p>Currently under active review:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md">SE-0158</a>: <em>Package Manager Manifest API Redesign</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>: <em>Support recursive constraints on associated types</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156</a>: <em>Class and Subtype existentials</em></li>
</ul>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Itai Ferber (<a href="https://github.com/itaiferber">@itaiferber</a>) <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033910.html">started a thread</a> with a proposal draft for a new Swift-focused archival and serialization API for Foundation.</p>
<blockquote>
<p>The following introduces a new Swift-focused archival and serialization API as part of the Foundation framework. We’re interested in improving the experience and safety of performing archival and serialization, and are happy to receive community feedback on this work.
Because of the length of this proposal, the Appendix and Alternatives Considered sections have been omitted here, but are available in the <a href="https://github.com/apple/swift-evolution/pull/639">full proposal</a> on the swift-evolution repo. The full proposal also includes an Unabridged API for further consideration.</p>
</blockquote>
<p>From the <a href="https://github.com/apple/swift-evolution/pull/639">proposal</a> introduction:</p>
<blockquote>
<p>Foundation’s current archival and serialization APIs (<code class="language-plaintext highlighter-rouge">NSCoding</code>, <code class="language-plaintext highlighter-rouge">NSJSONSerialization</code>, <code class="language-plaintext highlighter-rouge">NSPropertyListSerialization</code>, etc.), while fitting for the dynamism of Objective-C, do not always map optimally into Swift. This document lays out the design of an updated API that improves the developer experience of performing archival and serialization in Swift.</p>
<p>Specifically: <br /></p>
<ul>
<li>It aims to provide a solution for the archival of Swift <code class="language-plaintext highlighter-rouge">struct</code> and <code class="language-plaintext highlighter-rouge">enum</code> types</li>
<li>It aims to provide a more type-safe solution for serializing to external formats, such as JSON and plist</li>
</ul>
</blockquote>
<p>This is great news! This is certainly something that the community has wanted for awhile. I’m sure Nick O’Neill would be happy to stop maintaining <a href="https://github.com/nickoneill/Pantry">Pantry</a>, a library built to solve this problem.</p>
<p>Further, Itai <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170313/033909.html">followed up</a> with a companion proposal for Swift encoders:</p>
<blockquote>
<p>This is a companion proposal to the <a href="https://github.com/apple/swift-evolution/pull/639">Foundation Swift Archival & Serialization API</a>. This introduces new encoders and decoders to be used as part of this system. The proposal is available <a href="https://github.com/apple/swift-evolution/pull/640">online</a>…</p>
</blockquote>
<p>From the <a href="https://github.com/apple/swift-evolution/pull/640">proposal</a> introduction:</p>
<blockquote>
<p>As part of the proposal for a Swift archival and serialization API (SE-NNNN), we are also proposing new API for specific new encoders and decoders, as well as introducing support for new <code class="language-plaintext highlighter-rouge">Codable</code> types in <code class="language-plaintext highlighter-rouge">NSKeyedArchiver</code> and <code class="language-plaintext highlighter-rouge">NSKeyedUnarchiver</code>.</p>
<p>This proposal composes the latter two stages laid out in SE-NNNN.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/842104864301694976">Does this mean Swift and ObjC are webscale now</a>?</p>
Issue #60
https://swiftweeklybrief.com/issue-60
2017-03-09T00:00:00-08:00
2017-03-09T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week we launched the <a href="https://spec.fm/podcasts/swift-unwrapped">Swift Unwrapped</a> podcast! While Swift 3.1 development is chugging along with fixes and refinements, there’s worry in the community about the removal of <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code> from Xcode 8.3 beta. Also, this week will be known as “bring your own submodule proposal” week — there have been a number of different proposals on the topic.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://gumroad.com/l/natural-swift/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_60" target="_blank">Free video: Natural Swift</a></h4>
<p>Hello, it’s Paul Hudson again, still with Hacking with Swift, and still helping to support this awesome newsletter. After you’ve finished reading, why not download my Natural Swift video? It’s 75 minutes of pure Swift goodness, and completely free.</p>
<p><small><a href="https://gumroad.com/l/natural-swift/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_60" target="_blank">gumroad.com</a></small></p>
</div>
<h3 id="swift-unwrapped">Swift Unwrapped</h3>
<p>This week <a href="https://twitter.com/simjp">JP Simard</a> and I launched our new podcast, <a href="https://spec.fm/podcasts/swift-unwrapped">Swift Unwrapped</a>! We plan to discuss the Swift language, its evolution and development, the Swift.org open source projects, and general Swifty news. Think of it as an extension of and commentary on this newsletter where we’ll be doing deep dives on various topics and elaborating on concepts in greater detail. Our <a href="https://spec.fm/podcasts/swift-unwrapped/61849">first episode</a> is a retrospective on the first full year of open source Swift development, reflecting on where we’ve been and how we got here. You can <a href="https://itunes.apple.com/us/podcast/swift-unwrapped/id1209817203">subscribe on iTunes</a>. If you enjoy it, please consider leaving us a rating or review on iTunes!</p>
<h3 id="news-and-community">News and community</h3>
<p>When it comes to supporting Swift, Google and Facebook appear to have something in common: their build tools rely on the existence of <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code>, an Apple utility built into Xcode, which copies the Swift runtime into an application bundle. For an in-depth look at <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code>, consider reading <a href="https://pewpewthespells.com/blog/swift_and_objc.html">this Technical Q&A</a> by Samantha Marshall (<a href="https://twitter.com/queersorceress">@queersorceress</a>). (And don’t forget to click on the “Donate” button at the bottom of that page.) Dmitry Shevchenko (<a href="https://twitter.com/dmishe89">@dmishe89</a>) <a href="https://bugs.swift.org/browse/SR-3957">reported</a> that <code class="language-plaintext highlighter-rouge">swift-stdlib-tool</code> has been removed in Xcode 8.3b2, and <a href="https://openradar.appspot.com/radar?id=5608273688395776">filed</a> an Apple Radar. If you use <a href="https://bazel.build">Bazel</a> or <a href="https://buckbuild.com">Buck</a> to compile iOS apps, and you’d like those tools to support Swift, you could help by duplicating the Radar.</p>
<p><a href="https://twitter.com/nicklockwood/status/839264831362502656">Nick Lockwood</a> released v0.25.0 of his <a href="https://github.com/nicklockwood/SwiftFormat">SwiftFormat</a> tool, which now supports custom header comment templates, hoists <code class="language-plaintext highlighter-rouge">var</code>/<code class="language-plaintext highlighter-rouge">let</code> out of patterns, and more.</p>
<p><a href="https://twitter.com/olebegemann/status/839263316258193409">Ole Begemann</a> shared a tip for checking if a specific commit will be included in Swift 3.1:</p>
<blockquote>
<p>To check if a specific commit will make it into Swift 3.1:</p>
<p><code class="language-plaintext highlighter-rouge">git branch -r --contains <commit></code></p>
<p>and look for <code class="language-plaintext highlighter-rouge">origin/swift-3.1-branch</code>.</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov (<a href="https://twitter.com/slava_pestov">@slava_pestov</a>) <a href="https://github.com/apple/swift/pull/7887">fixed</a> a conformance lookup issue. When substituting a type like <code class="language-plaintext highlighter-rouge">T.A.B</code> where <code class="language-plaintext highlighter-rouge">A</code> and <code class="language-plaintext highlighter-rouge">B</code> are associated types and the conformance requirement on <code class="language-plaintext highlighter-rouge">T.A</code> is implied by conformance requirements on <code class="language-plaintext highlighter-rouge">T</code>, the compiler would crash. This is <a href="https://bugs.swift.org/browse/SR-4088">a regression</a> that I <a href="https://github.com/jessesquires/JSQDataSourcesKit/issues/95">ran into recently</a> in the latest Xcode beta. This was one of those times where <a href="https://twitter.com/slava_pestov/status/837818707871047681">having access to the Core Team</a> via Twitter, and having Swift open source on GitHub really made a difference for me!</p>
<p>Jordan Rose (<a href="https://twitter.com/UINT_MIN">@UINT_MIN</a>) landed an <a href="https://twitter.com/slava_pestov/status/839289812964139008">epic bug fix</a>. (<a href="https://github.com/apple/swift/pull/7963"><code class="language-plaintext highlighter-rouge">master</code> PR</a>, <a href="https://github.com/apple/swift/pull/7967"><code class="language-plaintext highlighter-rouge">3.1-branch</code> PR</a>) It’s super interesting. I’d recommend reading the pull request descriptions and commit messages if you’re curious about the details. In short, this bug led to nonsensical errors like <code class="language-plaintext highlighter-rouge">'C.Iterator' is not the same type as 'C.Iterator'</code>, which I’ve seen before. And verifying the fix only required <a href="https://twitter.com/UINT_MIN/status/839259261716746240">compiling 400 times</a>!</p>
<p>Gonzalo Larralde (<a href="https://github.com/gonzalolarralde">@gonzalolarralde</a>) <a href="https://github.com/apple/swift/pull/7777">merged changes</a> to specify the linker for Android ARMv7 targets.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0158-package-manager-manifest-api-redesign.md">SE-0158</a>: <em>Package Manager Manifest API Redesign</em> by Ankit Aggarwal is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000329.html">under review</a>.</p>
<blockquote>
<p>This is a proposal for redesigning the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest APIs provided by Swift Package Manager.
This proposal only redesigns the existing public APIs and does not add any new functionality; any API to be added for new functionality will happen in separate proposals.</p>
<p>The <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest APIs were designed prior to the API Design Guidelines, and their design was not reviewed by the evolution process. Additionally, there are several small areas which can be cleaned up to make the overall API more “Swifty”.</p>
<p>We would like to redesign these APIs as necessary to provide clean, conventions-compliant APIs that we can rely on in the future. Because we anticipate that the user community for the Swift Package Manager will grow considerably in Swift 4, we would like to make these changes now, before more packages are created using the old API.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Philippe Hausler (<a href="https://github.com/phausler">@phausler</a>) opened a <a href="https://github.com/apple/swift/pull/7979">pull request</a> to fix a build failure for importing <code class="language-plaintext highlighter-rouge">NSUInteger</code> as <code class="language-plaintext highlighter-rouge">Int</code>. Not terribly interesting, except for Jordan Rose’s <a href="https://github.com/apple/swift/pull/7979#issuecomment-285099500">comment</a> linking to <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031327.html">this mailing list thread</a> about <code class="language-plaintext highlighter-rouge">NSUInteger</code> inconsistencies from a month ago about:</p>
<blockquote>
<p>I want to draw attention to one of the oddest parts of the Objective-C importer today: <code class="language-plaintext highlighter-rouge">NSUInteger</code>. TLDR: <code class="language-plaintext highlighter-rouge">NSUInteger</code> is treated differently based on whether it comes from a system framework or a user-provided header file. I think this is silly and that we should treat it consistently everywhere, but I haven’t had time to go collect data to demonstrate that this is a safe change. Would someone like to take that on? […]</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031327.html">Continue reading…</a></p>
</blockquote>
<p>He explains how <code class="language-plaintext highlighter-rouge">NSUInteger</code> is commonly used in frameworks like <code class="language-plaintext highlighter-rouge">Foundation</code>, how Swift treats its when importing in certain scenarios, and why all of this is problematic. Fascinating read!</p>
<p>Last week Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033376.html">started discussions</a> to revisit <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md">SE-0083</a>: <em>Remove bridging conversion behavior from dynamic casts</em>.</p>
<blockquote>
<p>I’d like to investigate separating Objective-C bridging from the behavior of the as/as?/is operator family again for Swift 4. Last year, I proposed <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md">SE–0083</a>, but we deferred the proposal for lack of time to evaluate its impact. As complicating factors, we now have source compatibility with Swift 3 as a requirement, and the id-as-Any work from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md">SE–0116</a> more or less requires bridging dynamic casts to work. I think we can nonetheless make important improvements in this area in order to simplify the core language and provide more portable behavior across platforms with and without ObjC interop. In retrospect, submitting SE–0083 as an omnibus “fix casting” proposal was a mistake. We can separate out a few smaller subproblems from the overall concept […]</p>
</blockquote>
<p>Later in the thread, Joe elaborates on the <code class="language-plaintext highlighter-rouge">as</code> operator:</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">as</code> isn’t generally for type conversion, it’s for type <em>coercion</em>, giving the type checker additional information it can’t infer. If not for the legacy of inducing bridging conversions, <code class="language-plaintext highlighter-rouge">as</code> wouldn’t ever have any effect on its own. Having <code class="language-plaintext highlighter-rouge">as</code> sometimes be semantically neutral and sometimes introduce behavior compromises that meaning, since you can’t trust that <code class="language-plaintext highlighter-rouge">as</code> doesn’t have other side effects. Aside from the bridging conversions, all other conversion operations in the library are handled by initializers, so it would be more consistent to do the same for explicit bridging operations. Ideally, over time, the native Swift data types will be powerful enough, and the Clang importer and overlays comprehensive enough, to reach the point where explicit bridging conversions are rarely necessary to begin with.</p>
</blockquote>
<p>There are numerous discussions on a (sub)module system for Swift, continuing from previous weeks and prompted by Robert Widmann’s (<a href="https://twitter.com/CodaFi_">@CodaFi_</a>) original <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032678.html">proposal draft email</a>. There are a number of <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033430.html">different</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033524.html">module system</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033520.html">proposals</a> floating around now and being debated. You know everything is going great when each email begins with <em>“Sorry for yet another submodule proposal.”</em> 😆 😅 🍿 Anyway, the community seems far from reaching a consensus here.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ayanonagon/status/839238968004616192">maybe we have <em>too many</em> JSON parsers</a>?</p>
Issue #59
https://swiftweeklybrief.com/issue-59
2017-03-02T00:00:00-08:00
2017-03-02T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>What happened since last week other than <a href="https://twitter.com/awscloud/status/836666493668466689">the Internet</a> <a href="https://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/">bursting</a> <a href="https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html">into flames</a>? Let’s find out! 😄</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://www.hackingwithswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_59" target="_blank">Hacking with Swift</a></h4>
<p>Hello, it’s Paul Hudson here from Hacking with Swift. I’m not going to use this spot to sell you stuff, I just wanted to help support this awesome newsletter. Thanks for all your hard work, Jesse and co!</p>
<p><small><a href="https://www.hackingwithswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_59" target="_blank">hackingwithswift.com</a></small></p>
</div>
<h3 id="news-and-community">News and community</h3>
<p>The Mozilla mobile team <a href="https://mozilla-mobile.github.io/ios/firefox/swift/core/2017/02/22/migrating-to-swift-3.0.html">wrote about their migration to Swift 3.0</a> for <a href="https://github.com/mozilla-mobile/firefox-ios">Firefox for iOS</a>. It’s another in-depth look from the community at the pain, sweat, and tears involved in migrating. If we’re lucky, this will be one of the last posts we see like this. The unique thing about Firefox is that the entire app is <a href="https://github.com/mozilla-mobile/firefox-ios">open source</a>, so you see the details up close. The good news, however, is that future versions of the Swift compiler (beginning with 3.1) will feature a “compatibility mode” which should help ease these kinds of transitions — not to mention, source-breaking changes now undergo much more scrutiny.</p>
<p>Craig Hockenberry wrote an article, <a href="http://furbo.org/2017/02/17/swift-changes-considered-harmful/">Swift Changes Considered Harmful</a>. He notes a very practical negative impact of Swift’s rapid evolution, that WWDC sample code <strong>from 2016</strong> no longer compiles and StackOverflow answers are often outdated — resulting in a detrimental experience for beginners. There’s at least one solution here: Apple should update all Swift code samples for Swift 3.0 or provide sample code in Objective-C.</p>
<p><a href="https://twitter.com/SmileyKeith/status/835677088724049921">Keith Smiley</a> had one of those “this StackOverflow answer should be a blog post” moments, answering <a href="http://stackoverflow.com/questions/37847271/is-it-possible-to-dump-the-ast-while-building-an-xcode-project/42463996#42463996">a question</a> about dumping the Swift AST of an app. And then he wrote <a href="https://github.com/keith/xcode-ast-dump">some scripts</a> to help! 👏 🙌</p>
<p>Thanks to <a href="https://twitter.com/steipete/status/835043149840068608">Peter Steinberger</a>, I discovered Sandy Martel’s <a href="https://github.com/sandym/swiftpp">swiftpp</a> project. <em>“swiftpp is a clang tool that automatically generates the glue code to let a swift class inherit from a C++ class. You can override C++ virtual methods from the swift derivative as well.”</em></p>
<p>Another project of note is <a href="https://github.com/bazelbuild/tulsi">Tulsi</a> — an Xcode Project Generator for <a href="https://github.com/bazelbuild/bazel">bazel</a>, Google’s build tool. (Similar to Facebook’s <a href="https://github.com/facebook/buck">buck</a>.) If everyone keeps building their own build tools, I’m sure one of them will eventually mostly work most of the time. 😄 Maybe Xcode <a href="http://isxcodeopensourceyet.github.io">should be open source</a>?</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="/issue-58/">Last week</a> I lamented Graydon Hoare’s <a href="https://github.com/apple/swift/pull/7676">revert</a> of the <a href="https://swift.org/blog/bridging-pch/">bridging PCH feature</a> by default. This week Ted Kremenek <a href="https://github.com/apple/swift/pull/7763">reverted the revert</a> to again make bridging PCH the default. <a href="https://cdn.meme.am/cache/instances/folder609/500x/67178609.jpg">I heard the Core Team likes reverts</a>.</p>
<p>Roman Levenstein (<a href="https://github.com/swiftix">@swiftix</a>) merged <a href="https://github.com/apple/swift/pull/7751">improvements</a> to the SIL optimizer, resulting in reducing the code size of the stdlib by about 9.4%.</p>
<p>Ben Cohen (<a href="https://github.com/airspeedswift">@airspeedswift</a>) got the 👩❤️👩 emoji <a href="https://github.com/apple/swift/commit/ad080c1db3dd15a129deab2de0f8956b5df58e22">working</a> on the <code class="language-plaintext highlighter-rouge">unicode-rethink</code> branch.</p>
<p>Nate Cook (<a href="https://github.com/natecook1000">@natecook1000</a>) <a href="https://github.com/apple/swift/pull/7617">added</a> a benchmark for quadratic hash performance to help address <a href="https://bugs.swift.org/browse/SR-3268">SR-3268</a>.</p>
<p>Nethra Ravindran (<a href="https://github.com/nethraravindran">@nethraravindran</a>) <a href="https://github.com/apple/swift-corelibs-foundation/pull/897">fixed</a> a memory leak in <code class="language-plaintext highlighter-rouge">NSURLComponents</code> in corelibs-foundation.</p>
<p>The <strong>@swift-ci</strong> bot got a <a href="https://github.com/swift-ci">cute new avatar</a>!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md">SE-0153</a>: <em>Compensate for the inconsistency of <code class="language-plaintext highlighter-rouge">@NSCopying</code>’s behaviour</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000327.html">accepted</a> for Swift 4.</p>
<blockquote>
<p>The proposal is accepted using the “compiler magic” approach, where the compiler will introduce the copy within the initialization to maintain the invariant that the stored property is always initialized with or set to a copy of the provided value.</p>
<p>Feedback from the review was mixed. There was general agreement that this was a real problem that does require a solution, but the discussion during the review slightly favored the more conservative approach of adding a warning in the compiler. This was based on two main concerns about introducing the copy within the initializer:</p>
<p>1) <code class="language-plaintext highlighter-rouge">@NSCopying</code> would act differently from <code class="language-plaintext highlighter-rouge">didSet</code>, the latter of which still would not be called within initializers, and
2) Concern that property behaviors would not be able to model the semantics described here.</p>
<p>The core team felt that <code class="language-plaintext highlighter-rouge">@NSCopying</code> needs to guarantee that the copy occurs under all circumstances, and that a change in language semantics here is warranted. Regarding concern (1), the core team felt that <code class="language-plaintext highlighter-rouge">@NSCopying</code> and <code class="language-plaintext highlighter-rouge">didSet</code> are different enough that different behavior is reasonable and expected. Regarding concern (2), the core team noted that property behaviors can model the new semantics by providing behaviors with an extra customization point that is invoked from within the initializer (and does not have access to “self”). Moreover, having this customization point in property behaviors will make concern (1) less acute, because property behaviors can and will differ in their initialization vs. setting behavior.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md">SE-0154</a>: <em>Provide Custom Collections for Dictionary Keys and Values</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000324.html">accepted</a> for Swift 4.</p>
<blockquote>
<p>Feedback was generally positive, and the core team felt that this proposal was a useful step forward for <code class="language-plaintext highlighter-rouge">Dictionary</code>, providing more flexibility for the standard library ABI and better performance. However, the core team noted that acceptance of this proposal should not preclude improvements to the ergonomics of <code class="language-plaintext highlighter-rouge">Dictionary</code>, even for the use cases described in the proposal itself (e.g., inserting an empty collection if it isn’t already there, and appending a value to the collection).</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-March/000328.html">accepted</a>.</p>
<blockquote>
<p>The proposal is accepted with the following revisions:</p>
<ul>
<li>The root <code class="language-plaintext highlighter-rouge">Number</code> protocol should be renamed <code class="language-plaintext highlighter-rouge">Numeric</code>.</li>
<li>Instead of using single-case enums as mock trailing argument labels, the <code class="language-plaintext highlighter-rouge">FullWidth</code> and <code class="language-plaintext highlighter-rouge">ReportingOverflow</code> variants should include that information in their basename:</li>
</ul>
<p><code class="language-plaintext highlighter-rouge">multipliedFullWidth(by:)</code> <br />
<code class="language-plaintext highlighter-rouge">dividingFullWidth(_:)</code> <br />
<code class="language-plaintext highlighter-rouge">addingReportingOverflow(_:)</code> <br />
<code class="language-plaintext highlighter-rouge">subtractingReportingOverflow(_:)</code> <br />
<code class="language-plaintext highlighter-rouge">multipliedReportingOverflow(by:)</code> <br />
<code class="language-plaintext highlighter-rouge">dividedReportingOverflow(by:)</code> <br /></p>
<ul>
<li><code class="language-plaintext highlighter-rouge">popcount</code> should use the unabbreviated name <code class="language-plaintext highlighter-rouge">populationCount</code>.</li>
</ul>
<p>The core team also observed that the proposed endianness-handling interfaces deserve further thought. In almost every known little-, big-, or mixed-endian format, converting to and from another endian are symmetric operations (going to and from big endian are the same operation, as are going to and from little endian), so there is no need for both sets of operations to be independent protocol requirements. The core team accepts the proposal as is for now, since it’s a small corner of the larger proposal, but asks the authors for a follow-up proposal in this space.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md">SE-0156</a>: <em>Class and Subtype existentials</em> by David Hart and Austin Zheng is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000325.html">under review</a>.</p>
<blockquote>
<p>This proposal brings more expressive power to the type system by allowing Swift to represent existentials of classes and subtypes which conform to protocols.</p>
<p>Currently, the only existentials which can be represented in Swift are conformances to a set of protocols, using the & protocol composition syntax: <code class="language-plaintext highlighter-rouge">Protocol1 & Protocol2</code>.</p>
<p>On the other hand, Objective-C is capable of expressing existentials of classes and subclasses conforming to protocols with the following syntax: <code class="language-plaintext highlighter-rouge">id<Protocol1, Protocol2></code>, <code class="language-plaintext highlighter-rouge">Base<Protocol>*</code>.</p>
<p>We propose to provide similar expressive power to Swift, which will also improve the bridging of those types from Objective-C.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md">SE-0157</a>: <em>Support recursive constraints on associated types</em> by Douglas Gregor, Erica Sadun, and Austin Zheng is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000326.html">under review</a>.</p>
<blockquote>
<p>This proposal lifts restrictions on associated types in protocols. Their constraints will be allowed to reference any protocol, including protocols that depend on the enclosing one (recursive constraints).</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>There were a number of access control discussions this week, many rehashing ideas discussed during original review of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>, the proposal that introduced <code class="language-plaintext highlighter-rouge">fileprivate</code>. Nevin Brackett-Rozinsky <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/033112.html">started a thread</a>, <em>A Comprehensive Rethink of Access Levels in Swift</em>. It’s a thorough and thoughtful write up.</p>
<blockquote>
<p>There has been a deluge of discussion about access levels lately, all attempting to simplify the situation. Shortly after Swift 3 was released, many people realized that the new access modifier story was far more complex than the old one, and expressed the belief that the changes may have been a mistake.</p>
<p>In the months that followed, more and more people came to share the same view, and stage 2 of Swift 4 has seen a profusion of proposals addressing the issue. These proposals are generally small and focus on changing just one aspect of access control. However, given the situation we are in now, it is important to look at the problem in its entirety and arrive at a cohesive solution.</p>
<p>[…]</p>
<p>That belief, as well as the numerous arguments which led to it, were well-informed and thoughtfully considered. However, due to the inevitable linear nature of time, they were not based on first-hand experience with the new changes. Upon the release of Swift 3, we all gained that first-hand experience, and it quickly became apparent to many people that the new access control system was needlessly complicated, and not at all the improvement it had been heralded as.</p>
<p>[…]</p>
<p>It is important that we as the Swift community are able to recognize our mistakes, and even more important that we fix them. We originally thought that the Swift 3 access control changes would be beneficial. However, experience with them in practice has shown that not to be the case. Instead, the language became more complex, and that has real costs. It is time for a simplification.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/033112.html">Continue reading…</a></p>
</blockquote>
<p>Nevin’s final recommendations are to keep Swift 2’s original <code class="language-plaintext highlighter-rouge">private</code> (to file), <code class="language-plaintext highlighter-rouge">internal</code>, and <code class="language-plaintext highlighter-rouge">public</code> modifiers (removing <code class="language-plaintext highlighter-rouge">fileprivate</code>). Then, remove <code class="language-plaintext highlighter-rouge">open</code> and parameterize <code class="language-plaintext highlighter-rouge">final</code> to accommodate the semantics of <code class="language-plaintext highlighter-rouge">open</code>, for example <code class="language-plaintext highlighter-rouge">final(public)</code> or <code class="language-plaintext highlighter-rouge">final(internal)</code>.</p>
<p>I definitely agree with the first part, but not the second — and it’s probably safe to say that this is not going to happen given Swift 4’s constraints and higher standards for source-breaking changes. This goes for other similar suggestions on the mailing list too, things like <code class="language-plaintext highlighter-rouge">private(file)</code>, <code class="language-plaintext highlighter-rouge">private(module)</code>, etc. I can tell you now, this is not going to happen! Such changes are too drastic and too disruptive, and were previously discussed and rejected.</p>
<p>I think the simplest, most reasonable, and less intrusive path forward is to simply revert <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>. That would leave us with <code class="language-plaintext highlighter-rouge">private</code> (to file), <code class="language-plaintext highlighter-rouge">internal</code>, <code class="language-plaintext highlighter-rouge">public</code>, and <code class="language-plaintext highlighter-rouge">open</code>. With <code class="language-plaintext highlighter-rouge">internal</code> being the default, it never has to be written. And only library authors (typically more advanced users) would need to know and understand <code class="language-plaintext highlighter-rouge">open</code>. That leaves only 2 access modifiers (<code class="language-plaintext highlighter-rouge">private</code> and <code class="language-plaintext highlighter-rouge">public</code>) to worry about for the majority of developers. This kind of progressive disclosure (one of Swift’s strengths) is particularly important for beginners.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/835358654593290240">there’s always a party in San Jose</a>.</p>
Issue #58
https://swiftweeklybrief.com/issue-58
2017-02-23T00:00:00-08:00
2017-02-23T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>The biggest news over the past week (and likely disappointing for some) was that ABI stability has been deferred from Swift 4. In practice, ABI stability likely affects very few Swift users directly, and for those whom are affected it would be much worse to lockdown the ABI too soon rather than delay it further. In a sense, that leaves ABI stability as mostly a symbol of Swift’s maturity (or lack thereof). Aside from the obvious impacts of those affected by the lack of ABI stability, the major impact here is that iOS developers will continue to be required to bundle the Swift standard library with their apps. This is also a blocker for wider adoption of Swift within Apple (including eventually providing Swift-only APIs in the SDKs).</p>
<p>While inconvenient, this is not the end of the world. The Core Team is clearly dedicated to declaring ABI stability as soon as they reasonably can, and will continue working toward this goal during the remainder of the Swift 4 release cycle. Having said that, I think if there are delays for this beyond Swift 5, that’s when the community should begin to worry. In other news, a new manifesto on memory ownership landed this week and Slava fixed an 18-month-old radar! 😄</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://forwardswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_58" target="_blank">Forward Swift: March 2 in San Francisco + Free Online Workshop Access</a></h4>
<p>Attend a full day of cutting-edge iOS talks ranging from mirroring and introspection to watchOS. Your ticket includes free networking events with speakers/other devs, and 1 free month of online workshop access post event. Add an exclusive in-person workshops by Paul Hudson on beginning or advanced Swift, macOS, and server-side Swift while they last. Use code <strong>forward-swift-2017</strong>.</p>
<p><small><a href="https://forwardswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_58" target="_blank">forwardswift.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<p>In Ted Kremenek’s <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html">Swift 4, stage 2</a> announcement, he mentioned some starter proposals. There’s probably two dozen or so <a href="https://bugs.swift.org/browse/SR-3397?jql=labels%20%3D%20StarterProposal">JIRA tasks</a> that describe these potential proposals and they vary in complexity and difficulty. You should definitely have a look if you’re interested in writing a proposal. Checkout the list and see if there’s a task for a feature you’ve been wanting. Remember, proposals can have multiple authors — so don’t hesitate to collaborate with others.</p>
<blockquote>
<p>The Core Team has also identified some <a href="https://bugs.swift.org/browse/SR-3316?jql=labels%20%3D%20StarterProposal">starter proposals</a> that fit well with the goals of Swift 4. Taking one of those ideas and developing it into a complete proposal is a fantastic way to get involved in the Swift evolution process.</p>
</blockquote>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ted Kremenek wrote an official blog post on the <a href="https://swift.org/blog/swift-4-0-release-process/">Swift 4 Release Process</a>, describing the goals, release process, estimated schedule, and how source compatibility will work between Swift 3 and 4.</p>
<p>Károly Lőrentey (<a href="https://twitter.com/lorentey">@lorentey</a>) posted a <a href="https://twitter.com/lorentey/status/834458009069899778">series of tweets</a> on the performance of <code class="language-plaintext highlighter-rouge">Set</code> and <code class="language-plaintext highlighter-rouge">Array</code>.</p>
<blockquote>
<p>Fun Swift quiz: given a large <code class="language-plaintext highlighter-rouge">Array<Int></code> with random values, which of these two is faster?</p>
<ol>
<li><code class="language-plaintext highlighter-rouge">array.sorted()</code></li>
<li><code class="language-plaintext highlighter-rouge">Set<Int>(array)</code></li>
</ol>
</blockquote>
<p><a href="https://developer.apple.com/news/?id=02202017a">Xcode 8.3 beta 3</a> was released.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor (<a href="https://twitter.com/dgregor79">@dgregor79</a>) <a href="https://github.com/apple/swift/pull/7658">fixed</a> an issue in the constraint solver to now handle disjunctions as separate connected components. The pull request description is fantastic and worth a read. (See also: <a href="https://twitter.com/dgregor79/status/834116498712977408">tweet</a>.)</p>
<p>Graydon Hoare (<a href="https://github.com/graydon">@graydon</a>) unfortunately had <a href="https://github.com/apple/swift/pull/7676">to revert</a> enabling bridging PCH by default due to some concerns regarding source compatibility. This feature is now <em>opt-in</em> rather than <em>opt-out</em>. This was the subject of his <a href="https://swift.org/blog/bridging-pch/">blog post</a> last month, <em>Faster Mix-and-Match Builds with Precompiled Bridging Headers</em>. Unfortunately, disabling this feature means regressing build times for users who may not realize they will need to enable this manually.</p>
<p>Slava Pestov (<a href="https://twitter.com/slava_pestov/status/834287805480079364">@slava_pestov</a>) <a href="https://github.com/apple/swift/pull/7683">merged</a> preliminary Sema support for generic subscripts, building upon a number of previous pull requests. He notes that this also fixes an 18-month SourceKit radar. See — radars <em>do</em> get fixed in a timely manner! 😉</p>
<p>Michael Gottesman (<a href="https://github.com/gottesmm">@gottesmm</a>) <a href="https://github.com/apple/swift/pull/7714">merged</a> changes to completely refactor class constructor initialization for ownership, fixing a number issues with the previous implementation.</p>
<p>Hugh Bellamy (<a href="https://github.com/hughbe">@hughbe</a>) <a href="https://github.com/apple/swift/pull/7588">ported</a> swiftSyntax to Windows.</p>
<p><a href="https://github.com/ddunn2">@ddunn2</a> opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/892">pull request</a> with an initial implementation of <code class="language-plaintext highlighter-rouge">ByteCountFormatter</code>.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/7679">addressed</a> a couple of ABI FIXMEs by deleting code.</p>
<p>Doug Gregor (<a href="https://twitter.com/dgregor79">@dgregor79</a>) <a href="https://github.com/apple/swift-evolution/commit/891d5d4c54e7eab5271418b2b6c720402a56ebce">committed</a> notes on Swift’s stage 2 goals and priorities.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md">SE-0155</a>: <em>Normalize Enum Case Representation</em> by Daniel Duan and Joe Groff was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000323.html">reviewed</a> briefly and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032980.html">returned for revision</a> early.</p>
<p>From the proposal:</p>
<blockquote>
<p>In Swift 3, associated values for an enum case are represented by a labeled-tuple. This has several undesired effects: inconsistency in enum value construction syntax, many forms of pattern matching, missing features such as specifying default value and missed opportunity for layout improvements.</p>
<p>This proposal aims to make enums more “regular” by replacing tuple as the representation of associated values, making declaration and construction of enum cases more function-like.</p>
</blockquote>
<p>John McCall:</p>
<blockquote>
<p>The core team met and talked about SE-0155 today, even though we’re not quite done with the review period, and here’s where we stand.</p>
<p>SE-0155 is being returned for revision. Consensus appears to be strongly in favor of requiring argument labels (if provided) to be enforced on “call” sites. However, the core team feels that the proposal needs revision in the following ways:</p>
<ul>
<li>Are internal argument names syntactically allowed in a case declaration?</li>
<li>Can cases with the same base name be overloaded by argument label? If so, is a pattern match using just the bare name ambiguous or does it match both cases?</li>
<li>Can cases with the same name (using the same rule as above) be overloaded by argument type? If so, how are they disambiguated in pattern matches?</li>
<li>Do pattern matches require argument labels to be given along with value patterns, e.g. “case .valid(value: let value)”, or is there some way to shorten this? If the latter, what are the rules for that?</li>
<li>Are you proposing anonymous cases, and if so, what are the language rules for them?</li>
<li>The proposal makes a claim about layout efficiency; please either discuss this claim or remove it.</li>
</ul>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md">SE-0153</a>: <em>Compensate for the inconsistency of <code class="language-plaintext highlighter-rouge">@NSCopying</code>’s behaviour</em> by Torin Kwok is <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0153-compensate-for-the-inconsistency-of-nscopyings-behaviour.md">under review</a>.</p>
<blockquote>
<p>First of all, in Swift, the Objective-C <code class="language-plaintext highlighter-rouge">copy</code> property attribute translates to <code class="language-plaintext highlighter-rouge">@NSCopying</code>.</p>
<p>Like Objective-C, in Swift, avoiding accessing ivar via setter methods in initializer is considered as the best pratice. Unlike Objective-C, which gives developers the freedom to decide on whether assign a value to a property by invoking setter or by accessing ivar directly, accessing a property in Swift from within an initializer always does direct access to the storage rather than going through the setter, even if using <code class="language-plaintext highlighter-rouge">dot</code> syntax.</p>
<p>However, as a side-effect, <code class="language-plaintext highlighter-rouge">@NSCopying</code> attribute does not work as consistently as we usually expected in Swift initializers after developers declared a property as <code class="language-plaintext highlighter-rouge">@NSCopying</code>.</p>
<p>[…]</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0154-dictionary-key-and-value-collections.md">SE-0154</a>: <em>Provide Custom Collections for Dictionary Keys and Values</em> by Nate Cook is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000321.html">under review</a>.</p>
<blockquote>
<p>This proposal addresses significant unexpected performance gaps when using dictionaries. It introduces type-specific collections for a <code class="language-plaintext highlighter-rouge">Dictionary</code> instance’s <code class="language-plaintext highlighter-rouge">keys</code> and <code class="language-plaintext highlighter-rouge">values</code> properties.</p>
<p>New collection types provide efficient key lookup and mutable access to dictionary values, allowing in-place updates and copy-on-write optimization of stored values. The addition of these new types impacts the standard library ABI, since we won’t be able to use types aliases from the existing types for <code class="language-plaintext highlighter-rouge">keys</code> and <code class="language-plaintext highlighter-rouge">values</code>.
[…]</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000322.html">under review</a> for the third (and final? 😅) time. This proposal was accepted for Swift 3, but was not implemented in time.</p>
<blockquote>
<p>This proposal cleans up Swifts integer APIs and makes them more useful for generic programming.</p>
<p>The language has evolved in ways that affect integers APIs since the time the original proposal was approved for Swift 3. We also attempted to implement the proposed model in the standard library and found that some essential APIs were missing, whereas others could be safely removed.</p>
<p>Swift’s integer protocols don’t currently provide a suitable basis for generic programming. See <a href="http://blog.krzyzanowskim.com/2015/03/01/swift_madness_of_generic_integer/">this blog post</a> for an example of an attempt to implement a generic algorithm over integers.</p>
<p>[…]</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ted Kremenek announced <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html">Swift 4, stage 2</a>:</p>
<blockquote>
<p>Back in July, we laid out a plan for Swift 4 which divided the release into two stages. Since then, we’ve been in Swift 4 stage 1 […]</p>
<p>Since July, we now have a much better understanding now of how to achieve ABI stability, with an <a href="https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md">ABI Manifesto</a> detailing the list of all language/implementation work that is needed to achieve ABI stability. We have made substantial progress in that work during stage 1, but much remains to be done. Once Swift achieves ABI stability the ABI can be extended, but not changed. Thus the cost of locking down an ABI too early is quite high.</p>
<p><strong>Deferring ABI Stability from Swift 4</strong><br />
Given the importance of getting the core ABI and the related fundamentals correct, we are going to defer the declaration of ABI stability out of Swift 4 while still focusing the majority of effort to get to the point where the ABI can be declared stable.</p>
<p>To allow the community to follow along with this effort, an ABI dashboard will get wired up from the <a href="https://github.com/apple/swift-evolution">swift-evolution</a> home page that will present a table of main ABI tasks remaining and what Swift release they landed in. This dashboard will largely track open tasks in JIRA. I expect the dashboard to be up next week, and I’ll send a follow up email when it is available.</p>
<p><strong>Stage 2</strong><br />
With ABI stability well-understood and many of the stage 1 goals underway, it is time to open up Swift 4 stage 2 to expand the scope of proposals to be considered.</p>
<p><strong>Timeline</strong><br />
Stage 2 starts right now. All design work and discussion for stage 2 extends to April 1, 2017. The intent is to timebox discussion to provide adequate time for the actual implementation of accepted proposals.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032116.html">Continue reading…</a></p>
</blockquote>
<p>Ben Cohen <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032120.html">started a discussion</a> on <code class="language-plaintext highlighter-rouge">Sequence</code> and <code class="language-plaintext highlighter-rouge">Collection</code> enhancements for “stage 2” of Swift 4 development:</p>
<blockquote>
<p>Following up on Ted’s post regarding the opening up of stage 2, I’m starting a thread to discuss additive algorithms for Sequence and Collection. Here is a list of commonly requested algorithms to operate on Sequence or Collection: […]</p>
<p>Please reply here with any comments or questions on the above list, or any additions you believe are important that are missing from it.
As this focus area is larger in scope than <code class="language-plaintext highlighter-rouge">Dictionary</code>, it is likely that it will need to be broken up into multiple separate proposals. The plan is to get an initial high-level signal from this thread on which areas to put focus on. We are also looking for volunteers to put together proposals and implementations — if you’re interested in helping with that, please email me off-list. High quality community implementations will significantly improve the chances of a feature making it into Swift 4. Smaller, more focused proposals are also more likely to make it than larger ones.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032120.html">Continue reading…</a></p>
</blockquote>
<p>John McCall <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032155.html">started a thread</a> to introduce a new <a href="https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md">Ownership Manifesto</a>:</p>
<blockquote>
<p>Memory ownership is a topic that keeps poking its head up here. Core team members have mentioned several times that it’s something we’re interested in working on. Questions sometimes get referred back to it, saying stuff like “we’re working on tools to let you control ARC a little better”. It’s even on the short list of high-priority features for Swift 4 […]</p>
</blockquote>
<p>From the <a href="https://github.com/apple/swift/blob/master/docs/OwnershipManifesto.md">manifesto</a> introduction:</p>
<blockquote>
<p>Adding “ownership” to Swift is a major feature with many benefits for programmers. This document is both a “manifesto” and a “meta-proposal” for ownership: it lays out the basic goals of the work, describes a general approach for achieving those goals, and proposes a number of specific changes and features, each of which will need to be separately discussed in a smaller and more targeted proposal. This document is intended to provide a framework for understanding the contributions of each of those changes.</p>
</blockquote>
<p>It’s a lengthy read, but very interesting. If long form reading isn’t your thing, Alexis Beingessner was kind enough to write up some <a href="https://gist.github.com/Gankro/1f79fbf2a9776302a9d4c8c0097cc40e">TL;DR notes</a> on the manifesto.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/b3ll/status/834552936982196224">using computers The Australian Way</a>™. <code class="language-plaintext highlighter-rouge">¯\_(ツ)_/¯</code></p>
Issue #57
https://swiftweeklybrief.com/issue-57
2017-02-16T00:00:00-08:00
2017-02-16T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week changes to branch management for the <a href="https://github.com/apple/swift-lldb">swift-LLDB</a> repository were announced, as well as a new Swift Syntax and Structured Editing library! This library aims to expand on the functionality provided by SourceKit and sounds like it could enable tons of great new tooling for Swift. Apple also announced WWDC 2017.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://forwardswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_57" target="_blank">Forward Swift: March 2 in San Francisco + Free Online Workshop Access</a></h4>
<p>Attend a full day of cutting-edge iOS talks ranging from mirroring and introspection to watchOS. Your ticket includes free networking events with speakers/other devs, and 1 free month of online workshop access post event. Add an exclusive in-person workshops by Paul Hudson on beginning or advanced Swift, macOS, and server-side Swift while they last. Use code <strong>forward-swift-2017</strong>.</p>
<p><small><a href="https://forwardswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_57" target="_blank">forwardswift.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3936">SR-3936</a>: Provide a Fix It for errors such as “Computed property must have an explicit type”</li>
<li><a href="https://bugs.swift.org/browse/SR-3882">SR-3882</a>: <code class="language-plaintext highlighter-rouge">@objc</code> protocol conformance info isn’t recorded when a type conforms to a Swift sub-protocol</li>
<li><a href="https://bugs.swift.org/browse/SR-3867">SR-3867</a>: Improve diagnostics for labeled block without <code class="language-plaintext highlighter-rouge">do</code></li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>The engineering team at Airbnb shared their story on <a href="https://medium.com/airbnb-engineering/getting-to-swift-3-at-airbnb-79a257d2b656#.453vg69qn">migrating to Swift 3</a>. The post covers their approach to the migration, the impact of Swift 3 on binary size and build time (both regressed, unfortunately), and some issues to watch out for. It’s an interesting read and definitely highlights the risks and pain points that early adopters experienced. But hopefully that’s over now. 😅</p>
<p>Ole Begemann wrote an article on <a href="https://oleb.net/blog/2017/02/sorted-array/">implementing a sorted array</a> in Swift, a follow-up to objc.io’s <a href="https://talk.objc.io/episodes/S01E35-sorted-arrays-collections-3">Swift Talk #35</a>. His post and the objc.io video provide a great in-depth look at how to write your own, efficient collections in Swift.</p>
<p>Apple announced <a href="https://developer.apple.com/wwdc/">WWDC 2017</a>, which will be held June 5-9 in San Jose, CA.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>David Farler (<a href="https://github.com/bitjammer">@bitjammer</a>) <a href="https://github.com/apple/swift/pull/7393">started</a> the syntax structure editing library. (See below for more details.)</p>
<p>John Szumski (<a href="https://github.com/jszumski">@jszumski</a>) opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/883">pull request</a> with an initial implementation of <code class="language-plaintext highlighter-rouge">MassFormatter</code> in corelibs-foundation.</p>
<p>Younes Manton (<a href="https://github.com/ymanton">@ymanton</a>) <a href="https://github.com/apple/swift/pull/7339">improved</a> string comparison performance on Linux.</p>
<p>Ankit Aggarwal (<a href="https://github.com/aciidb0mb3r">@aciidb0mb3r</a>) <a href="https://github.com/apple/swift-package-manager/pull/954">implemented</a> tools version support in SPM. (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md">SE-0152</a>)</p>
<p>Philippe Hausler (<a href="https://github.com/phausler">@phausler</a>) <a href="https://github.com/apple/swift/pull/7433">added</a> additional conformances and functionality to <code class="language-plaintext highlighter-rouge">NSRange</code>.</p>
<p>Olivier Tardieu (<a href="https://github.com/tardieu">@tardieu</a>) <a href="https://github.com/apple/swift/pull/7479">added</a> an unsafe String API discussion to String manifesto.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md">SE-0151</a>: <em>Package Manager Swift Language Compatibility Version</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000318.html">accepted</a> for Swift 4.</p>
<blockquote>
<p>There wasn’t much discussion on the mailing list, but we did receive some off-list feedback that was supportive. The proposal is accepted for Swift 4.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md">SE-0152</a>: <em>Package Manager Tools Version</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000319.html">accepted</a> for Swift 4.</p>
<blockquote>
<p>There wasn’t much discussion on the mailing list, but we did receive some off-list feedback that was supportive. The proposal is accepted for Swift 4.</p>
</blockquote>
<p>Both proposals have already been <a href="https://github.com/apple/swift-evolution/pull/605">implemented</a> as well. 😄🎉</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>David Farler <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170206/004066.html">sent an email</a> announcing work on the <em>Swift Syntax and Structured Editing</em> library:</p>
<blockquote>
<p>A truly modern compiler has to have excellent IDE and tools integration, as we have done through the SourceKit layer, providing code completion, documentation comments, syntax highlighting, and more. There’s no reason to stop there, so I’d like to announce work on the Swift Syntax and Structured Editing library, which will be growing in lib/Syntax in the coming weeks. The overall goal of the library is to provide a representation and a body of APIs for structured editing on Swift syntax.</p>
<p>The immediate goals of the library are to provide infrastructure for the Swift Migrator and for a first-class formatting tool, which we’ll be bringing to the open source tree and developing publicly.</p>
<p><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170206/004066.html">Continue reading…</a></p>
</blockquote>
<p>Chris Bieneman <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170206/004048.html">announced changes</a> to LLDB branch management:</p>
<blockquote>
<p>Over the last couple weeks we’ve been working on some changes to the branch management strategy for the Swift-LLDB repository. The goal is to have LLDB more closely align with the other projects forked from <a href="http://llvm.org/">LLVM.org</a>. We believe that making this change will simplify the contribution process for LLDB’s Swift support.</p>
<p>To this end, we are making the following changes:</p>
<p>LLDB has gained an <code class="language-plaintext highlighter-rouge">upstream-with-trunk</code> branch which will be auto-merged from LLVM.org’s <code class="language-plaintext highlighter-rouge">LLDB/trunk</code>. This branch will contain the best of both worlds. The latest and greatest from LLVM.org, and Swift support. This branch will pair to LLVM & Clang’s <code class="language-plaintext highlighter-rouge">upstream-with-swift</code> branches and Swift’s <code class="language-plaintext highlighter-rouge">master-next</code>.</p>
<p>LLDB has also gained a stable branch which will behave the same way as the LLVM & Clang stable branches, and should be used for most Swift compiler development. Additionally we have made the <code class="language-plaintext highlighter-rouge">swift-lldb/stable</code> branch the default branch on the GitHub repository, which matches the behavior of LLVM & Clang.</p>
<p><a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170206/004048.html">Continue reading…</a></p>
</blockquote>
<p>David Hart started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031833.html">a discussion</a> on the merit (or lack thereof) of the <code class="language-plaintext highlighter-rouge">final</code>, <code class="language-plaintext highlighter-rouge">lazy</code>, and <code class="language-plaintext highlighter-rouge">fileprivate</code> keywords. He argues that <code class="language-plaintext highlighter-rouge">final</code> has diminished value given <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md">SE-0117</a>, that <code class="language-plaintext highlighter-rouge">lazy</code> will eventually be obsoleted by Joe Groff’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">property behaviors proposal</a>, and that <code class="language-plaintext highlighter-rouge">fileprivate</code> should be reverted (which has been discussed on the lists before). Matthew Johnson <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031835.html">pointed out</a> that <code class="language-plaintext highlighter-rouge">final</code> still brings a lot of value, and Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031842.html">noted</a> that property behaviors won’t be implemented until <em>at least</em> Swift 5. The merit and utility of <code class="language-plaintext highlighter-rouge">fileprivate</code> is still in question, and the rest of the thread debates this. I would personally love to see <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a> reverted. In my experience <code class="language-plaintext highlighter-rouge">fileprivate</code> has become a burden rather than solving any tangible problems.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/831953187623952384">overflow and underflow</a>. 😄</p>
Issue #56
https://swiftweeklybrief.com/issue-56
2017-02-09T00:00:00-08:00
2017-02-09T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week there were updates from the Swift Server APIs work group, new SPM proposals, great community articles about protocols and standard library collections, and an announcement that swift-evolution (and swift-users) will be moving to <a href="http://www.discourse.org">Discourse</a>. Given the volume on these particular lists, and the need to easily search, reference, and rehash previous discussions, I think this will benefit the community. It looks like the initial setup and migration may require substantial effort, but the Core Team is seeking help from the community. Read on to learn more!</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="https://forwardswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_56" target="_blank">Forward Swift: March 2 in San Francisco + Free Online Workshop Access</a></h4>
<p>Attend a full day of cutting-edge iOS talks ranging from mirroring and introspection to watchOS. Your ticket includes free networking events with speakers/other devs, and 1 free month of online workshop access post event. Add an exclusive in-person workshops by Paul Hudson on beginning or advanced Swift, macOS, and server-side Swift while they last. Use code <strong>forward-swift-2017</strong>.</p>
<p><small><a href="https://forwardswift.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_56" target="_blank">forwardswift.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3836">SR-3836</a>: The <code class="language-plaintext highlighter-rouge">SubSequence</code> of a <code class="language-plaintext highlighter-rouge">Range</code> should be a <code class="language-plaintext highlighter-rouge">Range</code></li>
<li><a href="https://bugs.swift.org/browse/SR-1421">SR-1421</a>: <code class="language-plaintext highlighter-rouge">sourcekitd-test -help</code> should print help, list available request types</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Chris Eidhof wrote a great post, <a href="http://chris.eidhof.nl/post/classes-and-protocols/">Classes That Conform To Protocols</a>, that explains how to use type-erasers as a workaround until <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials">generalized existentials</a> arrive in Swift.</p>
<p>Orta Therox wrote a <a href="http://artsy.github.io/blog/2017/02/05/Retrospective-Swift-at-Artsy/">retrospective on using Swift at Artsy</a>. It’s an incredibly interesting post that actually ends up being more about the pros and cons of adopting <a href="https://facebook.github.io/react-native/">React Native</a> instead of converting to Swift. Most importantly, he highlights some major, systemic issues with Apple’s developer tools and ecosystem — in particular the lack of openness (Radar) and lack of extensibility (Xcode).</p>
<p>The Swift Server APIs work group held their second security stream meeting, and <a href="https://github.com/swift-server/work-group/pull/72">posted the meeting minutes</a>.</p>
<p>Daniel Duan wrote a step-by-step guide on how to <a href="http://dduan.net/2017/02/07/replying-to-old-mailing-list-threads/">reply retroactively to an old mailing list thread</a> on swift-evolution. Definitely not very user friendly or efficient. This is the kind of cumbersome experience that the Core Team hopes to mitigate by moving to Discourse.</p>
<p>Ole Begemann wrote a great article, <a href="https://oleb.net/blog/2017/02/why-is-dictionary-not-a-mutablecollection/">Being a Mutable Collection is not Sufficient to be a <code class="language-plaintext highlighter-rouge">MutableCollection</code></a>, where he dives into the standard library collection protocols and answers why <code class="language-plaintext highlighter-rouge">Dictionary</code> is (perhaps unintuitively) <em>not</em> a <code class="language-plaintext highlighter-rouge">MutableCollection</code>, among other things.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Dave Abrahams (<a href="https://github.com/dabrahams">@dabrahams</a>) opened an initial <a href="https://github.com/apple/swift/pull/6752">pull request</a> to rethink the existing Unicode implementation. This work is part of the <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md">String Manifesto</a>.</p>
<p>Erik Eckstein (<a href="https://github.com/eeckstein">@eeckstein</a>) <a href="https://github.com/apple/swift/pull/7274">made changes</a> to link a new re-mangler and de-mangler into the swift runtime library.</p>
<p>Jacob Bandes-Storch (<a href="https://github.com/jtbandes">@jtbandes</a>) <a href="https://github.com/apple/swift/pull/7331">fixed</a> a crash in conditional compilation parsing and fixed an invalid but allowed use of <code class="language-plaintext highlighter-rouge">#if</code> / <code class="language-plaintext highlighter-rouge">#endif</code>, which was <em>technically</em> a breaking change. (:trollface:) However, Doug Gregor <a href="https://github.com/apple/swift/pull/7331#issuecomment-278551656">pointed out</a> that the likelihood of this affecting real-world code was small and the code is obviously invalid. So, the old (incorrect) behavior will <em>not</em> be preserved in Swift 3 mode of the compiler.</p>
<p>Slava Pestov (<a href="https://github.com/slavapestov">@slavapestov</a>) <a href="https://github.com/apple/swift/pull/7296">fixed</a> an issue (<a href="https://bugs.swift.org/browse/SR-3840">SR-3840</a>) where a closure that reads and writes to a computed parameter picks up the static type and not the dynamic type.</p>
<p>Arnold Schwaighofer (<a href="https://github.com/aschwaighofer">@aschwaighofer</a>) open a <a href="https://github.com/apple/swift/pull/7237">pull request</a> to switch over to using the Swift calling convention for Swift functions.</p>
<p>There’s a <a href="https://github.com/swift-server/security">new repo</a> under the <a href="https://github.com/swift-server">swift-server</a> GitHub organization for the development of cross-platform Security APIs. It’s currently empty except for a README, which has all of the details. It discusses the scope of the project, which SSL implementation to use, and trade-offs.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md">SE-0149</a>: <em>Package Manager Support for Top of Tree development</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000314.html">accepted</a>.</p>
<blockquote>
<p>The review of SE-0149 “Package Manager Support for Top of Tree development” ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to everyone who participated!</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md">SE-0150</a>: <em>Package Manager Support for branches</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000315.html">accepted</a>.</p>
<blockquote>
<p>The review of SE-0150 “Package Manager Support for branches” ran from January 24…31. Feedback was positive, and the proposal is accepted for Swift 4. Thanks to everyone who participated!</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0151-package-manager-swift-language-compatibility-version.md">SE-0151</a>: <em>Package Manager Swift Language Compatibility Version</em> by Daniel Dunbar and Rick Ballard is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000316.html">under review</a>.</p>
<blockquote>
<p>This proposal adds support for the Swift compiler’s new “language compatibility version” feature to the package manager.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0152-package-manager-tools-version.md">SE-0152</a>: <em>Package Manager Tools Version</em> by Rick Ballard is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-February/000317.html">under review</a>.</p>
<blockquote>
<p>This proposal introduces a “Swift tools version” which is declared for each Swift package. The tools version declares the minimum version of the Swift tools required to use the package, determines what version of the <code class="language-plaintext highlighter-rouge">PackageDescription</code> API should be used in the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest, and determines which Swift language compatibility version should be used to parse the <code class="language-plaintext highlighter-rouge">Package.swift</code> manifest.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Continuing the meta-discussions from last week about moving away from the mailing lists to <a href="http://www.discourse.org">Discourse</a>, Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031657.html">sent an email</a> regarding the decision from the Core Team:</p>
<blockquote>
<p>There was a long thread on swift-evolution about whether we should use modern forum software — like Discourse — as an alternative to the mailing lists we have now. After a long discussion, the Core Team has decided to move swift-evolution and swift-users to Discourse.</p>
<p>There are tradeoffs to moving to a forum. The main advantages are:</p>
<ul>
<li>Easy for people to participate without subscribing to the entire mailing list, as well as no need to provide email address to participate. A lot of people have voiced concern that they feel resistance to participate because of needing to subscribe to a mailing list.</li>
<li>Consistent affordances and rendering of content, including Markdown support. This is really useful for having technical discussions.</li>
<li>Better searching of topics, archiving, etc.</li>
<li>More tools for moderation.</li>
<li>Topic cross-referencing, and consistent organization of topics instead of whatever threading support a mail client provides (which is inconsistent).</li>
</ul>
<p>I also want to consider moving the -dev lists to the same forum setup as well; but that will be a separate conversation on those lists.</p>
<p>A rollout plan has not been figured out. People are busy and there are logistics to figure out. I will be engaging a handful of members from the community to help with the transition. Specifically, there are those who really value using email for participation on swift-evolution and swift-users, and the goal is to get the forum setup to allow those people to continue to feel effective when using email for discussions on these “lists”.</p>
<p>More details will be announced as they get figured out, but I felt it was important to let the community know about this direction.</p>
</blockquote>
<p>David Hart <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031514.html">shared</a> a second <a href="https://github.com/hartbit/swift-evolution/blob/e6411d8a9e7924bbd8a48fc292bf08d58a8d1199/proposals/XXXX-subclass-existentials.md">draft</a> proposal on class and subtype existentials.</p>
<blockquote>
<p>I rewrote the draft proposal concerning the class and subclass existentials. Please let me know what you think, especially concerning the <code class="language-plaintext highlighter-rouge">class</code> and <code class="language-plaintext highlighter-rouge">AnyObject</code> conundrum.</p>
</blockquote>
<p>There’s an on-going discussion about <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031466.html">compile-time generic specialization</a>, originally started by Abe Schneider:</p>
<blockquote>
<p>The current behavior of generics in Swift causes it lose type information at compile time due to the desire of maintaining a single version of the function. This runs counter to how c++ works, which creates a new copy of a function per type, but preserves information to be preserved. This can cause unexpected behavior from the user’s perspective…</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031466.html">Continue reading…</a></p>
</blockquote>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031500.html">shared some insights</a> into Swift’s design and how it works:</p>
<blockquote>
<p>You can’t figure out the correct function to dispatch entirely at compile time because Swift supports retroactive modeling. Let’s make this a super-simple example…</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170206/031500.html">Continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/steipete/status/829044564220604417">unsigned math is evil</a>. (<a href="https://gist.github.com/steipete/06d101d41c93763f7d5e394dea3c56fe">gist</a>) If only there were a language and compiler that could mitigate these kinds of issues… 😉</p>
Issue #55
https://swiftweeklybrief.com/issue-55
2017-02-02T00:00:00-08:00
2017-02-02T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome! This week we saw how compile-time cost is being addressed in Swift 3.1. The swift-evolution community discussed ABI stability, and there was also a meta-discussion on possibly moving away from mailing lists to a forum-based solution.</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3782">SR-3782</a>: UnsafeMutable[Raw]BufferPointer should have non-mutating subscript setters</li>
<li><a href="https://bugs.swift.org/browse/SR-3665">SR-3665</a>: Global functions called with an explicit namespace do not respect <code class="language-plaintext highlighter-rouge">@discardableResult</code></li>
<li><a href="https://bugs.swift.org/browse/SR-3773">SR-3773</a>: Class definition not included when running <code class="language-plaintext highlighter-rouge">-emit-sil</code></li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Graydon Hoare (<a href="https://github.com/graydon/">@graydon</a>) (<a href="https://en.wikipedia.org/wiki/Rust_(programming_language)">Rust</a> creator) wrote a post on <a href="https://swift.org/blog/bridging-pch/">Faster Mix-and-Match Builds with Precompiled Bridging Headers</a> for the official Swift blog. The article discusses the compile-time cost of projects that mix Objective-C and Swift and how it is being addressed in Swift 3.1. One interesting thing to note is that the team is explicitly <a href="https://swift.org/blog/bridging-pch/#reporting-feedback">soliciting feedback on Twitter</a> via <code class="language-plaintext highlighter-rouge">#SwiftBridgingPCH</code>.</p>
<p>Paul Hudson wrote about <a href="https://www.hackingwithswift.com/swift3-1">What’s new in Swift 3.1</a>. It’s a great overview with examples.</p>
<p>From <a href="https://twitter.com/jckarter/status/825012717580726272">Joe Groff</a>:</p>
<blockquote>
<p>If your Swift code compiles in Xcode 8.2 but not in the 8.3 betas, that’s our fault, not yours. Please let us know by filing bugs!</p>
</blockquote>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Colin Howell (<a href="https://github.com/colinhowell">@colinhowell</a>) <a href="https://github.com/apple/swift/pull/7004/commits/e4ae3f03642e1c93c81b10a49e7f6b1e76333774">fixed</a> a source of exponential behavior with dictionary literals.</p>
<p>Michael Gottesman (<a href="https://github.com/gottesmm">@gottesmm</a>) add <a href="https://github.com/apple/swift/pull/7076">a new tool</a> called SILLLVMGen that performs IRGen on a sil or sib file without adding any additional complexity.</p>
<p>Doug Gregor (<a href="https://github.com/DougGregor">@DougGregor</a>) <a href="https://github.com/apple/swift/pull/7144">merged</a> improvements to the type checker regarding how constraints are generated for interpolated string literals.</p>
<p>Jordan Rose (<a href="https://github.com/jrose-apple">@jrose-apple</a>) <a href="https://github.com/apple/swift/pull/7169">fixed a crash</a> when calling a generic initializer with default arguments.</p>
<p>Slava Pestov (<a href="https://github.com/slavapestov">@slavapestov</a>) <a href="https://github.com/apple/swift/pull/7095">fixed</a> a batch of compiler crashers. <em>“A fixed crasher a day keeps @practicalswift at bay… or something.”</em></p>
<p>Graydon Hoare (<a href="https://github.com/graydon">@graydon</a>) opened a <a href="https://github.com/apple/swift/pull/7088">pull request</a> to fix an issue in the constraint solver where it was inaccurately measuring its memory usage threshold.</p>
<p>Dave Abrahams (<a href="https://github.com/dabrahams">@dabrahams</a>) <a href="https://github.com/apple/swift/pull/7183">fixed</a> a data race in <code class="language-plaintext highlighter-rouge">StringBuffer.append</code>.</p>
<p><a href="https://github.com/saiHemak">@saiHemak</a> <a href="https://github.com/apple/swift-corelibs-foundation/pull/860">implemented</a> <code class="language-plaintext highlighter-rouge">homeDirectoryForCurrentUser</code> and <code class="language-plaintext highlighter-rouge">homeDirectory(forUser:)</code> on <code class="language-plaintext highlighter-rouge">FileManager</code> in corelibs-foundation.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md">SE-0148</a>: <em>Generic Subscripts</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000311.html">accepted</a> for Swift 4.</p>
<blockquote>
<p>The review of SE-0148 “Generic Subscripts” ran from January 19…24, 2017. Feedback was 100% positive, and the proposal is accepted for Swift 4, along with the amendment to support default arguments for subscript parameters. Thanks to everyone who participated!</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ben Cohen (<a href="https://twitter.com/AirspeedSwift">@AirspeedSwift</a>) <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031235.html">wrote about</a> where the standard library should draw the line in providing convenience functions that can easily be composed from other functions in the standard library.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0100-add-sequence-based-init-and-merge-to-dictionary.md">SE-100</a> is a proposal to add an <code class="language-plaintext highlighter-rouge">init</code> to <code class="language-plaintext highlighter-rouge">Dictionary</code> from a sequence of key/value pairs. It’s a commonly requested feature, and IMO much needed and should be added as soon as we move to the appropriate phase in Swift’s evolution.</p>
<p>Another commonly requested <code class="language-plaintext highlighter-rouge">Dictionary</code> feature is similar: add a <code class="language-plaintext highlighter-rouge">Dictionary.init</code> that takes a sequence, and a closure that maps that sequence to keys. This is useful, for example, when you have a sequence of objects that you frequently need to index into via one property on those objects, so you want to build a fast lookup cache using that property.</p>
<p>Now, if we implement SE-100, that second request can be easily composed. It would be something like <code class="language-plaintext highlighter-rouge">Dictionary(sequence.lazy.map { (key: $0.someProperty, value: $0) } )</code></p>
<p>Some people look at that line of code and think sure, that’s what I’d do and it’s easy enough that the second helper shouldn’t be added as it’s superfluous. Others look at it and say that it is unreadable clever-code FP nonsense, and we should just add the helper method because most programmers wouldn’t be able to read or write that easily.</p>
<p>As we expand (and maybe contract :) the standard library, this kind of question comes up a lot, so it is worth setting out some criteria for judging these “helper” methods. Here’s my take on such a list (warning: objectivity and subjectivity blended together in the below).</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031235.html">Continue reading…</a></p>
</blockquote>
<p>David Hart <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030718.html">started a thread</a> on postponing ABI stability:</p>
<blockquote>
<p>ABI stability is an important feature which many Swift users are looking forward to. If I understand it correctly, once it’s here, the Standard Library becomes part of that ABI and only additive and backwards-compatible changes can be done. Seeing how we are still heavily modifying the Standard Library this year (Strings), wouldn’t it be wiser to let those changes simmer under the scrutiny of the broader community of Swift users for a year before we make it into the ABI?</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030971.html">From Dave Abrahams</a>:</p>
<blockquote>
<p>I have had exactly the same worry for quite some time. We’re still waiting for many basic components of the generics system, and, if our experience with protocol extensions is any guide, before we have those features in hand, it will be impossible to anticipate the design changes we’d want to make to the standard library… and that cuts against the grain of <em>source</em> (to say nothing of ABI) stability.</p>
<p>So far I’ve been unable to form a mental model for what source and/or ABI stability actually means for our ability to make changes to the standard library in the future. It’s possible that we discover a workable path forward, but it’s equally possible that we find ourselves painted into a corner.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030989.html">From Ted Kremenek</a>:</p>
<blockquote>
<p>I fully agree that locking down the ABI prematurely would be detrimental to the long-term future of the language.</p>
<p>Part of the point of the ABI manifesto is to scope out what are the desirable or critical changes needed before ABI gets locked down. From that we can have concrete discussions on what’s left to be done, how much work it will take to get there, etc.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/031037.html">From Chris Lattner</a>:</p>
<blockquote>
<p>[…] In short, in the Swift 4 / iOS “N” timeframe, the only benefit of ABI stability would be that apps don’t need to include the standard library if they deploy to iOS “N or later”. Independent of whether ABI stability is achievable, I think it is important to do things like merge the dylibs together, since backward deployment will continue to be important for many apps.</p>
</blockquote>
<p>Joshua Alvarado has <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030646.html">re-opened the discussion</a> on moving swift-evolution away from email toward a forum-based solution.</p>
<blockquote>
<p>It is hard to know what has already been discussed and who is even in the active conversation. Keeping track of history is a pain as well. Searching through many emails to find who said what and when is not effective in email clients. Also, code formatting in emails is not effective. Let’s discuss and actually make an action to move away from email if the community so agrees.</p>
</blockquote>
<p>Ole Begemann <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030687.html">highlighted</a> some common pain points with the current solution: a lack of permalinks to view messages on the web archive, the poor usability of the web archive, and readability due to people using different formatting. Austin Zheng <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030942.html">pointed out</a> potential issues with logistics, maintenance, and administrative costs. Finally, Nate Cook <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030933.html">took the time</a> to setup a trial account with Discourse to see how importing the existing archives would work!</p>
<p>Project Lead, Ted Kremenek, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030862.html">was open to the idea</a>:</p>
<blockquote>
<p>I have no problem with the project moving to forums instead of the Mailman mailing lists we have now — if it is the right set of tradeoffs.</p>
<p>My preference is to approach the topic objectively, working from goals and seeing how the mailing lists are aligning with those goals and how an alternative, such as Discourse, might do a better job.</p>
<p>The current use of mailing lists has been carry-over of how both LLVM does public discussion (which is all mailing lists) and how the Swift team at Apple has used mailing lists for discussion. That inertia has benefits in that it is a familiar workflow that is “proven” to work — but that doesn’t mean it is the best option going forward.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030862.html">Continue reading…</a></p>
</blockquote>
<p>The community was mostly positive about moving away from email for swift-evolution and swift-users (other mailing lists would remain) and agreed that if moving to a forum that <a href="http://www.discourse.org">Discourse</a> would likely be the best option.</p>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170130/031327.html">asked for help</a> on gathering data for a proposal to fix how <code class="language-plaintext highlighter-rouge">NSUInteger</code> is treated in Swift.</p>
<blockquote>
<p>Hey, swift-evolution. I want to draw attention to one of the oddest parts of the Objective-C importer today: <code class="language-plaintext highlighter-rouge">NSUInteger</code>. TLDR: <code class="language-plaintext highlighter-rouge">NSUInteger</code> is treated differently based on whether it comes from a system framework or a user-provided header file. I think this is silly and that we should treat it consistently everywhere, but I haven’t had time to go collect data to demonstrate that this is a safe change. Would someone like to take that on? […]</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ericasadun/status/824755257762840579">Forget about unwrapping optionals.</a></p>
Issue #54
https://swiftweeklybrief.com/issue-54
2017-01-26T00:00:00-08:00
2017-01-26T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week was <em>manifesto</em> week, with a couple of new manifestos showing up in the main Swift repo a la Doug Gregor’s original <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md">Generics Manifesto</a>. Additional interviews with Chris Lattner made their rounds on the web, and the first few proposals of the new year are under review — evidence that Boris Bügling <em>does</em> actually work sometimes. 😉 😄</p>
<!--excerpt-->
<p class="text-center"><b>Interested in sponsoring Swift Weekly Brief? <a href="https://swiftweeklybrief.com/sponsorship/">Learn more here</a>.</b></p>
<h3 id="news-and-community">News and community</h3>
<p>Mishal Shah announced that Swift 3.1 <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20170123/003862.html">development snapshots are now available</a> on <a href="https://swift.org/download/#snapshots">Swift.org</a>.</p>
<p>The first Xcode 8.3 beta <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_8.3_beta/Release_Notes_for_Xcode_8.3_beta.pdf">was released</a>. This version <strong>no longer supports Swift 2.3</strong> and includes Swift 3.1 which is intended to be source compatible with Swift 3.0.</p>
<p>In case you haven’t read and listened to enough interviews with Chris Lattner 😄, Slashdot posted an <a href="https://developers.slashdot.org/story/17/01/23/085232/slashdots-interview-with-swift-creator-chris-lattner">interview</a>, Accidental Tech posted a <a href="http://atp.fm/205-chris-lattner-interview-transcript">full transcript</a> of their interview from last week, and Chris also appeared on the <a href="https://swiftcoders.podbean.com/e/37-chris-lattner-creator-of-swift">SwiftCoders</a> podcast. 😎</p>
<p>Let Greg Heo (<a href="https://twitter.com/gregheo">@gregheo</a>) take you on <a href="https://swiftunboxed.com/open-source/map/">a tour of <code class="language-plaintext highlighter-rouge">.map</code></a> in Swift. If you’ve had trouble understanding what <code class="language-plaintext highlighter-rouge">.map</code> does and how it works, then read this article and thank Greg later.</p>
<p>Jacob Bandes-Storch (<a href="https://twitter.com/jtbandes">@jtbandes</a>) <a href="https://twitter.com/jtbandes/status/823991172527898624">noticed</a> that Swift syntax highlighting <a href="https://github.com/textmate/swift.tmbundle/compare/841f53f...master">changes</a> have been pushed to GitHub.</p>
<p>Not new (but new to me!), but Caleb Davenport (<a href="https://github.com/calebd">@calebd</a>) <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/167#issuecomment-275221190">pointed out</a> that there’s unofficial <a href="https://fossies.org/dox/swift-swift-3.0.2-RELEASE/">Swift docs</a> hosted at fossies.org. You can type in the name of any class in the Swift compiler C++ source code and it will show you class diagrams, documentation, and more. From Greg Heo: <em>“I looked up what I thought would make the scariest class diagram and wasn’t disappointed.”</em> See <a href="https://fossies.org/dox/swift-swift-3.0.2-RELEASE/structVisitNodeResult.html">VisitNodeResult</a>. 😅</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Ben Cohen (<a href="https://github.com/airspeedswift">@airspeedswift</a>) <a href="https://github.com/apple/swift/commit/a716581c8b0bb421a19d40ad91466e2173f0a387">committed</a> a new doc, the <a href="https://github.com/apple/swift/blob/master/docs/StringManifesto.md">String Manifesto</a>:</p>
<blockquote>
<p>For Swift 4 and beyond we want to improve three dimensions of text processing:</p>
<ol>
<li>Ergonomics</li>
<li>Correctness</li>
<li>Performance</li>
</ol>
<p>This document is meant to both provide a sense of the long-term vision (including undecided issues and possible approaches), and to define the scope of work that could be done in the Swift 4 timeframe. […]</p>
</blockquote>
<p>Michael Ilseman (<a href="https://github.com/milseman">@milseman</a>) <a href="https://github.com/apple/swift/commit/4fcdcb5c8d260ca8576c8c0c4887a66d078005b8#diff-2a6d24c08daab38bbd62e44bfecb4113">committed</a> a new doc, the <a href="https://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md">Swift ABI Stability Manifesto</a>:</p>
<blockquote>
<p>One of the top priorities for Swift right now is compatibility across future Swift versions. Compatibility aims at accomplishing two goals:</p>
<ol>
<li><em>Source compatibility</em> means that newer compilers can compile code written in an older version of Swift. This aims to reduce the migration pain that Swift developers face when migrating to a newer Swift version. […]</li>
<li><em>Binary framework & runtime compatibility</em> enables the distribution of frameworks in a binary form that works across multiple Swift versions. […]</li>
</ol>
<p>This document is an exploration and explanation of Swift’s ABI alongside the goals and investigations needed before declaring Swift’s ABI stable. It is meant to be a resource to the community as well as a declaration of the direction of Swift’s ABI. […]</p>
</blockquote>
<p>Tony Allevato (<a href="https://github.com/allevato">@allevato</a>) <a href="https://github.com/apple/swift/pull/6850">merged</a> improvements to speed up <code class="language-plaintext highlighter-rouge">Character.init</code>, resulting in a ~150-300x improvement in some scenarios. 😱 The pull request description has all of the details.</p>
<p>Jacob Bandes-Storch (<a href="https://github.com/jtbandes">@jtbandes</a>) has been <a href="https://github.com/apple/swift-evolution/pull/592">working on</a> improving the new <a href="https://apple.github.io/swift-evolution/">proposal status page</a>.</p>
<p>Michael Gottesman (<a href="https://github.com/gottesmm">@gottesmm</a>) <a href="https://github.com/apple/swift/pull/7032">merged</a> ownership verifier fixes that were found when testing the verifier on SILGen output.</p>
<p><a href="https://github.com/larryonoff">@larryonoff</a> merged <a href="https://github.com/apple/swift-corelibs-xctest/pull/176">support</a> for watchOS, tvOS, and iOS in corelibs-xctest.</p>
<p>David Grove (<a href="https://github.com/dgrove-oss">@dgrove-oss</a>) <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/206">implemented</a> <code class="language-plaintext highlighter-rouge">pthread_workqueue</code> within libdispatch.</p>
<p>There’s an old, but really interesting <a href="https://github.com/apple/swift-corelibs-xctest/pull/61">pull request</a> from Brian Croom (<a href="https://github.com/briancroom">@briancroom</a>) that adds unit testing infrastructure to corelibs-xctest. It still hasn’t been merged, but maybe someone out there is interested in nudging it along. 😄</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md">SE-0148</a>: <em>Generic Subscripts</em> by Chris Eidhof is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000306.html">under review</a>.</p>
<blockquote>
<p>Currently, subscripts can’t be generic. This is limiting in a number of ways:</p>
<ul>
<li>Some subscripts are very specific and could be made more generic.</li>
<li>Some generic methods would feel more natural as a subscript, but currently can’t be. This also makes it impossible to use them as lvalues.
This feature is also mentioned in the generics manifesto under <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generic-subscripts">generic subscripts</a>.</li>
</ul>
<p>Example of a generic subscript:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">Collection</span> <span class="p">{</span>
<span class="kd">subscript</span><span class="o"><</span><span class="kt">Indices</span><span class="p">:</span> <span class="kt">Sequence</span><span class="o">></span><span class="p">(</span><span class="nv">indices</span><span class="p">:</span> <span class="kt">Indices</span><span class="p">)</span> <span class="o">-></span> <span class="p">[</span><span class="kt">Iterator</span><span class="o">.</span><span class="kt">Element</span><span class="p">]</span> <span class="k">where</span> <span class="kt">Indices</span><span class="o">.</span><span class="kt">Iterator</span><span class="o">.</span><span class="kt">Element</span> <span class="o">==</span> <span class="kt">Index</span> <span class="p">{</span>
<span class="c1">// ...</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Or a generic return type:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">JSON</span> <span class="p">{</span>
<span class="kd">subscript</span><span class="o"><</span><span class="kt">T</span><span class="p">:</span> <span class="kt">JSONConvertible</span><span class="o">></span><span class="p">(</span><span class="nv">key</span><span class="p">:</span> <span class="kt">String</span><span class="p">)</span> <span class="o">-></span> <span class="kt">T</span><span class="p">?</span> <span class="p">{</span>
<span class="c1">// ...</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0149-package-manager-top-of-tree.md">SE-0149</a>: <em>Package Manager Support for Top of Tree development</em> by Boris Bügling (<a href="https://twitter.com/neonacho">#yatusabes</a>) is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000308.html">under review</a>.</p>
<blockquote>
<p>This proposal adds enhancements to swift package edit to support development of packages without strict versioning (“top of tree” development).</p>
<p>The package manager currently supports package dependencies which are strictly versioned according to semantic versioning. This works well for users of packages and it is possible to edit a package in place using <code class="language-plaintext highlighter-rouge">swift package edit</code> already, but we want to allow developers to manually check out repositories on their machines as overrides. This is useful when developing multiple packages in tandem or when working on packages alongside an application. […]</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0150-package-manager-branch-support.md">SE-0150</a>: <em>Package Manager Support for branches</em> by Boris Bügling (<a href="https://twitter.com/neonacho">#yatusabes</a>) is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000309.html">under review</a>.</p>
<blockquote>
<p>This proposal adds enhancements to the package manifest to support development of packages without strict versioning. This is one of two features, along with “Package Manager Support for Top of Tree development”, being proposed to enable use of SwiftPM to develop on “top of tree” of related packages.</p>
<p>The package manager currently supports packages dependencies which are strictly versioned according to semantic versioning. This is how a package’s dependencies should be specified when that package is released, but this requirement hinders some development workflows:</p>
<ul>
<li>bootstrapping a new package which does not yet have a version at all</li>
<li>developing related packages in tandem in between releases, when one package may depend on the latest revision of another, which has not yet been tagged for release</li>
</ul>
<p>[…]</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Rick Ballard <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000307.html">sent an email</a> announcing the Swift 4 Package Manager roadmap. This lengthy email is worth a read and shows how hard the SwiftPM team has been working. Features and improvements that will ship with Swift 3.1 include: a new <code class="language-plaintext highlighter-rouge">swift package edit</code> command to begin editing on a package, pinning, project generation improvements, a new dependency resolver, cycle detection and incremental build correctness, parallel cloning, and improved test coverage and infrastructure. The work that the team is planning for Swift 4 is even more impressive.</p>
<blockquote>
<p>Hello Swift Package Manager community,</p>
<p>The package manager’s release in Swift 3 was a big success, with many enthusiastic adopters. Since then we’ve been hard at work building the next version of the package manager. We have a lot we want to do, but focus is important for building a successful tool, so we’ve defined a set of goals that we expect to focus on for Swift 4. As always, this roadmap may be amended based on feedback from the community, and pull requests for improvements outside this list are still welcome!</p>
<p>This email covers a lot of different features, so instead of replying directly it would be best to start a new thread on any topic you’d like to discuss in detail.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000307.html">Continue reading…</a></p>
</blockquote>
<p>Thomas Catterall (<a href="https://github.com/swizzlr">@swizzlr</a>) announced an unofficial “official” <a href="https://github.com/swiftdocker/docker-swift">docker container</a> for Swift.</p>
<blockquote>
<p>I’m pleased to announce that with the assistance of many, many people (see below), we have released an <a href="https://hub.docker.com/_/swift/">“official” Docker image for Swift</a>.</p>
<p>The image contains everything needed to compile and run a Swift application, reliably and reproducibly. It’s based on Ubuntu 16.04 and has been used in production for many months now. A Docker library image such as this one occupies the top level namespace, so that you can simply write “FROM swift” to refer to the image. It has received extensive auditing for best practices and security by Docker experts, and will be maintained by a dedicated team of volunteers.</p>
<p>I would like to encourage everyone interested to ask questions and offer improvements over on the <a href="https://github.com/swiftdocker/docker-swift">Github repo</a>. […]</p>
</blockquote>
<p>In <a href="http://llvmweekly.org/issue/160">LLVM Weekly #160</a> Alex Bradbury linked to <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-January/109138.html">an email from John Regehr</a>, the secretary of the LLVM Foundation, that announced that Chris Lattner will remain on the LLVM Foundation Board of Directors.</p>
<blockquote>
<p>As you’ve likely heard by now, Chris Lattner is leaving his position at Apple, and thus will no longer be managing Apple’s LLVM efforts. This raised a question of whether Chris should be removed from the LLVM Foundation Board of Directors. After discussing the issue, the board unanimously agreed that there is no reason to change the board’s composition, or anything else related to the Foundation’s governance, at this time. […]</p>
</blockquote>
<p>Also on the LLVM-dev lists, Alex Rosenberg <a href="http://lists.llvm.org/pipermail/llvm-dev/2017-January/108953.html">reiterated Apple’s commitment to LLVM</a>:</p>
<blockquote>
<p>You may have heard about changes in the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030063.html">Swift community</a>, and we wanted to make it clear that Apple is strongly committed to open source and the LLVM and Clang tools.</p>
<p>Our compiler toolchain has been, is, and will continue to be based on LLVM and Clang. We remain one of the largest users of and contributors to LLVM, as evidenced by our extensive contributions to the project and the breadth of Apple employee participation in the overall project and the LLVM DevMtg in November. We’re as committed as ever.</p>
</blockquote>
<p>Tony Parker <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20170123/001092.html">asked for help in testing <code class="language-plaintext highlighter-rouge">URLSession</code></a>:</p>
<blockquote>
<p>As we’re wrapping up Swift 3.1, I think it’d be a great opportunity to have a quality focus area on one of our most important APIs: URLSession. If you’ve been wondering how to make a meaningful contribution, this is the perfect time.</p>
<p>It’d be great to greatly expand both unit test and higher level test coverage of URLSession. For testing that can’t really be part of a unit test and CI like poorly performing networks or esoteric configurations, it would also be nice to build a different kind of test tool. That tool would provide a lot of knobs for controlling a URLSession. We could make this tool part of the swift-corelibs-foundation project.</p>
<p>Is anyone interested in chipping in here? We don’t have to start big. Even small contributions could get us moving in the right direction.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/822973978629128192">“This program cannot be run in DOS mode.”</a></p>
Issue #53
https://swiftweeklybrief.com/issue-53
2017-01-19T00:00:00-08:00
2017-01-19T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to the weekly! As of Tuesday, January 17 <code class="language-plaintext highlighter-rouge">master</code> branch development has <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20170109/001070.html">officially switched</a> to Swift 4.0. This marked the last periodic merge of <code class="language-plaintext highlighter-rouge">master</code> into the <code class="language-plaintext highlighter-rouge">swift-3.1-branch</code> branch. Anything else going into Swift 3.1 will now require approval from our new Swift overlord, <a href="https://github.com/tkremenek">Ted Kremenek</a>. 😄 I suppose this means we’re officially commencing <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000269.html">Swift 4 Phase 1</a>.</p>
<!--excerpt-->
<div class="alert alert-warning sponsor">
<h4>Sponsored Link</h4>
<h4><a href="http://shop.waynewbishop.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_53" target="_blank">The Swift Algorithms Book (Now Shipping Internationally!)</a></h4>
<p>Written for students and professionals, the 2nd edition of Swift Algorithms & Data Structures blends modern code, illustrations and computer science to help you pass the interview or build your next app. Revised and updated for Swift 3.0, we’ve recently expanded our shipping options to include more than 70 countries. Use coupon code <strong>JESSE</strong> at checkout to receive a <strong>20% discount</strong>!</p>
<p><small><a href="http://shop.waynewbishop.com/?utm_campaign=Swift_Weekly_Brief&utm_medium=email_web&utm_source=Swift_Weekly_Brief_53" target="_blank">shop.waynewbishop.com</a></small></p>
</div>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3625">SR-3625</a>: [Swift Package Manager] Make <code class="language-plaintext highlighter-rouge">Process</code> class thread safe</li>
<li><a href="https://bugs.swift.org/browse/SR-3455">SR-3455</a>: [Compiler] Evaluation and validation of build conditions should be separate</li>
<li><a href="https://bugs.swift.org/browse/SR-3343">SR-3343</a>: [Standard library] Investigate <code class="language-plaintext highlighter-rouge">Array</code> canaries for <code class="language-plaintext highlighter-rouge">withUnsafe*</code> operations</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Hopefully everyone has had time to absorb <a href="/issue-52/">last week’s news</a> that Chris Lattner will be leaving Apple. Nothing has changed, right?! 😄 Lattner was <a href="http://www.macrumors.com/2017/01/17/chris-lattner-says-tesla-irresistible/">interviewed by MacRumors</a> where he elaborated a bit more on his decision. There are no conspiracy theories here. After 16 years of working on developer tools, wouldn’t you be ready for something new too? Remember, Lattner also started and left LLVM, a project that continues to thrive.</p>
<p>The <a href="https://twitter.com/atpfm">Accidental Tech Podcast</a> also <a href="http://atp.fm/episodes/205">interviewed Chris Lattner</a> in their latest episode. It’s great and definitely worth a listen!</p>
<p>In cased you missed it back in December or just need a refresher, there’s an official blog post on the <a href="https://swift.org/blog/swift-3-1-release-process/"><em>Swift 3.1 Release Process</em></a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Karl Weinmeister (<a href="https://github.com/kweinmeister">@kweinmeister</a>) sent a <a href="https://github.com/apple/swift-corelibs-foundation/pull/791">pull request</a> that implements and tests <code class="language-plaintext highlighter-rouge">EnergyFormatter</code> in corelibs-foundation.</p>
<p>Hugh Bellamy (<a href="https://github.com/hughbe">@hughbe</a>) <a href="https://github.com/apple/swift/pull/6821">ported</a> swift-demangle to Windows.</p>
<p>Matthew Carroll (<a href="https://github.com/matthewcarroll">@matthewcarroll</a>) submitted <a href="https://github.com/apple/swift/pull/6823">a fix</a> for starter bug <a href="https://bugs.swift.org/browse/SR-2475">SR-2475</a>, which adds a diagnostic that warns when an unlabeled parameter follows a variadic parameter.</p>
<p>Arthur Sabintsev (<a href="https://github.com/ArtSabintsev">@ArtSabintsev</a>) <a href="https://github.com/apple/swift/pull/6776">implemented</a> <code class="language-plaintext highlighter-rouge">XCTAssertNoThrow</code> in the SDK overlays for Swift and also <a href="https://github.com/apple/swift-corelibs-xctest/pull/184">add support</a> for this in corelibs-xctest.</p>
<p>Chris Eidhof opened a <a href="https://github.com/apple/swift-evolution/pull/584/files">pull request</a> on swift-evolution with an initial draft of his generic subscripts proposal.</p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080</a>: <em>Failable Numeric Conversion Initializers</em> has officially <a href="https://github.com/apple/swift-evolution/commit/24aafe9aa0cbcec757ab495c32e8718d14d5f809">been marked as implemented</a> for Swift 3.1.</p>
<h3 id="proposals">Proposals</h3>
<p>Max Moiseev (<a href="https://github.com/moiseev">@moiseev</a>) sent <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030191.html">an email</a> regarding the status of proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em>, which was accepted for Swift 3 but <strong>not</strong> completed in time. This second draft has been updated for the current state of Swift and is being discussed on the mailing list.</p>
<blockquote>
<p>Back in June 2016 we discussed the new design of the integer types for the standard library. It even resulted in acceptance of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a> for Swift 3. Unfortunately we were not able to implement it in time for the release.</p>
<p>But it was not forgotten, although, as time went by, a few changes needed to be made in order to reflect the current state of the language.
Without further introduction, please welcome the refined proposal to make integers in Swift more suitable for generic programming.</p>
<p>Available in <a href="https://gist.github.com/moiseev/62ffe3c91b66866fdebf6f3fcc7cad8c">this gist</a>.</p>
</blockquote>
<p>There is a fancy new <a href="https://apple.github.io/swift-evolution/">status page</a>! Kyle Murray (<a href="https://github.com/krilnon/">@krilnon</a>) built the new status page and wrote a <a href="https://swift.org/blog/swift-evolution-status-page/">blog post</a> announcing the <a href="https://github.com/apple/swift-evolution/pull/589">changes</a>. It seems like he will also review proposal pull requests, as stated in the newly added <a href="https://github.com/apple/swift-evolution/blob/master/CONTRIBUTING.md">CONTRIBUTING.md</a>.</p>
<blockquote>
<p>To help make sense of it all, the status page has several ways to navigate through the list of proposals. You can search for specific authors, review managers, and topics by keyword. You can narrow the list to show only the proposals that were implemented in a particular version of Swift.</p>
</blockquote>
<p>The new site looks great! You can search based on proposal metadata but not proposal contents. I suppose this mostly replaces my <a href="https://github.com/jessesquires/swift-proposal-analyzer">swift-proposal-analyzer</a> project. 😅 <a href="https://en.wikipedia.org/wiki/Sherlock_(software)">Sherlocked</a>!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>As mentioned above, Nicole Jacque sent <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20170109/001070.html">an email</a> announcing the final merge from <code class="language-plaintext highlighter-rouge">master</code>:</p>
<blockquote>
<p>As outlined in Ted’s Swift 3.1 Release Process blog post, for the past month, we’ve been periodically merging <code class="language-plaintext highlighter-rouge">master</code> to the <code class="language-plaintext highlighter-rouge">swift-3.1-branch</code> branch. We will be doing one final merge of master to the <code class="language-plaintext highlighter-rouge">swift-3.1-branch</code> on January 17 at noon (Pacific). Note that we’ve pushed this back a day due to the MLK Jr. Day holiday. Any changes landed after that time will require approval via a pull request against the <code class="language-plaintext highlighter-rouge">swift-3.1-branch</code> branch in order to include them in the Swift 3.1 release. After this final merge, development on master will be targeted for Swift 4.</p>
<p>Snapshots of the <code class="language-plaintext highlighter-rouge">swift-3.1-branch</code> will be made available on the <a href="https://swift.org/download/">downloads page</a>. Snapshots will be made available daily, if all package generation CI tests are passing.</p>
</blockquote>
<p>Adam Shin started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030183.html">a discussion</a> on equatability for enums with associated values, proposing that Swift add support for <code class="language-plaintext highlighter-rouge">enum</code> values with <code class="language-plaintext highlighter-rouge">Equatable</code> associated types be automatically <code class="language-plaintext highlighter-rouge">Equatable</code> too.</p>
<blockquote>
<p>When using enums with associated values, it’s often necessary to check for equality between two enum objects in some way. That can lead to boilerplate […] which results in code duplication and opens the door to potential logic errors.</p>
<p>Instead, what if enums with associated values were automatically <code class="language-plaintext highlighter-rouge">Equatable</code> when all their associated values were <code class="language-plaintext highlighter-rouge">Equatable</code>? That would remove the need for such boilerplate code.</p>
</blockquote>
<p>Chris Eidhof proposed <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170116/030300.html">adding a new version of reduce</a> to the standard library:</p>
<blockquote>
<p>How does everyone feel about adding a second version of <code class="language-plaintext highlighter-rouge">reduce</code> to <code class="language-plaintext highlighter-rouge">Sequence</code>? Instead of a <code class="language-plaintext highlighter-rouge">combine</code> function that’s of type <code class="language-plaintext highlighter-rouge">(A, Element) -> A</code>, it would be <code class="language-plaintext highlighter-rouge">(inout A, Element) -> ()</code>. This way, we can write nice functionals algorithms, but have the benefits of <code class="language-plaintext highlighter-rouge">inout</code> (mutation within the function, and hopefully some copy eliminations).</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/reyner/status/819765555255050240">Swift custom operator ideas?</a></p>
Issue #52
https://swiftweeklybrief.com/issue-52
2017-01-12T00:00:00-08:00
2017-01-12T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week brought some very unexpected news. As you’ve likely heard, <a href="http://nondot.org/sabre/">Chris Lattner</a> will be <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030063.html">leaving Apple</a> and <a href="https://www.tesla.com/blog/welcome-chris-lattner">joining Tesla</a>. The original author of the Clang Static Analyzer, <a href="https://twitter.com/tkremenek">Ted Kremenek</a>, will be taking over as Swift Project Lead. While the timing certainly seems abrupt, these things rarely happen at “good” or convenient times. I’m sure he will be missed at Apple, and it’s certainly a great loss for the company. Let’s all wish Chris the best of luck! The good news is that the <a href="https://swift.org/community/#community-structure">Core Team</a> is still there — and they’ve been doing all the hard work lately anyway, right? 😉</p>
<p>One thing to note is that Chris is the first Core Team member to leave Apple and <em>remain</em> on the Core Team. Ironically, this makes him the <em>first</em> non-Apple member of the Core Team. In his note to swift-evolution, he mentioned that he intends to stay involved so hopefully the project will still benefit from his guidance and contributions!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3542">SR-3542</a>: [Starter Proposal] <code class="language-plaintext highlighter-rouge">enum</code> cases should have compound names, like functions</li>
<li><a href="https://bugs.swift.org/browse/SR-3419">SR-3419</a>: [Starter Proposal] Strides should be collections</li>
<li><a href="https://bugs.swift.org/browse/SR-888">SR-888</a>: [Starter Proposal] <code class="language-plaintext highlighter-rouge">Sequence.minElement()</code> and <code class="language-plaintext highlighter-rouge">maxElement()</code> should be protocol requirements (customization points)</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p><a href="https://www.dotswift.io">DotSwift</a>, <em>the European Swift Conference</em>, will be held 27 January, 2017 in Paris, France. <em>Swift Weekly Brief</em> readers can get a <strong>20% discount</strong> on tickets with the code <strong>SWIFTWEEKLYBRIEF</strong> (<a href="https://dotswift2017.eventbrite.com/?discount=SWIFTWEEKLYBRIEF">direct link</a>).</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Graydon Hoare (<a href="https://github.com/graydon">@graydon</a>) sent a promising <a href="https://github.com/apple/swift/pull/5977">pull request</a> to speed up project build times in non-WMO (<a href="https://swift.org/blog/whole-module-optimizations/">whole-module-optimization</a>) mode. <em>“The point is to accelerate non-WMO builds with large bridging headers, which spend a nontrivial amount of time re-importing the header for each frontend job.”</em></p>
<p>Ben Ng (<a href="https://github.com/ben-ng">@ben-ng</a>) sent a <a href="https://github.com/apple/swift/pull/6653">pull request</a> to add a benchmark for <code class="language-plaintext highlighter-rouge">+=</code> when appending to an <code class="language-plaintext highlighter-rouge">Array</code>. This is to measure the impact of his <a href="https://github.com/apple/swift/pull/6652">other pull request</a> that improves the performance of appending to <code class="language-plaintext highlighter-rouge">Array</code> with <code class="language-plaintext highlighter-rouge">+=</code>.</p>
<p>Russell Currey (<a href="https://twitter.com/russelldotcc">@russelldotcc</a>) merged a <a href="https://github.com/apple/swift-corelibs-foundation/pull/767">pull request</a> to corelibs-foundation to enable building on PowerPC.</p>
<p>Maxim Moiseev (<a href="https://twitter.com/moiseev">@moiseev</a>) opened a <a href="https://github.com/apple/swift/pull/6603">pull request</a> to deprecate <code class="language-plaintext highlighter-rouge">+</code> and <code class="language-plaintext highlighter-rouge">-</code> for <code class="language-plaintext highlighter-rouge">SignedInteger</code> and its Stride. This allowed for mixed-type arithmetic, which is not supposed to work. It was necessary prior to the new <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md">collection indexing model</a> to make moving indexes simple. This is a breaking change that will be allowed (with a warning) under Swift 3.1 and will be an error in Swift 4.</p>
<p>Ankit Aggarwal (<a href="https://twitter.com/aciidb0mb3r">@aciidb0mb3r</a>) marked both <a href="https://github.com/apple/swift-evolution/commit/abb4d442d1e174de405c4880f4b38c46baeeaecf">SE-0082</a>: <em>Package Manager Editable Packages</em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md">proposal link</a>) and <a href="https://github.com/apple/swift-evolution/commit/70ef7fbe267ede911d59295e298e97deaf5e7317">SE-0145</a>: <em>Package Manager Version Pinning</em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md">proposal link</a>) as implemented in Swift 3.1.</p>
<p>K Staring (<a href="https://github.com/kstaring">@kstaring</a>) finally <a href="https://github.com/apple/swift/pull/4804">merged</a> a patch for FreeBSD compatibility that lets the current Swift 3 codebase compile on FreeBSD. The pull request was originally opened in September, but just merged this week.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0147-move-unsafe-initialize-from.md">SE-0147</a>: <em>Move <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer.initialize(from:)</code> to <code class="language-plaintext highlighter-rouge">UnsafeMutableBufferPointer</code></em> by Ben Cohen was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2017-January/000305.html">accepted</a>.</p>
<blockquote>
<p>Feedback was light but positive, and the proposal is accepted for Swift 4. Thanks to everyone who participated!</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>As mentioned above, Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030063.html">sent an email</a> this week about leaving Apple and transferring his responsibilities to <a href="https://twitter.com/tkremenek">Ted Kremenek</a>:</p>
<blockquote>
<p>Since Apple launched Swift at WWDC 2014, the Swift team has worked closely with our developer community. When we made Swift open source and launched Swift.org we put a lot of effort into defining a strong community structure. This structure has enabled Apple and the amazingly vibrant Swift community to work together to evolve Swift into a powerful, mature language powering software used by hundreds of millions of people.</p>
<p>I’m happy to announce that Ted Kremenek will be taking over for me as “Project Lead” for the Swift project, managing the administrative and leadership responsibility for Swift.org. This recognizes the incredible effort he has already been putting into the project, and reflects a decision I’ve made to leave Apple later this month to pursue an opportunity in another space. This decision wasn’t made lightly, and I want you all to know that I’m still completely committed to Swift. I plan to remain an active member of the Swift Core Team, as well as a contributor to the swift-evolution mailing list.</p>
<p>Working with many phenomenal teams at Apple to launch Swift has been a unique life experience. Apple is a truly amazing place to be able to assemble the skills, imagination, and discipline to pull something like this off. Swift is in great shape today, and Swift 4 will be a really strong release with Ted as the Project Lead.</p>
<p>Note that this isn’t a change to the structure - just to who sits in which role - so we don’t expect it to impact day-to-day operations in the Swift Core Team in any significant way. Ted and I wanted to let you know what is happening as a part of our commitment to keeping the structure of Swift.org transparent to our community.</p>
<p>-Chris</p>
</blockquote>
<p>In a follow-up email, Chris <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030078.html">elaborated</a> on the change a bit more:</p>
<blockquote>
<p>One thing that I don’t think is fully appreciated by the community: Ted has been one of the quiet but incredible masterminds behind Swift (and Clang, and the Clang Static Analyzer) for many years. His approach and modesty has led many to misunderstand the fact that he has actually been running the Swift team for quite some time (misattributing it to me). While I’m super happy to continue to participate in the ongoing evolution and design of Swift, I’m clearly outmatched by the members of the Apple Swift team, and by Ted’s leadership of the team. This is the time for me to graciously hand things over to folks who are far more qualified than me. Swift has an incredible future ahead of it, and I’m really thrilled to be small part of the force that helps guide its direction going forward.</p>
</blockquote>
<p>I’ve spoken with Ted a few times via Twitter, and he’s always been super kind and helpful. I’m confident the project and community are in good hands. I’d love to see Ted show up at some of the indie Swift conferences this year!</p>
<p>Alex Martini <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029962.html">sent out an email</a> on design discussion for upcoming proposals:</p>
<blockquote>
<p>To help keep proposals moving forward, the Swift core team has set aside some time specifically for design discussions of upcoming proposals. Below are some rough notes from the discussion this week.</p>
<p>These are informal comments, intended to guide the proposals in directions that draw constructive feedback. You are welcome to ignore the feedback, agree with it, or disagree with it. As always, the formal decision doesn’t happen until after the review period ends.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029962.html">continue reading…</a></p>
</blockquote>
<p>The email goes on to mostly discuss details about Doug Gregor’s <a href="https://github.com/DougGregor/swift-evolution/blob/objc-inference/proposals/NNNN-objc-inference.md">draft proposal</a>, <em>Limiting @objc inference</em>.</p>
<p>Chris Eidhof <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170109/030064.html">started a thread</a> to discuss generic subscripts.</p>
<blockquote>
<p>Recently, I’ve bumped into the lack of generic subscripts a few times. There are a bunch of useful things you could do with it. It’s in the generics manifesto as well…</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/slava_pestov/status/818625485588434946">Once the yak has been fully shaved…</a></p>
Issue #51
https://swiftweeklybrief.com/issue-51
2017-01-05T00:00:00-08:00
2017-01-05T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome back to the weekly! Hopefully you enjoyed some time off over the last few weeks. As expected, the Swift project repos are back to buzzing with their usual activity. Welcome to <a href="https://github.com/apple/swift/pull/6519">2017</a>, let’s dive in!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3359">SR-3359</a>: [Compiler] Warn if <code class="language-plaintext highlighter-rouge">@discardableResult</code> is used with a <code class="language-plaintext highlighter-rouge">Void</code> result.</li>
<li><a href="https://bugs.swift.org/browse/SR-3281">SR-3281</a>: [Compiler] The Swift man page is out of date</li>
<li><a href="https://bugs.swift.org/browse/SR-3207">SR-3207</a>: [Compiler] Segmentation fault with Objective-C parameter of <code class="language-plaintext highlighter-rouge">NSError* __autoreleasing __nonnull * __nullable</code></li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Apple’s holiday period ended on January 3rd. The <code class="language-plaintext highlighter-rouge">master</code> branch lock was released, CI buildbots returned online, and Apple employees <a href="https://twitter.com/slava_pestov/status/816525308580929536">merged</a> over 30 pull requests that had piled up over the break.</p>
<p>Ray Fix (<a href="https://twitter.com/rayfix">@rayfix</a>) wrote an article, <a href="https://www.raywenderlich.com/148569/unsafe-swift"><em>Unsafe Swift: Using Pointers And Interacting With C</em></a>, which dives into the <code class="language-plaintext highlighter-rouge">Unsafe[Mutable][Raw][Buffer][Pointer][<T>]</code> APIs in the standard library. Ray explains nearly everything you need to know about these APIs and how to use them. 😎</p>
<p><a href="https://github.com/antlr/antlr4">ANTLR</a>, <em>ANother Tool for Language Recognition</em>, now <a href="https://twitter.com/clattner_llvm/status/809640290378137600">supports Swift</a>. You can <a href="https://github.com/antlr/antlr4/blob/master/doc/swift-target.md">get started here</a>. 🤓</p>
<p>Chris Lattner <a href="https://twitter.com/clattner_llvm/status/810175976583950336">shared</a> his <a href="http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf">slides</a> from his talk at IBM’s <a href="http://researcher.watson.ibm.com/researcher/view_group_subpage.php?id=6940">Programming Languages Day</a>. In the talk, he discusses a number of things: potential improvements for Swift compiler, such as parallel WMO based on LLVM’s ThinLTO approach, Swift 5 is planned for release in 2018 and may include a concurrency model, and discussions on that concurrency model will begin in Spring/Summer 2017. 😱</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>During the holiday break while the <code class="language-plaintext highlighter-rouge">master</code> branch was locked, the team took some time to smash bugs. Slava Pestov opened a <a href="https://github.com/apple/swift/pull/6484">pull request</a> with fixes for a number of compiler crashers. <a href="https://github.com/practicalswift">@practicalswift</a> regularly <a href="https://github.com/apple/swift/pull/6484#issuecomment-269871144">posted status updates</a>:</p>
<blockquote>
<p>Currently there are 82 crashers marked as unresolved in the repo. Of those 82 crashers …</p>
<p>65 crashers have been fixed in submitted PRs which will be merged once master is unlocked (great work by this team: 34 crashers fixed by <a href="https://github.com/xedin">@xedin</a>, 25 crashers fixed by <a href="https://github.com/slavapestov">@slavapestov</a> and 6 crashers fixed by <a href="https://github.com/CodaFi">@CodaFi</a>)</p>
<p>[…]</p>
</blockquote>
<p>Brian Gesiak (<a href="https://twitter.com/modocache">@modocache</a>) <a href="https://github.com/apple/swift/pull/6495">implemented</a> colorized output for <code class="language-plaintext highlighter-rouge">-dump-parse</code> and <code class="language-plaintext highlighter-rouge">-dump-ast</code>.</p>
<p>Slava Pestov (<a href="https://twitter.com/slava_pestov">@slava_pestov</a>) <a href="https://github.com/apple/swift/pull/6133">implemented</a> evolution proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a>: <em>Distinguish between single-tuple and multiple-argument function types</em>. This is the first implemented proposal for Swift 4. 🎉</p>
<p><a href="https://github.com/antonmes">@antonmes</a> <a href="https://github.com/apple/swift-corelibs-foundation/pull/748">submitted</a> a pull request to corelibs-foundation to implement <code class="language-plaintext highlighter-rouge">Thread.main</code> and <code class="language-plaintext highlighter-rouge">Thread.isMainThread</code>.</p>
<p>Brian Gesiak (<a href="https://twitter.com/modocache">@modocache</a>) <a href="https://github.com/apple/swift/pull/6513">sent</a> a pull request that marks functions that can return twice, such as <code class="language-plaintext highlighter-rouge">vfork</code> and <code class="language-plaintext highlighter-rouge">setjmp</code>, unavailable in Swift. Swift code that used those functions would almost certainly crash.</p>
<p>Doug Gregor (<a href="https://twitter.com/dgregor79">@dgregor79</a>) <a href="https://github.com/apple/swift/pull/6309">merged</a> changes to the type checker to clean up <code class="language-plaintext highlighter-rouge">as</code>, <code class="language-plaintext highlighter-rouge">as!</code>, <code class="language-plaintext highlighter-rouge">as?</code>, and <code class="language-plaintext highlighter-rouge">is</code> casting. This refactoring resolves a number of SR bugs and radars.</p>
<p>Kevin Ballard (<a href="https://twitter.com/eridius">@eridius</a>) <a href="https://github.com/apple/swift/pull/6480">merged</a> changes to include unavailable/deprecated/availability attributes when printing Objective-C declarations for Swift functions.</p>
<p>Brian Gesiak (<a href="https://twitter.com/modocache">@modocache</a>) <a href="https://github.com/apple/swift/pull/6530">opened</a> a pull request that adds support for importing “function-like” macros from C and Objective-C. For now, only function-like macros that take no arguments, such as <code class="language-plaintext highlighter-rouge">#define MyMacro() 1</code>, are imported.</p>
<p>Roman Levenstein (<a href="https://github.com/swiftix">@swiftix</a>) sent a <a href="https://github.com/apple/swift/pull/6486">pull request</a> with an initial implementation of the <code class="language-plaintext highlighter-rouge">@_specialize</code> attribute supporting layout constraints and partial specializations.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates this week! See the <a href="http://apple.github.io/swift-evolution/">status page here</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Michael Gottesman (<a href="https://twitter.com/gottesmang">@gottesmang</a>) sent <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161212/003712.html">an email</a> announcing a new tool called <code class="language-plaintext highlighter-rouge">bug-reducer</code>, inspired by LLVM’s <a href="http://llvm.org/docs/Bugpoint.html">bugpoint tool</a>.</p>
<blockquote>
<p>The tool called ‘bug-reducer’ is not a full bugpoint tool, but has what I believe to be the minimum functionality needed to be useful, namely:</p>
<ol>
<li>Given a crashing sil-opt invocation, reduce the number of functions in the input file to a minimal set causing a crash.</li>
<li>Given a crashing sil-opt invocation, reduce the number of optimization passes run on the input file to a minimal set and then try to reduce functions.</li>
<li>A random pass pipeline generator that runs N rounds of a permuted performance optimization pipeline and tries to reduce the test cases using the above tools if a crash is found.</li>
</ol>
<p>For guides on use, please see the <a href="https://github.com/apple/swift/tree/master/utils/bug_reducer">README</a> at: <code class="language-plaintext highlighter-rouge">./swift/utils/bug-reducer/README.md</code>.</p>
<p>Consider this an early holiday gift from me to the Swift team. I hope it is useful. = ).</p>
</blockquote>
<p>In a thread on moving the placement of and adding types to <code class="language-plaintext highlighter-rouge">throws</code>, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161226/029854.html">Chris Lattner commented</a> on the possibility of <code class="language-plaintext highlighter-rouge">Result</code> types:</p>
<blockquote>
<p>I’m personally a big fan of typed <code class="language-plaintext highlighter-rouge">throws</code>, but I know that John McCall has strong concerns. I can’t argue that typed <code class="language-plaintext highlighter-rouge">throws</code> is a high priority at the moment, but as soon as we start talking about concurrency the topic of a <code class="language-plaintext highlighter-rouge">Result</code> type will come back up (for use with futures/async).</p>
<p>I think that discussion will naturally drive the priority on settling the typed throws debate.</p>
</blockquote>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170102/029909.html">sent a draft proposal</a> on limiting <code class="language-plaintext highlighter-rouge">@objc</code> inference:</p>
<blockquote>
<p>Here’s a draft proposal to limit inference of <code class="language-plaintext highlighter-rouge">@objc</code> to only those places where we need it for consistency of the semantic model. It’s in the realm of things that isn’t <em>needed</em> for ABI stability, but if we’re going to make the source-breaking change here we’d much rather do it in the Swift 4 time-frame than later.</p>
<p>One can explicitly write <code class="language-plaintext highlighter-rouge">@objc</code> on any Swift declaration that can be expressed in Objective-C. As a convenience, Swift also infers <code class="language-plaintext highlighter-rouge">@objc</code> in a number of places to improve interoperability with Objective-C and eliminate boilerplate. This proposal scales back the inference of <code class="language-plaintext highlighter-rouge">@objc</code> to only those cases where the declaration must be available to Objective-C to maintain semantic coherence of the model, e.g., when overriding an <code class="language-plaintext highlighter-rouge">@objc</code> method or implementing a requirement of an <code class="language-plaintext highlighter-rouge">@objcprotocol</code>.</p>
<p>[…]</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/slava_pestov/status/816172527944728576">If fixing bugs is called “debugging” …</a> 😄</p>
Issue #50
https://swiftweeklybrief.com/issue-50
2016-12-15T00:00:00-08:00
2016-12-15T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to the 50th issue of the weekly! It’s hard to believe we’ve reached this milestone! 😊</p>
<p>This week Ted Kremenek wrote an official post on the <a href="https://swift.org/blog/swift-3-1-release-process/">3.1 release process</a>. Swift 3.1 is intended to be source compatible with Swift 3.0 and set for release in Spring 2017. (Spring for those of us in the Northern Hemisphere. 😉) The final date to accept major changes for Swift 3.1 will be around January 16, 2017. As Chris Lattner <a href="https://twitter.com/clattner_llvm/status/807368728048324608">noted</a>: <em>“Swift 3.1 is the first release to benefit from the new era of source compatibility, a result of swift-evolution refining and polishing 3.0!”</em></p>
<p><strong>This will be the last issue for 2016.</strong> But don’t worry, I’ll still be periodically <a href="https://twitter.com/swiftlybrief">tweeting</a> anything interesting. Swift.org will likely start to quiet down over the coming weeks. If you’re in the US, enjoy the holidays and (hopefully) time off. We’ll be back in January!</p>
<!--excerpt-->
<h3 id="news-and-community">News and community</h3>
<p>The final version of <a href="https://developer.apple.com/news/?id=12122016a">Xcode 8.2 was released</a>, along with updates for all of Apple’s platforms. (<a href="https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html">Release notes</a>)</p>
<p>Soroush Khanlou wrote a post on <a href="http://khanlou.com/2016/12/guarding-against-long-compiles/"><em>Guarding Against Long Compiles</em></a>. It turns out that it’s pretty easy to have Xcode generate warnings for functions that take too long to type-check.</p>
<p>The video for Mike Ash’s talk <a href="https://realm.io/news/goto-mike-ash-exploring-swift-memory-layout/"><em>Exploring Swift Memory Layout</em></a> at GOTO Copenhagen 2016 is now online. As always, Mike does a great job explaining complex topics.</p>
<h3 id="twitter">Twitter</h3>
<p>There were some interesting discussions on Twitter this week, so how about a new section in the weekly? 😄</p>
<p>Rob Napier <a href="https://twitter.com/cocoaphony/status/808402924535762944">started a thread</a> on the semantics of <code class="language-plaintext highlighter-rouge">nil</code> versus the empty string (<code class="language-plaintext highlighter-rouge">""</code>) when dealing with <code class="language-plaintext highlighter-rouge">String?</code>.</p>
<p>Nick Lockwood <a href="https://twitter.com/nicklockwood/status/808257898296000512">asked</a>, <em>What’s the collective term for constants and variables in Swift? “properties”?</em> <code class="language-plaintext highlighter-rouge">¯\_(ツ)_/¯</code></p>
<p>Ole Begemann <a href="https://twitter.com/olebegemann/status/808687131543666688">investigated</a> how Swift 3 handles the new emoji in iOS 10.2. Spoiler: it isn’t Unicode 9.0 compliant yet. ☹️</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov (<a href="https://twitter.com/slava_pestov">@slava_pestov</a>) found <a href="https://github.com/apple/swift/commit/30c4235193b64050f8110ef5598c7efb4501e0da">and fixed</a> a ‘horrific’ Swift 3 compatibility bug. When they say Swift 3.1 will be compatible with Swift 3, <a href="https://twitter.com/jckarter/status/809134772786036736">they’re serious</a>. 😅</p>
<p>Hugh Bellamy (<a href="https://github.com/hughbe">@hughbe</a>) continued working on the port to Windows with a number of pull requests:</p>
<ul>
<li>Port swift-lldb to Windows, <a href="https://github.com/apple/swift-lldb/pull/105">#105</a></li>
<li>Support building swift/AST with MSVC on Windows, <a href="https://github.com/apple/swift/pull/5948">#5948</a></li>
<li>Port stdlib/public/stubs/GlobalObjects to Windows, <a href="https://github.com/apple/swift/pull/6239">#6239</a></li>
<li>Fix errors and warnings building swift/SIL on Windows using MSVC, <a href="https://github.com/apple/swift/pull/5954">#5954</a></li>
</ul>
<p>Erik Eckstein (<a href="https://github.com/eeckstein">@eeckstein</a>) <a href="https://github.com/apple/swift/pull/6181">fixed</a> an issue where the compiler would seg fault with <code class="language-plaintext highlighter-rouge">-O</code> and <code class="language-plaintext highlighter-rouge">-whole-module-optimization</code>.</p>
<p>Chris Bailey (<a href="https://twitter.com/Chris__Bailey">@Chris__Bailey</a>) posted the <a href="https://github.com/swift-server/work-group/pull/58">meeting minutes</a> from the Server APIs work-group HTTP stream meeting.</p>
<p>Karl Weinmeister (<a href="https://github.com/kweinmeister">@kweinmeister</a>) opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/745">pull request</a> on corelibs-foundation to finish implementing <code class="language-plaintext highlighter-rouge">NSLengthFormatter</code>.</p>
<p>Michael Ilseman, the <a href="https://speakerdeck.com/ayanonagon/contributing-to-swift?slide=11">Swift compiler dog</a>, (<a href="https://twitter.com/Ilseman">@Ilseman</a>) cleaned up <a href="https://github.com/apple/swift/pull/6278">the clang importer</a> in preparation for dealing with Swift source compatibility.</p>
<p>Doug Gregor (<a href="https://twitter.com/dgregor79">@dgregor79</a>) fixed <a href="https://github.com/apple/swift/pull/6294">a constraint solver issue</a> where after binding a type variable, not all affected constraints would be activated.</p>
<h3 id="proposals">Proposals</h3>
<p>No updates this week! Check <a href="http://apple.github.io/swift-evolution/">the status page</a> to see the current state of proposals.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Brian King started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029441.html">a thread</a> on changing <code class="language-plaintext highlighter-rouge">NSObject</code> dispatch behavior.</p>
<blockquote>
<p>I wanted to follow up to a blog post I wrote about <a href="https://www.raizlabs.com/dev/2016/12/swift-method-dispatch">Message Dispatch in Swift</a>. I mentioned some changes to NSObject that didn’t result in any objections, so I thought it was time to see what the SE mailing list thought.</p>
<p>I’ve read a few conversations on SE mailing list that have morphed into abstract conversations about dynamic vs static dispatch. I want to focus specifically on how Swift NSObject subclasses behave.</p>
<p>I think that there are 2 changes that will result in fewer bugs and
will not have a substantial impact on performance:</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161212/029441.html">continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/NeoNacho/status/808775176863313920">“What is a software engineer’s job?”</a> #yatusabes</p>
Issue #49
https://swiftweeklybrief.com/issue-49
2016-12-08T00:00:00-08:00
2016-12-08T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue 49! As of December 3, Swift has been <a href="https://twitter.com/clattner_llvm/status/805076141157404672">open source for 1 full year</a>. 😱 🎂 Can you believe it? I’m not sure if it is harder to believe that this was Swift’s <em>first year</em> of open source development, or that it has <em>only been 1 year</em>. Congrats to the Core Team, contributors, and community!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3281">SR-3181</a>: [Compiler, Docs] The Swift man page is woefully out of date.</li>
<li><a href="https://bugs.swift.org/browse/SR-3254">SR-3254</a>: [Compiler] Diagnostics are unhelpful/confusing for compound function name references.</li>
<li><a href="https://bugs.swift.org/browse/SR-3207">SR-3207</a>: [Compiler] Segmentation fault with Objective-C parameter of type <code class="language-plaintext highlighter-rouge">(NSError* __autoreleasing __nonnull * __nullable)</code></li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ole Begemann wrote an article on <a href="https://oleb.net/blog/2016/11/rawrepresentable/"><em>The RawRepresentable Protocol in Swift</em></a>. If you didn’t know, <code class="language-plaintext highlighter-rouge">RawRepresentable</code> isn’t limited to only <code class="language-plaintext highlighter-rouge">enum</code> types! Great read.</p>
<p>Brian King wrote about <a href="https://www.raizlabs.com/dev/2016/12/swift-method-dispatch/">method dispatch in Swift</a>. Chris Lattner <a href="https://twitter.com/clattner_llvm/status/806564802290008064">summarized</a> the article well: <em>“A very thorough summary of how method dispatch works in various parts of Swift.”</em></p>
<h3 id="swift-server-work-group">Swift server work group</h3>
<p>Chris Bailey posted the agendas for the first <a href="https://github.com/swift-server/work-group/pull/56">HTTP stream meeting</a> and the first <a href="https://github.com/swift-server/work-group/pull/57">Security stream meeting</a>. The meetings are taking place on December 12 and 14, respectively. Note that Chris has to coordinate these meetings among stakeholders in central Europe, the UK, east coast US, and west coast US. That feat alone deserves some kind of award. 😄</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/5778">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>: <em>Adding a Build Configuration Import Test</em>.</p>
<p>David Jones <a href="https://github.com/apple/swift-corelibs-foundation/pull/723">further improved</a> the performance of JSON serialization on Linux in corelibs-foundation. It looks like improvements range from 1.2-2.2x speed ups.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/6069">continued</a> his factoring of the AST from <a href="/issue-48/">last week</a>, this time completely removing <code class="language-plaintext highlighter-rouge">SubstitutedType</code>. <em>“Swift.swiftmodule is 670KB smaller now.”</em> 🎉</p>
<p>Xi Ge fixed a few IDE crashers: <a href="https://github.com/apple/swift/pull/6079">016</a>, <a href="https://github.com/apple/swift/pull/6084">091</a>, <a href="https://github.com/apple/swift/pull/6077">012</a>.</p>
<p>Boris Bügling <a href="https://github.com/apple/swift-llbuild/pull/42">added support</a> for build cancellation in swift-llbuild.</p>
<h3 id="accepted-proposals">Accepted Proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md">SE-0145</a>: <em>Package Manager Version Pinning</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-December/000302.html">accepted</a>.</p>
<blockquote>
<p>This was a revision of a previous proposal, and the feedback to this revised version was generally positive. Most of the feedback and discussion was about what the workflow and default behavior should be for various use cases. There was also some feedback about the name (“pinning” vs “locking”), and feedback that the proposed new JSON file be formatted in a way that is easily diffable. There seemed to be broad agreement that the underlying feature being proposed is a good and important improvement.</p>
<p>Thank you to Daniel Dunbar for writing this proposal and driving this discussion forward.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0147-move-unsafe-initialize-from.md">SE-0147</a>: <em>Move <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer.initialize(from:)</code> to <code class="language-plaintext highlighter-rouge">UnsafeMutableBufferPointer</code></em> by Ben Cohen is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-December/000304.html">under review</a>.</p>
<blockquote>
<p>The version of <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer.initialize(from:)</code> that takes a <code class="language-plaintext highlighter-rouge">Collection</code> should be deprecated in favor of a new method on <code class="language-plaintext highlighter-rouge">UnsafeMutableBufferPointer</code> that takes a <code class="language-plaintext highlighter-rouge">Sequence</code>, with a goal of improving memory safety and enabling faster initialization of memory from sequences. Similarly, <code class="language-plaintext highlighter-rouge">UnsafeMutableRawPointer.initializeMemory(as:from:)</code> should be deprecated in favour of a new <code class="language-plaintext highlighter-rouge">UnsafeMutableRawBufferPointer.initialize(as:from:)</code>.</p>
<p><code class="language-plaintext highlighter-rouge">UnsafeMutablePointer.initialize(from:)</code> underpins implementations of collections, such as <code class="language-plaintext highlighter-rouge">Array</code>, which are backed by a buffer of contiguous memory. When operations like <code class="language-plaintext highlighter-rouge">Array.append</code> are implemented, they first ensure their backing store can accommodate the number of elements in a source collection, then pass that collection into the <code class="language-plaintext highlighter-rouge">initialize</code> method of their backing store.</p>
<p>Unfortunately there is a major flaw in this design: a collection’s <code class="language-plaintext highlighter-rouge">count</code> might not accurately reflect the number of elements returned by its iterator. For example, some collections can be misused to return different results on each pass. Or a collection could just be implemented incorrectly.</p>
<p>If the collection’s <code class="language-plaintext highlighter-rouge">count</code> ends up being lower than the actual number of elements yielded by its iterator, the caller may not allocate enough memory for them. Since <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer.initialize(from:)</code> does not receive a limiting capacity, this method would then scribble past the end of the buffer, resulting in undefined behaviour.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ankit Aggarwal <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20161205/000780.html">announced</a> new features in SwiftPM.</p>
<blockquote>
<p>SwiftPM has a brand new dependency resolver. It was hidden behind a flag (<code class="language-plaintext highlighter-rouge">--enable-new-resolver</code>) while we developed and tested it but now it is the default resolver, starting from snapshots released on December 7, 2016. It is worth noting that, dependencies are no longer cloned into <code class="language-plaintext highlighter-rouge">Packages/</code> directory, they will be cloned into the build directory (but that is an implementation detail as mentioned in the editable packages proposal). This means you can remove this directory when using the new resolver.</p>
<p>SwiftPM has two new major features built on top of the new resolver:</p>
<ul>
<li><a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#editable-packages">Editable Packages</a></li>
<li><a href="https://github.com/apple/swift-package-manager/blob/master/Documentation/Usage.md#package-pinning">Version Pinning</a></li>
</ul>
<p><a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20161205/000780.html">continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ashfurrow/status/805849576603140096">When I change 1 line in a unit test…</a> 😄</p>
Issue #48
https://swiftweeklybrief.com/issue-48
2016-12-01T00:00:00-08:00
2016-12-01T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome back to the weekly! There was definitely some quiet time during the holidays in the US, but the repos are back to buzzing with activity.</p>
<!--excerpt-->
<h3 id="news-and-community">News and community</h3>
<p>There’s a new <a href="https://github.com/swift-server">swift-server</a> organization on GitHub for the <a href="https://swift.org/server-apis/">Server APIs Project</a>. There’s currently only one repository, <a href="https://github.com/swift-server/work-group">work-group</a>, which contains <a href="https://github.com/swift-server/work-group/tree/master/meetings">meeting notes</a> for the various sub-teams — HTTP, networking, and security.</p>
<p>Greg Heo wrote two great articles about two of the types in standard library: <a href="https://swiftunboxed.com/open-source/CollectionOfOne/"><em>CollectionOfOne</em></a> and <a href="https://swiftunboxed.com/open-source/IteratorOverOne/"><em>IteratorOverOne</em></a>. Each post dives into the implementation details of the types, explaining each piece one by one. (See what I did there? 😄)</p>
<p>This isn’t new, but I just discovered Alex Blewitt’s open source project, <a href="https://github.com/alblue/SILInspector">SILInspector</a> — <em>An application for experimenting with Swift’s Intermediate Language</em>. This might be interesting for you if you want to learn more about SIL.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/5935">completed</a> some major refactoring work regarding function types in the AST. The <code class="language-plaintext highlighter-rouge">PolymorphicFunctionType</code> class was removed and subsumed by <code class="language-plaintext highlighter-rouge">GenericFunctionType</code>. This work, <a href="https://twitter.com/slava_pestov/status/802942139873173504">the culmination of two years chipping away at technical debt in Swift generics</a>, resolved a 2013 FIXME. That code was so old, it could have been written on a newly updated Mac Pro. 😉</p>
<p>Alex Blewitt opened a <a href="https://github.com/apple/swift/pull/5903">pull request</a> to enable SourceKit building by default on Linux. More details are providing in <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161121/003554.html">this email</a> sent to swift-dev.</p>
<p>Hugh Bellamy <a href="https://github.com/apple/swift/pull/5904">added support</a> for building Swift on Windows with <a href="https://en.wikipedia.org/wiki/Visual_C%2B%2B">MSVC</a>. There are corresponding pull requests on <a href="https://github.com/apple/swift-clang/pull/45">swift-clang</a> and <a href="https://github.com/apple/swift-llvm/pull/33">swift-llvm</a>. All 3 pull requests require merging in order for Swift to build successfully on Windows.</p>
<p>Roman Levenstein <a href="https://github.com/apple/swift/pull/5979">reduced</a> the compiler memory usage during the LLVM code-generation and optimization phases by roughly by 15-20 percent.</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/823">added</a> performance tests to SwiftPM for “real world” packages, <a href="https://github.com/apple/swift-package-manager/pull/823/files#diff-3e7409122da942c39a66fc6b6a6dba7bR124">including</a> Kitura, Zewo, Perfect, and SourceKitten.</p>
<p>Ben Ng <a href="https://github.com/apple/swift/pull/5978">submitted</a> changes to the SILOptimizer to improve the performance of appending to <code class="language-plaintext highlighter-rouge">Array</code>. <em>“This makes <code class="language-plaintext highlighter-rouge">myArray += [42]</code> equivalent to <code class="language-plaintext highlighter-rouge">myArray.append(42)</code>, which results in a 6x speedup.”</em></p>
<p>Alex Blewitt <a href="https://github.com/apple/swift-corelibs-foundation/pull/727">implemented</a> the remaining parts of <code class="language-plaintext highlighter-rouge">NSDecimal</code> and <code class="language-plaintext highlighter-rouge">NSDecimalNumber</code> in corelibs-foundation.</p>
<p>Chris Bailey has <a href="https://github.com/swift-server/work-group/pull/52">posted the meeting minutes</a> from the Swift Server Work Group HTTP kick-off meeting.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md">SE-0143</a>: <em>Conditional conformances</em> by Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-November/000295.html">was accepted</a>.</p>
<blockquote>
<p>The proposal has been accepted for Swift 4 phase 1. Reception was almost unanimously positive, and while there was valid discussion and concern about the limitations of the initial model as proposed and its impact on the future direction of Swift’s generics model, the core team agrees that this is an independently useful and valuable expansion of the generics model that leaves the door open to future elaboration. Thank you Doug for writing and revising the proposal, and thank you to everyone who participated in its review!</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0146-package-manager-product-definitions.md">SE-0146</a>: <em>Package Manager Product Definitions</em> by Anders Bertelrud was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-November/000296.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-November/000298.html">accepted</a>.</p>
<blockquote>
<p>The proposal received no feedback, but as the core team already agreed it is the right direction we will move forward with accepting and implementing it.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md">SE-0145</a>: <em>Package Manager Version Pinning</em> was revised and is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-November/000297.html">under review again</a>.</p>
<blockquote>
<p>This is a proposal for adding package manager features to “pin” or “lock” package dependencies to particular versions.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p><a href="https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20161114/003982.html">From Jordan Rose</a> on a thread about conditional conformance to protocols:</p>
<blockquote>
<p>Rule of thumb: overloads are resolved statically, protocol requirements are invoked dynamically. You cannot get dynamic behavior out of just overloads, ever.</p>
</blockquote>
<p>Brian Gesiak <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161128/003567.html">started a thread</a> about modifying Swift’s build system to enable/disable Objective-C inter-op for any platform, which would allow Objective-C inter-op on non-Apple platforms.</p>
<blockquote>
<p>Over the weekend I learned of the <a href="https://mulle-objc.github.io">mulle-objc project</a>. It boasts an Objective-C compiler and
runtime that works on Linux.</p>
<p>Now, I don’t know if Swift’s Objective-C inter-op will work completely with mulle-objc, but I did a bit of experimenting over the weekend, and it seems possible. But one obstacle is the fact that the Swift build system conflates “an Apple target” with “capable of Objective-C inter-op.” To even start working with mulle-objc, I had to remove a lot of <code class="language-plaintext highlighter-rouge">#ifdef __APPLE__</code> in the code.</p>
</blockquote>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161128/003585.html">replied</a>:</p>
<blockquote>
<p>To be clear, I didn’t mean to discourage you (or anyone else watching) from adding support for non-Apple Objective-C platforms; I only wanted to make it clear that it almost definitely won’t Just Work by trying to compile the existing code for a non-Apple target. Like John said, we should leverage higher-level interfaces in Clang’s CodeGen to emit ObjC metadata; right now, we hardcode the Apple layouts of everything.</p>
</blockquote>
<p><a href="https://twitter.com/modocache/status/804003571897368576">Weekend project, anyone?</a></p>
<p>Nate Cook <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161128/029095.html">pitched an idea</a> for a proposal, <em>Normalize Slice Types for Unsafe Buffers</em>.</p>
<blockquote>
<p>Hello all — This is a proposal for a fairly minor change in slicing behavior for unsafe buffers.</p>
<p>This proposal changes Swift’s typed <code class="language-plaintext highlighter-rouge">UnsafeBufferPointer</code> types to be their own slice type, like the <code class="language-plaintext highlighter-rouge">UnsafeRawBufferPointer</code> types. This is a minor change in the subscript API of <code class="language-plaintext highlighter-rouge">UnsafeBufferPointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutableBufferPointer</code>, but constitutes a change to the standard library’s ABI, as it can’t be solved through type aliasing.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/dgregor79/status/804026200863739904">only in Silicon Valley</a>.</p>
Issue #47
https://swiftweeklybrief.com/issue-47
2016-11-17T00:00:00-08:00
2016-11-17T00:00:00-08:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>In this brief, a lot of <code class="language-plaintext highlighter-rouge">swiftc</code> crashes have been either fixed or identified, we discuss some proposals that are not yet in scope for Swift 4 Stage 1, and… well, let’s not spoil everything, shall we?</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3174">SR-3174</a>: The <code class="language-plaintext highlighter-rouge">#selector</code> keyword gets confused by local variable names. A simple fix for this is to search for selectors after popping out of the local scope.</li>
<li><a href="https://bugs.swift.org/browse/SR-3175">SR-3175</a>: The Swift “driver” is the program that runs when you invoke <code class="language-plaintext highlighter-rouge">swift</code> or <code class="language-plaintext highlighter-rouge">swiftc</code> on the command line. Its primary responsibility is to divide up work into several subprocesses (in parallel where possible). If one of these subprocesses terminates due to an exception, it would be helpful if the driver printed the signal number.</li>
<li><a href="https://bugs.swift.org/browse/SR-3207">SR-3207</a>: Compilers should provide helpful errors, but they should never crash. With a little bit of C++, you can prevent a crash when Swift imports Objective-C code with incorrect nullability attributes, and instead a surface an error: “hey buddy, you can’t have a pointer be both <code class="language-plaintext highlighter-rouge">nonnull</code> <em>and</em> <code class="language-plaintext highlighter-rouge">nullable</code>.”</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Jacob Bandes-Storch <a href="https://github.com/apple/swift-evolution/pull/558">added support</a> to mark proposals as “in progress” on the <a href="http://apple.github.io/swift-evolution/">Swift-Evolution proposal status site</a>.</p>
<p>Slava Pestov opened a <a href="https://github.com/apple/swift/pull/5732">pull request</a> with fixes for reflection. <em>“This PR fixes two problems with the reflection library’s type lowering; enums without payloads would mess up layout of subsequent fields, and sometimes classes with superclasses had layout start at the wrong offset.”</em></p>
<p>David Jones from IBM submitted <a href="https://github.com/apple/swift-corelibs-foundation/pull/718">pull request</a> to corelibs-foundation to improve JSON serialization performance on Linux.</p>
<p>Jonathan Anderson <a href="https://github.com/apple/swift-llbuild/pull/38">added support</a> for FreeBSD in swift-llbuild.</p>
<p>Jacob Bandes-Storch fixed <a href="https://github.com/apple/swift/pull/5763">a bunch</a> of <a href="https://github.com/apple/swift/pull/5751">crashes</a> in <code class="language-plaintext highlighter-rouge">swiftc</code>.</p>
<p><strong>@practicalswift</strong> also fixed <a href="https://github.com/apple/swift/pull/5760">a <code class="language-plaintext highlighter-rouge">swiftc</code> crash</a> and identified <a href="https://github.com/apple/swift/pulls?utf8=✓&q=is%3Apr%20is%3Aclosed%20is%3Amerged%20author%3Apracticalswift%20swiftc%20">a lot</a> (!) of them. 😱</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/792">updated</a> SwiftPM to enable whole-module optimization in release mode for Xcode projects.</p>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md">SE-0145</a>: <em>Package Manager Version Pinning</em> was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161107/028758.html">returned for revision</a>.</p>
<blockquote>
<p>Thanks to everyone who participated in this review!</p>
<p>Based on the pretty universal negative feedback, we are going to reject this proposal as is, and take it back for another round of revisions.</p>
<p>Our revised plan is:</p>
<ol>
<li>
<p>To introduce an “autopin” behavior to cover the problem Paul outlined where <code class="language-plaintext highlighter-rouge">pin --all</code> effectively needs to be “sticky” for any new dependencies which come into play.</p>
</li>
<li>
<p>To make auto pinning on by default, with an explicit mechanism for projects to opt out.</p>
</li>
</ol>
</blockquote>
<p>And although there seems to not have been that much activity on the swift-evolution repository itself, check out <a href="https://github.com/apple/swift-evolution/pulls?q=is%3Apr+is%3Aopen+label%3A%22out+of+scope+for+current+release%22">this bunch of proposals</a> that have been written — but are out of scope — for Swift 4 stage 1. There are quite a lot of interesting proposals to find there! 👏</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Please don’t <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161114/028857.html">hold your breath</a> if you were expecting non-<code class="language-plaintext highlighter-rouge">@objc</code> optional methods in protocols. Chris Lattner:</p>
<blockquote>
<p>We discussed this extensively in the Swift 3 timeframe, and I believe that the consensus was “no”: optional requirements are considered an Objective-C compatibility feature.</p>
<p>I don’t recall all of the discussion, but a major one would have to be that it is highly redundant with other language features we already have, and makes the design space of Swift APIs more complicated. If Objective-C didn’t already have them, we would never consider adding them to our protocol model.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/functionalemoji">Functional Emoji</a> is an ‘artisinal bot’ that posts funny statements using emoji and common functional programming statements like <code class="language-plaintext highlighter-rouge">map</code>, <code class="language-plaintext highlighter-rouge">reduce</code> and <code class="language-plaintext highlighter-rouge">filter</code>. Some gems include:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="p">[</span><span class="n">🍻</span><span class="p">,</span><span class="n">🍈</span><span class="p">,</span><span class="n">🍯</span><span class="p">]</span><span class="o">.</span><span class="nf">reduce</span><span class="p">(</span><span class="n">eat</span><span class="p">)</span> <span class="o">=></span> <span class="p">[</span><span class="n">💩</span><span class="p">]</span>
<span class="p">[</span><span class="n">🇬🇹</span><span class="p">,</span><span class="n">🌍</span><span class="p">,</span><span class="n">🇻🇳</span><span class="p">]</span><span class="o">.</span><span class="nf">map</span><span class="p">(</span><span class="n">turn</span><span class="p">)</span> <span class="o">=></span> <span class="p">[</span><span class="n">🇭🇳</span><span class="p">,</span><span class="n">🌏</span><span class="p">,</span><span class="n">🇻🇳</span><span class="p">]</span></code></pre></figure>
Issue #46
https://swiftweeklybrief.com/issue-46
2016-11-10T00:00:00-08:00
2016-11-10T00:00:00-08:00
Brian Gesiak
https://twitter.com/modocache
https://github.com/modocache.png?size=100
modocache
<p>What’s there to say about a week like this? Might as well just talk about Swift.</p>
<p>In this brief, we discuss the 2016 LLVM Developers’ Meeting, “eager” bridging, and link to detailed instructions on how Swift contributors are testing for compile time performance.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<p>Many new Swift contributors choose to work on the Swift standard library. Last week Swift Weekly linked to Ole Begemann’s post on <a href="https://oleb.net/blog/2016/10/swift-stdlib-source/">How to Read the Swift Standard Library Source</a>. Another great resource is Russ Bishop’s talk, <a href="https://realm.io/news/slug-russ-bishop-contributing-open-source-swift-proposal/">Contributing to Swift: From Proposal to Shipped</a>.</p>
<p>This week’s starter tasks, on the other hand, focus on the Swift compiler itself. Yes, it’s written in C++, and yes, working on a compiler can be daunting. But these tasks are small, tangible improvements, many of which can be done even by someone who’s never written C++ before.</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3164">SR-3164</a>: The goal of this task is to rename <code class="language-plaintext highlighter-rouge">.swiftdeps</code> files to prevent them from being overwritten after an incremental compilation. If you know some C++, you can help make incremental compilation failures easier to diagnose! This code lives in the Swift driver, which is a great starting point, especially if you’re only just starting to learn about compilers.</li>
<li><a href="https://bugs.swift.org/browse/SR-3167">SR-3167</a>: If you name a function <code class="language-plaintext highlighter-rouge">func switch()</code>, you get an error: <code class="language-plaintext highlighter-rouge">expected identifier in function declaration</code>. The problem is that <code class="language-plaintext highlighter-rouge">switch</code> is a reserved keyword in Swift – but you’d never guess that from that error message! This task is to improve the error message.</li>
<li><a href="https://bugs.swift.org/browse/SR-3168">SR-3168</a>: The goal of this task is to provide a fix-it for the <code class="language-plaintext highlighter-rouge">'optional' can only be applied to protocol members</code> error message. Implementing it would probably take only a few short lines of C++, and you could really help someone out!</li>
</ul>
<p>Thanks to Jordan Rose for creating so many great starter tasks!</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>The 2016 Bay Area LLVM Developers’ Meeting was held on November 3rd and 4th. The event focuses on LLVM and Clang, and while none of the speakers referenced Swift specifically, many members of the Swift core team were in attendance. Expect slides from the talks to be released within a week or two. Video recordings will eventually be available as well.</p>
<p>At the meeting, discussions on moving LLVM from SVN onto Git and GitHub continued. Although it was decided that LLVM would move to GitHub, a major roadblock remains: reaching a consensus on whether to have LLVM, Clang, and the various other projects remain in separate repositories as they do today (a “multirepo” approach), or whether all the repositories should be placed in a single repository (a “monorepo”).</p>
<p>If you’re waiting for LLVM to move to GitHub before you start contributing, don’t hold your breath. In the meantime, LLVM’s <a href="http://llvm.org/docs/GettingStarted.html">Getting Started</a> and <a href="http://llvm.org/docs/Phabricator.html">Code Reviews with Phabricator</a> guides explain how to send patches to LLVM projects.</p>
<p>Chris Bieneman <a href="https://llvmdevelopersmeetingbay2016.sched.org/event/8YzZ/developing-and-shipping-clang-with-cmake">presented</a> on how migrating Clang’s build system from autoconf to CMake has benefited that project. Although the talk did not mention Swift’s build system, it’s clear that LLVM and Clang’s usage of CMake is very different from Swift’s.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Alexis Beingessner sent pull requests for eager <a href="https://github.com/apple/swift/pull/5488">array</a> and <a href="https://github.com/apple/swift/pull/5489">string</a> bridging. Currently, Objective-C’s <code class="language-plaintext highlighter-rouge">NSArray</code> and <code class="language-plaintext highlighter-rouge">NSString</code> are bridged into Swift by keeping a reference to a <code class="language-plaintext highlighter-rouge">-copy</code> of the Objective-C object, then forwarding messages to and from it. This has a performance overhead that can be eliminated by “eagerly” copying the contents of the <code class="language-plaintext highlighter-rouge">NSArray</code> or <code class="language-plaintext highlighter-rouge">NSString</code> into a Swift <code class="language-plaintext highlighter-rouge">Array</code> or <code class="language-plaintext highlighter-rouge">String</code> once, at the time that the Objective-C object is first bridged to Swift. Doug Gregor explains eager bridging <a href="https://twitter.com/dgregor79/status/796593026151944193">here</a>.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/5600">sent</a> a pull request that enables nested types within generic types. This resolves an ABI FIXME in the Swift standard library.</p>
<p>Alex Hoppen <a href="https://github.com/apple/swift/pull/5533">sent</a> a pull request to fix a regression <a href="https://bugs.swift.org/browse/SR-1976">reported</a> by Erica Sadun, in which annotating generic parameters to closures arguments as <code class="language-plaintext highlighter-rouge">inout</code> doesn’t quite work. This is an excellent example of a improvement to compiler internals that was both reported and addressed by non-Apple contributors to Swift.</p>
<p>Simon Evans <a href="https://github.com/apple/swift/pull/5394">sent</a> a pull request that would allow the Swift package manager to create static libraries on Linux.</p>
<p>David Aghassi <a href="https://github.com/apple/swift/pull/5645">sent</a> a pull request to add documentation to SourceKit’s <code class="language-plaintext highlighter-rouge">complete.open</code> request type. SourceKit is largely undocumented, and could use your help! See <a href="https://bugs.swift.org/browse/SR-2117">SR-2117</a> for details.</p>
<p>Xi Ge <a href="https://github.com/apple/swift/pull/5634">added</a> a new SourceKit request type, <code class="language-plaintext highlighter-rouge">range</code>, which provides information about a selected snippet of code.</p>
<p>Dave Abrahams <a href="https://github.com/apple/swift/pull/5640">sent</a> a pull request to improve the Emacs support files included in the Swift repository.</p>
<p>Hugh Bellamy <a href="https://github.com/apple/swift/pull/5671">sent</a> instructions on how to compile and run Swift on Windows, via Bash on Windows.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Doug Gregor’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md">SE-0143</a>, <em>Conditional conformances</em>, is back <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-November/000294.html">in review</a>.</p>
<blockquote>
<p>During the first round of review for SE-0143, there was concern about the clarity of the proposal as written, since the discussion fixated on a number of ancillary issues not intended to be core to the proposal. Doug has revised the proposal for another round of feedback, so the review period for this proposal has been extended through November 15.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Graydon Hoare <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161031/003410.html">posted</a> advice on how Swift contributors can test for compile time performance. His attachment was scrubbed from the mailing list archives, but you can read it <a href="https://gist.github.com/modocache/9805e3e8420ccfe5f49f9c932bac27d3">here</a>.</p>
<p>Brian Gesiak <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161107/003440.html">posted</a> results from running the PVS-Studio static analyzer on the Swift codebase. Based on the analyer warnings, Michael Ilseman <a href="https://github.com/apple/swift/pull/5677">removed</a> some unused method arguments.</p>
<h3 id="finally">Finally</h3>
<p><a href="https://twitter.com/Gankro/status/796520924505841669">Look</a> on my works, ye abstractions, and despair!</p>
Issue #45
https://swiftweeklybrief.com/issue-45
2016-11-03T00:00:00-07:00
2016-11-03T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Xcode 8.2 beta was <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_8.2_beta/Release_Notes_for_Xcode_8.2_beta.pdf">released</a>. <strong>It is the final release to support Swift 2.3.</strong> <a href="https://twitter.com/ayanonagon/status/793215522196168704">Good Luck</a> migrating if you haven’t yet! Other than this, Xcode 8.2 still bundles Swift 3.0.1 and the only other notable changes are SDK updates for the new MacBook Pro <a href="https://developer.apple.com/library/content/documentation/UserExperience/Conceptual/OSXHIGuidelines/AbouttheTouchBar.html">Touch Bar</a>.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-3115">SR-3115</a>: [SPM] Document swift package edit</li>
<li><a href="https://bugs.swift.org/browse/SR-2948">SR-2948</a>: [Compiler] Discarding a closure from a <code class="language-plaintext highlighter-rouge">@discardableResult</code> function results in a compile error.</li>
<li><a href="https://bugs.swift.org/browse/SR-2475">SR-2475</a>: Warn about unlabeled parameters following a variadic parameter</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="news-and-community">News and community</h3>
<p>Ole Begemann wrote an article, <a href="https://oleb.net/blog/2016/10/swift-stdlib-source/"><em>How to Read the Swift Standard Library Source</em></a>, where he explains how to checkout and build Swift, and gives tips for digging into the source. This is a great way to get started with Swift, especially if you’ve been confused by <code class="language-plaintext highlighter-rouge">.gyb</code> files.</p>
<p>Brian Gesiak wrote a post on <a href="http://modocache.io/swift-llvm-and-swift-clang">swift-llvm and swift-clang</a>, explaining why Apple released custom forks of LLVM and clang, and what they contain that the upstream repositories do not.</p>
<p>Brian Gesiak got <a href="https://twitter.com/modocache/status/792592110532853761">Swift building on CentOS</a>.</p>
<p><a href="https://scriptarian.com">Scriptarian</a> is a new Mac app that allows users to automate macOS and any AppleScript-enabled app with Swift.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><strong>@practicalswift</strong> added a number of new <a href="https://github.com/apple/swift/commit/3a9bef9d91982b59094fb32dc281ebdf19ed3a03">compiler crashers</a>, bringing to total number of unresolved crashers to 96. (5180 have been resolved.)</p>
<p>Thomas Catterall implemented <code class="language-plaintext highlighter-rouge">CustomReflectable</code> for <code class="language-plaintext highlighter-rouge">Notification</code> in corelibs-foundation.</p>
<p><strong>@airspeedswift</strong> opened a <a href="https://github.com/apple/swift/pull/5521">pull request</a> to resolve 3 ABI FIXME’s. This change collapses the two versions <code class="language-plaintext highlighter-rouge">Array.append(contentsOf:)</code>, one that takes a sequence and one that takes a collection. There’s some interesting background in the description, too.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md">SE-0145</a>: <em>Package Manager Version Pinning</em> from Daniel Dunbar, Ankit Aggarwal & Graydon Hoare is <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161031/028579.html">under review</a>.</p>
<blockquote>
<p>This is a proposal for adding package manager features to “pin” or “lock” package dependencies to particular versions.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>David Goodine <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028440.html">started a thread</a> discussing the <code class="language-plaintext highlighter-rouge">guard</code> and unwrapping syntax, specifically how it can be verbose and redundant. Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028448.html">suggested</a> a new keyword, <code class="language-plaintext highlighter-rouge">unwrap</code>, which would change <code class="language-plaintext highlighter-rouge">guard let foo = foo else { }</code> to <code class="language-plaintext highlighter-rouge">guard unwrap foo else { }</code>. Erica Sadun has drafted a proposal <a href="https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c">in this gist</a>. There’s been a lot of feedback so far, and Erica is continuing to revise the proposal.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ericasadun/status/793586066330562560">map, filter, reduce</a>. 😂</p>
Issue #44
https://swiftweeklybrief.com/issue-44
2016-10-27T00:00:00-07:00
2016-10-27T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>What a week for Swift! Swift 3.0.1 is here, but what’s more exciting is the new <a href="https://swift.org/blog/server-api-workgroup/">Server APIs Work Group</a> and <a href="https://swift.org/server-apis/">Server APIs Project</a> from Swift.org! See below for details. The Xcode 8.1 GM seed <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_8.1_GM_Seed/Release_Notes_for_Xcode_8.1_GM_Seed.pdf">was released</a>, which bundles Swift 3.0.1. There are a number of improvements in Swift 3.0.1, including <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md">SE-0138</a>, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md">SE-0139</a> and <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md">SE-0140</a>. Check the release notes for more information. Additionally, <a href="http://www.macrumors.com/2016/10/24/apple-releases-ios-10-1-with-new-portrait-mode/">iOS 10.1</a> and <a href="http://www.macrumors.com/2016/10/24/apple-releases-macos-sierra-10-12-1/">macOS Sierra 10.12.1</a> had their final releases.</p>
<p>In other news, Apple is holding a <a href="http://www.macrumors.com/2016/10/19/apple-announces-october-27th-mac-centric-event/">“Mac-centric” event</a> 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!</p>
<!--excerpt-->
<h3 id="news-and-community">News and Community</h3>
<p><a href="https://twitter.com/Chris__Bailey/">Chris Bailey</a> from IBM wrote a blog post on Swift.org announcing the new <a href="https://swift.org/blog/server-api-workgroup/">Server APIs Work Group</a>.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>The <a href="https://swift.org/server-apis/">Server APIs Project</a> 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 — think <a href="https://github.com/apple/swift-corelibs-foundation">corelibs-foundation</a>, but for the server. The <a href="https://swift.org/server-apis/#work-group">Work Group</a> is composed of a Steering Team and Stakeholders, including representatives for all of the popular Swift web frameworks — <a href="https://github.com/IBM-Swift/Kitura">IBM Kitura</a>, <a href="https://github.com/vapor/vapor">Vapor</a>, <a href="https://github.com/Zewo/Zewo">Zewo</a>, and <a href="https://github.com/PerfectlySoft/Perfect">Perfect</a>. 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 <a href="https://swift.org/server-apis/">project page</a>.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p><a href="https://github.com/eeckstein/">Erik Eckstein</a> wrote a blog post on Swift.org titled <a href="https://swift.org/blog/whole-module-optimizations/"><em>Whole-Module Optimization in Swift 3</em></a>. 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.</p>
<p>There’s a (new?) <a href="https://swift.org/migration-guide/se-0107-migrate.html">UnsafeRawPointer Migration Guide</a> on Swift.org that guides you through migrating code that uses the <code class="language-plaintext highlighter-rouge">UnsafePointer</code> APIs from Swift 2 to Swift 3.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift/commit/7519d83007443fd8092a20b700d5478a3cbeab5a">committed</a> <a href="https://github.com/apple/swift/pull/5419">a number</a> <a href="https://github.com/apple/swift/pull/5402">of diffs</a> <a href="https://github.com/apple/swift/pull/5421">to improve</a> the constraint solver by lazily creating constraints. This work prevents preallocating constraints that will be immediately simplified anyway — which should bring some decent performance improvements to the compiler.</p>
<p>In light of the rejection of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md">SE-0144</a>, Robert Widmann submitted a <a href="https://github.com/apple/swift/pull/5270">pull request</a> to disable the ability to use <code class="language-plaintext highlighter-rouge">$</code> as an identifier. It looks like Swift 3.x releases will continue to silently accept <code class="language-plaintext highlighter-rouge">$</code> as an identifier, but this will be an error in Swift 4.</p>
<p>Erik Eckstein <a href="https://github.com/apple/swift/pull/5400">fixed</a> a bug where a constructor call of an <code class="language-plaintext highlighter-rouge">open class</code> is devirtualized although the call should be done dynamically.</p>
<p><strong>@hyp</strong> <a href="https://github.com/apple/swift-clang/pull/34">patched</a> swift-clang to display an <code class="language-plaintext highlighter-rouge">objc_subclassing_restricted</code> error for Objective-C implementation declarations when appropriate.</p>
<p>Erica Sadun diligently helped to update and <a href="https://github.com/apple/swift/pull/5427">maintain</a> the Swift changelog.</p>
<p><strong>@kstaring</strong> opened a <a href="https://github.com/apple/swift/pull/4804">pull request</a> with a patch for FreeBSD compatibility.</p>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md">SE-0144</a>: <em>Allow Single Dollar Sign as a Valid Identifier</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000292.html">rejected</a>.</p>
<blockquote>
<p>The majority of the feedback on this proposal was opposed to it, because it makes the Swift language complex for a single library. While it is unfortunate that this library is out in the wild and that there are some users, it was never intended for a single dollar sign to be allowed as an identifier, and it was also never documented as such. The core team believes that Swift 3 compatibility mode will be able to cleanly handle compatibility issues implied by not accepting this proposal.</p>
<p>Thank you to Ankur Patel for raising this proposal: it was important to get proper community discussion and feedback on this topic.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>There’s a new mailing list! The <a href="https://lists.swift.org/mailman/listinfo/swift-server-dev">swift-server-dev</a> 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 <a href="https://lists.swift.org/pipermail/swift-server-dev/Week-of-Mon-20161024/000000.html">inaugural email</a>.</p>
<blockquote>
<p>[…] 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.</p>
</blockquote>
<p>Ted Kremenek also <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000293.html">announced</a> the Server APIs Project on swift-evolution-announce.</p>
<blockquote>
<p>[…] 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. […]</p>
<p>Thanks so much to Chris Bailey for driving much of the effort to organize the work group.</p>
</blockquote>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028371.html">pitched an idea</a> on reimagining <code class="language-plaintext highlighter-rouge">guard case</code> and <code class="language-plaintext highlighter-rouge">if case</code>. She proposed the following, simpler syntax using the pattern matching (<code class="language-plaintext highlighter-rouge">~=</code>) operator:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Current (confusing)</span>
<span class="k">if</span> <span class="k">case</span> <span class="n">range</span> <span class="o">=</span> <span class="n">myValue</span> <span class="p">{</span>
<span class="c1">// ...</span>
<span class="p">}</span>
<span class="c1">// Proposed (simpler)</span>
<span class="k">if</span> <span class="n">range</span> <span class="o">~=</span> <span class="n">myValue</span> <span class="p">{</span>
<span class="c1">// ...</span>
<span class="p">}</span></code></pre></figure>
<p>Jacob Bandes-Storch <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161017/028174.html">shared a draft proposal</a> on <em>Refining Identifier and Operator Symbology</em> 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.</p>
<blockquote>
<p>This proposal seeks to refine and rationalize Swift’s identifier and operator symbology.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — the <a href="https://twitter.com/ericasadun/status/790789759874404352">Swift philosophy</a>. 💩 (original email <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028390.html">here</a>.)</p>
Issue #43
https://swiftweeklybrief.com/issue-43
2016-10-20T00:00:00-07:00
2016-10-20T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Remember <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>? That’s the proposal that controversially introduced <code class="language-plaintext highlighter-rouge">fileprivate</code>. However, if you’re regretting this change (like me), then you might have another chance to be heard! See the mailing list discussion in this issue for details. This issue also covers “id-as-Any” and continues the on-going discussion about what should be considered a source-breaking change.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2960">SR-2960</a>: Better Document <code class="language-plaintext highlighter-rouge">utils/run-test</code>. Neither <code class="language-plaintext highlighter-rouge">build-script -h</code> nor <code class="language-plaintext highlighter-rouge">docs/Testing.rst</code> mention the existence of <code class="language-plaintext highlighter-rouge">utils/run-test</code>, but they should. This is the best way to run a subset of the tests, and a huge quality-of-life improvement for working on the compiler or standard library.</li>
<li><a href="https://bugs.swift.org/browse/SR-2948">SR-2948</a>: Discarding a closure from a <code class="language-plaintext highlighter-rouge">@discardableResult</code> function results in a compile error. A function marked with <code class="language-plaintext highlighter-rouge">@discardableResult</code> should not be a compiler error if its returning closure is not used.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="community">Community</h3>
<p>There’s a new post — <a href="https://developer.apple.com/swift/blog/?id=39"><em>Objective-C id as Swift Any</em></a> — on the official Apple Developer Swift blog. It clearly explains the changes in Swift 3.0 regarding Objective-C <code class="language-plaintext highlighter-rouge">id</code> importing into Swift as <code class="language-plaintext highlighter-rouge">Any</code> instead of <code class="language-plaintext highlighter-rouge">AnyObject</code>. If you’ve been confused about this, the post should clear things up!</p>
<p>If you are contributing to or interested in LLVM, the <a href="http://llvm.org/devmtg/2016-11/">LLVM Developers’ Meeting</a> is coming up on November 3-4.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Rintaro Ishizaki has submitted a <a href="https://github.com/apple/swift/pull/5290">pull request</a> to fix <a href="https://bugs.swift.org/browse/SR-2843">SR-2843</a>. The theme of “is this a source-breaking change” returns!</p>
<blockquote>
<p>In type parsing, <code class="language-plaintext highlighter-rouge">P1 & P2.Type</code> was parsed as <code class="language-plaintext highlighter-rouge">(metatype (composition P1 & P2))</code> and accepted.
On the other hand, in expression position, <code class="language-plaintext highlighter-rouge">(P1 & P2.Type).self</code> was converted to just <code class="language-plaintext highlighter-rouge">P1</code> (<code class="language-plaintext highlighter-rouge">P2.Type</code> was silently discarded).
This PR fixes this problem, while keeping <em>source compatibility</em> to the current behavior.
That said, expr:<code class="language-plaintext highlighter-rouge">(P1 & P2.Type).self</code> as type:<code class="language-plaintext highlighter-rouge">P1</code> is just a bug. IMO, no need to keep this behavior.</p>
</blockquote>
<p>DougGregor <a href="https://github.com/apple/swift/pull/5374">fixed</a> an unintentional source-breaking change from Swift 3 regarding implicitly-unwrapped optionals and type inference.</p>
<p>Back in June, Austin Zheng <a href="https://github.com/apple/swift/pull/3046">rewrote</a> native hashed collection indices, refactoring <code class="language-plaintext highlighter-rouge">Dictionary</code> and <code class="language-plaintext highlighter-rouge">Set</code>. This week, Alexis Beingessner took over and <a href="https://github.com/apple/swift/pull/5291">rebased</a> the pull request and resolved conflicts. Despite some behavior differences and possible bridging performance regressions, it looks like the changes bring a lot of structural improvements to the code.</p>
<p>Greg Parker submitted a <a href="https://github.com/apple/swift/pull/5282">pull request</a> for a new reference count representation (work-in-progress). Based on the <a href="https://github.com/apple/swift/pull/5282#issuecomment-253705039">benchmarks</a> noted by <strong>@swift-ci</strong>, there seem to be quite a few regressions — but I’m sure these will be fixed before merging!</p>
<p>Dave Abrahams made a <a href="https://github.com/apple/swift/pull/5267">small tweak</a> to (hopefully) speed up <code class="language-plaintext highlighter-rouge">Set</code>/<code class="language-plaintext highlighter-rouge">Dictionary</code> initialization from a <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
<p>Doug Coleman opened a <a href="https://github.com/apple/swift/pull/5048">pull request</a> to make the <code class="language-plaintext highlighter-rouge">utils/update-checkout</code> python script run in parallel. 😎 This should be useful for contributors.</p>
<p>From this week’s <a href="http://llvmweekly.org/issue/146">LLVM weekly</a>, a <a href="https://reviews.llvm.org/rL284077">lengthy proposal</a> on moving LLVM to GitHub was added. As mentioned before, having all of these projects on GitHub could be beneficial to Swift contributors, and possibly lower the barrier to getting involved with LLVM.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0144-allow-single-dollar-sign-as-valid-identifier.md">SE-0144</a>: <em>Allow Single Dollar Sign as a Valid Identifier</em> by Ankur Patel is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000291.html">under review</a>. As discussed <a href="/issue-42/">last issue</a>, Ankur is the author of <a href="https://github.com/ankurp/Dollar">Dollar.swift</a> which would break after a <a href="https://github.com/apple/swift/pull/3901">recent fix</a> in the compiler.</p>
<blockquote>
<p>The mainline Swift compiler emits an error message when the <code class="language-plaintext highlighter-rouge">$</code> character (U+0024) is used as an identifier by itself, which is a source breaking change from Swift 3.0.</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">let</span> <span class="err">$</span> <span class="o">=</span> <span class="mi">10</span>
<span class="c1">// OR</span>
<span class="kd">let</span> <span class="err">$</span> <span class="p">:</span> <span class="p">(</span><span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="p">(</span><span class="kt">Int</span><span class="p">)</span> <span class="o">=</span> <span class="p">{</span> <span class="nv">$0</span> <span class="o">*</span> <span class="nv">$0</span> <span class="p">}</span>
<span class="c1">// OR</span>
<span class="kd">class</span> <span class="err">$</span> <span class="p">{}</span></code></pre></figure>
<blockquote>
<p>This proposal suggests reverting this change, enabling the use of <code class="language-plaintext highlighter-rouge">$</code> as a valid identifier in future versions of Swift (>= 3.1).</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ankit Aggarwal <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/027945.html">asked for feedback</a> on a draft proposal for version pinning in SwiftPM.</p>
<p>The other week, David Hart <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027632.html">started a discussion</a> about <code class="language-plaintext highlighter-rouge">private</code> and <code class="language-plaintext highlighter-rouge">fileprivate</code> from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Access Level</em>, asking if “this ship has sailed” or not. As expected, the email elicited many responses from the community. Like David and Russ, I agree that this proposal was a mistake — in practice, using <code class="language-plaintext highlighter-rouge">fileprivate</code> feels cumbersome and too complex. I find extremely little value in <code class="language-plaintext highlighter-rouge">private</code>. In particular, these new access levels make type extensions more burdensome to implement since an <code class="language-plaintext highlighter-rouge">extension</code> cannot access <code class="language-plaintext highlighter-rouge">private</code> members. If the community is willing to put forth a detailed proposal with significant evidence to support that reverting SE-0025 would be best, it sounds like the Core Team will review it. As Lattner notes below, this would require a “pretty high burden of proof.” In any case, this discussion can be deferred until Spring — after Swift 4 Phase 1 is completed.</p>
<p>From <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027647.html">David Hart</a>:</p>
<blockquote>
<p>[…] I instead want to share my experience using <code class="language-plaintext highlighter-rouge">private</code> and <code class="language-plaintext highlighter-rouge">fileprivate</code> since release. Here are my thoughts:</p>
<p>We should start with the premise that the proposal has added a substantial amount of complexity:</p>
<p>It has added an extra modifier and access level to learn.
It has complicated the access level rules with Inner types as mentioned in the Complications with private types section of the proposal.
I have seen many people (twitter, work, slack) be confused about the difference between <code class="language-plaintext highlighter-rouge">private</code> and <code class="language-plaintext highlighter-rouge">fileprivate</code> at the global level. The answer is none, which shows that both modifiers are not very orthogonal.
Since release, I saw people prefer one over the other, as a matter of style. They tend to always use <code class="language-plaintext highlighter-rouge">fileprivate</code> or always using <code class="language-plaintext highlighter-rouge">private</code>. In the latter case, functions and properties get clumped in the same class scope instead of be written through multiple extensions.</p>
<p>I have the impression that the motivations for the proposal are much less real in practice:</p>
<p>The first motivation stated is: “It is not clear whether the implementation details are meant to be completely hidden or can be shared with some related code without the danger of misusing the APIs marked as <code class="language-plaintext highlighter-rouge">private</code>.” I’ve found that to be fairly rare in practice because the implementation details only used to leak inside the same file, which greatly reduces the dangers.
The second motivation stated is: “It forces a one class per file structure, which is very limiting.” First of all, this is partly false. I think it forces putting classes which share implementation details in the same file, which I don’t think is necessarily a bad thing.</p>
<p>To summarise, it seems that the confusion the proposal brought over semantics and style are not worth the limited benefits that it brought. I’d be tempted to backtrack the proposal and re-introduce <code class="language-plaintext highlighter-rouge">private</code> as a file scoped access-level and deprecate <code class="language-plaintext highlighter-rouge">fileprivate</code>.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027659.html">Russ Bishop</a>:</p>
<blockquote>
<p>I agree. The minor benefit that <code class="language-plaintext highlighter-rouge">fileprivate</code> brings is not worth the cognitive overhead it introduces. We should just admit it was a mistake and back it out. We can avoid source-breaking changes by making <code class="language-plaintext highlighter-rouge">fileprivate</code> a synonym for private and provide fixits/warnings for a release to give people a chance to move off it.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/027756.html">Doug Gregor</a>:</p>
<blockquote>
<p>[…] This proposal has been litigated numerous times already, and the bar for source-breaking changes is much higher now. To effectively re-open the discussion would require a proposal that significantly changes the model with a lot of evidence that such a new model is a drastic improvement over what we have now. “Back out SE-0025” is not a viable option now.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/027786.html">David Waite</a>:</p>
<blockquote>
<p>[…] I’m convinced as the Swift language and other Swift-based projects both gain more maturity, we will be able to get a holistic view of how access control should work and how it should correlate to project structure. Before then, any change may simply do more harm than good.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161010/027912.html">Chris Lattner</a>:</p>
<blockquote>
<p>Not speaking for the core team, just MHO:</p>
<p>I agree with Russ here, and with others who have said upthread that the “thing that has changed” is that we are starting to get usage experience with <code class="language-plaintext highlighter-rouge">fileprivate</code> vs <code class="language-plaintext highlighter-rouge">private</code>. I think we all understand the value of having fewer access control levels, and so if “private” isn’t conceptually pulling its weight, then it is reasonable to consider phasing it out.</p>
<p>That said, there is no specific rush to have this discussion, and I think it is reasonable to put a pretty high burden of proof on someone who wants to drive such a proposal. For example, if we had the discussion in the spring timeframe, we should have a pretty large body of Swift 3 code readily at hand (e.g. SwiftPM packages and other various github repos).</p>
<p>Given that, it should be easy enough to see how widely <code class="language-plaintext highlighter-rouge">private</code> is actually being used in practice. If it is very rare, then the argument to ditch it (make it a synonym for <code class="language-plaintext highlighter-rouge">fileprivate</code>, and eventually phasing out <code class="language-plaintext highlighter-rouge">fileprivate</code>) is strong. If lots of people are using <code class="language-plaintext highlighter-rouge">private</code> and only some are using <code class="language-plaintext highlighter-rouge">fileprivate</code>, then the discussion is quite different.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ayanonagon/status/788851043870269441">tabs or spaces</a>? 😄</p>
Issue #42
https://swiftweeklybrief.com/issue-42
2016-10-13T00:00:00-07:00
2016-10-13T00:00:00-07:00
Bas Broek
https://twitter.com/BasThomas
https://github.com/BasThomas.png?size=100
BasThomas
<p>Swift 3? You mean Swift 4? Apple has further outlined their plans on the next version of Swift. And as a reminder, Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000269.html">explained</a> back in July what’s in store for Swift 4 and its release plan. Forwards!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2902">SR-2902</a>: [Compiler] Add a timer and debug flag for expression type checking. (Thanks <a href="https://twitter.com/benasher44/status/785192508158377984">Ben Asher</a>!)</li>
<li><a href="https://bugs.swift.org/browse/SR-2910">SR-2910</a>: [Compiler] Log property name for synthesized properties in <code class="language-plaintext highlighter-rouge">-debug-time-function-bodies</code> output (Thanks <a href="https://twitter.com/benasher44/status/785578563084791808">Ben Asher</a>!)</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="community">Community</h3>
<p>Brian Gesiak followed up his <a href="http://modocache.io/how-to-port-the-swift-runtime-to-android">previous post</a> on porting the Swift runtime to Android with Part 2 — <a href="http://modocache.io/swift-on-android-now"><em>Swift on Android, Part Two: Now What?</em></a> This post discusses the implications for mobile developers.</p>
<p>Ole Begemann wrote a great post on <a href="https://oleb.net/blog/2016/10/optional-non-escaping-closures/"><em>Optional Non-Escaping Closures</em></a>. In Swift 3, non-escaping closure are the default. If you are still confused about how/when to use <code class="language-plaintext highlighter-rouge">@escaping</code>, this is a great read. Ole also explores some finer details and gotchas.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift-evolution/pull/541">updated</a> the swift-evolution repository for Swift 4 stage 1. 🎉 Swift 4.0’s expected release date is <em>late 2017</em>, so mark your calendars!</p>
<p>Michael Ilseman <a href="https://github.com/apple/swift/commit/12fb0bad7b00337c8a28eb9e0afd4b64e3ddfadc">committed</a> changes to allow Swift version compatibility checking for source-breaking changes. The recent <a href="https://github.com/apple/swift/pull/4878">change</a> to <code class="language-plaintext highlighter-rouge">@escaping</code> on variadic arguments is the first change to need specific Swift 3.0 compatibility.</p>
<p>As Brian Gesiak mentioned in <a href="/issue-39/">issue #39</a>, source-breaking changes really are hard to <a href="https://github.com/apple/swift/pull/4878#issuecomment-252695257">determine</a>. It turns out that Slava’s changes to variadic parameters <a href="https://bugs.swift.org/browse/SR-2907">were actually breaking</a>.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/3901">merged</a> changes to reject standalone <code class="language-plaintext highlighter-rouge">$</code> as identifiers, which were accidentally accepted as valid. Chris Lattner <a href="https://github.com/apple/swift/pull/3901#issuecomment-253119293">pointed out</a> that this is a source-breaking change (another!) — particularly for <a href="https://github.com/ankurp/Dollar">Dollar</a>, a Swift library by Ankur Patel. The fixit for this <a href="https://github.com/apple/swift/pull/3901#issuecomment-253119293">was almost</a> to rewrite <code class="language-plaintext highlighter-rouge">$</code> as 💲 (dollar sign emoji). 😂</p>
<p>Roman Levenstein opened a <a href="https://github.com/apple/swift/pull/5265">pull request</a> that adds a flag to the SIL optimizer to inline generics.</p>
<p>Alex Blewitt continued <a href="https://github.com/apple/swift-corelibs-foundation/pull/659">making progress</a> on implementing <code class="language-plaintext highlighter-rouge">NSDecimal</code> in swift-corelibs-foundation.</p>
<p>Swift 3.0.1 <a href="https://github.com/apple/swift/releases/tag/swift-3.0.1-PREVIEW-3">Preview 3</a> was released!</p>
<h3 id="proposals">Proposals</h3>
<p>No new proposals this week, but the <a href="http://apple.github.io/swift-evolution/">status page</a> has been updated to include Swift 3.0.1, Swift 3.1, and Swift 4.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Not on the mailing lists, but on Robert Widmann’s pull request mentioned above, Jordan Rose and Chris Lattner <a href="https://github.com/apple/swift/pull/3901#issuecomment-253292871">elaborate</a> on how source-breaking changes will be handled.</p>
<blockquote>
<p>We already passed that deadline: it was 3.0. At this point source-breaking changes need to be justified and will be handled on a case-by-case basis.</p>
<p>… but the process for doing this hasn’t been decided and written up yet.</p>
</blockquote>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160926/027337.html">shed some light</a> on the future dynamic aspects of Swift. <em>“The core team is committed to adding powerful dynamic features to Swift.”</em></p>
<blockquote>
<p>The primary reason that Swift currently lacks these features is simple prioritization. It has unfortunately not been the highest priority to build, because we already have working systems for all of those in Cocoa, and things like source stability and binary stability (among other things) are more important to the Swift community in the moment. As Swift evolves, they will bubble up in the priority list.</p>
<p>I know that having a read/write data reflection API is the top of the list for many people, and having the ability to reflect on methods is also important for some patterns. I look forward to the community having the bandwidth to properly design and debate these things, because I’m confident that there are good answers for these.</p>
<p>That said, to be clear, this is definitely out of scope for Swift 4 Stage 1, which is our current mode. We need to stay focused in the short term on the most pressing issues, which revolve around Source and ABI stability.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<blockquote>
<p>We are willing to make the internal implementation of Swift complex if that means that we get a beautiful model for programmers.</p>
<p>— <a href="https://twitter.com/ericasadun/status/784528752822849536">Chris Lattner</a> 👏</p>
</blockquote>
Issue #41
https://swiftweeklybrief.com/issue-41
2016-10-06T00:00:00-07:00
2016-10-06T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue 41! Swift 4.0 development continues, and it looks like <a href="https://github.com/apple/swift/releases/tag/swift-3.0.1-PREVIEW-2">Swift 3.0.1 Preview-2</a> has landed.</p>
<!--excerpt-->
<h3 id="community">Community</h3>
<p>Brian Gesiak <a href="http://modocache.io/how-to-port-the-swift-runtime-to-android">wrote a great article</a> on how Android support came to Swift, <em>Porting the Swift Runtime to Android, Part One: The How</em>. He makes it seem so easy!</p>
<p>Apple open sourced <a href="https://github.com/apple/swift-protobuf">Swift Protobuf</a>, a plugin and runtime library for using protobuf with Swift. Note that it is currently in a <em>prerelease</em> state.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/5141">fixed</a> a bug that prevented <code class="language-plaintext highlighter-rouge">@NSManaged</code> properties from satisfying protocol requirements.</p>
<p>As mentioned in <a href="/issue-39/">Issue 39</a>, Airspeed Velocity numbered and categorized each of the FIXMEs associated with ABI stability. This week, Doug Gregor <a href="https://github.com/apple/swift/pull/5132">knocked out</a> 3 of the standard library’s FIXME’s (#35, #37, #39) by removing the <code class="language-plaintext highlighter-rouge">_AnyHashableProtocol</code> hack from initial implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md">SE-0131</a>.</p>
<p>Nate Cook made substantial <a href="https://github.com/apple/swift/pull/5083">revisions and extensions</a> to the documentation for integer types & protocols.</p>
<p>Philippe Hausler <a href="https://github.com/apple/swift/pull/5071">submitted a pull request</a> that <strong>dramatically</strong> improves <code class="language-plaintext highlighter-rouge">String</code> bridging performance for certain cases.</p>
<blockquote>
<p>When Swift strings are bridged back into Objective-C two distinct methods can be called to get fast-access to the underlying buffers of the strings. These come in two flavors - either eight-bit contents or unicode contents. When the backing of the swift string is represented as a buffer of unicode characters (an element width of 2) the fastest and smallest encoding is unicode (<code class="language-plaintext highlighter-rouge">NSUnicodeStringEncoding</code> = 10) and the buffer can be portrayed to Objective-C directly as a cast of the startUTF16 to a constant <code class="language-plaintext highlighter-rouge">unichar</code> pointer. Likewise when the backing is ASCII the buffer can be represented as an eight bit encoding (<code class="language-plaintext highlighter-rouge">NSASCIIStringEncoding</code> = 1) and the buffer can be directly accessed as a constant <code class="language-plaintext highlighter-rouge">char</code> pointer.</p>
<p>This in normal cases can improve the bridging performance in the upwards of 90% faster access in bridged cases when passing a swift string into Objective-C APIs.</p>
</blockquote>
<p>Enrico Granata <a href="https://github.com/apple/swift/pull/5133">merged</a> changes to allow demangling of methods in extensions.</p>
<p>Alex Blewitt <a href="https://github.com/apple/swift-corelibs-foundation/pull/667">added supported</a> for <code class="language-plaintext highlighter-rouge">ISO8601</code> calendars in swift-corelibs-foundation.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md">SE-0141</a>: <em>Availability by Swift version</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000289.html">accepted</a>.</p>
<blockquote>
<p>Feedback on the proposal was light but entirely positive. The proposal is accepted.</p>
</blockquote>
<p>This proposal allows to you make declarations conditionally available, depending on the version of Swift. For example, you can currently declare a class as being available only in iOS 10 and later with <code class="language-plaintext highlighter-rouge">@available(iOS 10.0, *)</code>. After this proposal, you could write <code class="language-plaintext highlighter-rouge">@available(swift, introduced: 3.1)</code> to specify that an API is only available in Swift 3.1 or later.</p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md">SE-0142</a>: <em>Permit where clauses to constrain associated types</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-October/000290.html">accepted</a>.</p>
<blockquote>
<p>Feedback on this proposal was overwhelmingly positive. The proposal is accepted.</p>
</blockquote>
<p>This proposal introduces <code class="language-plaintext highlighter-rouge">where</code> clauses for <code class="language-plaintext highlighter-rouge">associatedtype</code> declarations, bringing the same expressiveness as generic type parameters.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ben Asher <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161003/003099.html">asked for advice</a> on debugging slow compile times and shared some stats on his project. Mark Lacey <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161003/003103.html">replied</a> with <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20161003/003110.html">a few tips</a>.</p>
<blockquote>
<p>Since upgrading to Swift 3, the number of trouble function bodies has gone from > 150 to < 20, so we’re really happy about that! The only issue though is that build time overall increased by ~1 min (amount of time to build all targets before automatically merging to master in our integration build).</p>
</blockquote>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161003/027566.html">noted</a> some unintended consequences from implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md">SE-0111</a>.</p>
<blockquote>
<p>SE-0111 established that Swift’s type system would not allow function argument labels to be expressed as part of a function type. As I’ve been working with curried functions, I’m discovering an unintended consequence of this proposal in that it strips curried functions of their external labels and the resulting calls of their readability.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p><a href="https://medium.com/ios-os-x-development/is-apple-using-swift-4a6c80f74599#.upb3embbg">Is Apple using Swift in iOS</a>, yet? It looks like the iOS 10 Music app is <a href="https://twitter.com/stroughtonsmith/status/783669525594210309">mostly Swift</a>! 😎 But it looks like not much else, unfortunately.</p>
Issue #40
https://swiftweeklybrief.com/issue-40
2016-09-29T00:00:00-07:00
2016-09-29T00:00:00-07:00
Brian Gesiak
https://twitter.com/modocache
https://github.com/modocache.png?size=100
modocache
<p>With 1,653 votes, <a href="https://twitter.com/stroughtonsmith/status/780028892794978304">this</a> Twitter poll shows a majority of people building their current and future macOS/iOS apps in Swift. The poll is a good reminder that many professional app developers now rely on the Swift compiler, even as it continues to rapidly grow and change. On the one hand, that means contributors like you and I can have a positive, immediate impact on many developers. On the other hand, there’s a great deal of people who may be inconvenienced by a bug, so maintainers will need to be careful about how to vet contributions.</p>
<p>How has Swift grown this week? In this brief, we discuss conditional protocol conformances, building the Swift runtime for Android from a macOS host machine, improved diagnostics, and proposals to add compile time debugging options.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<p>Do you have experience writing Python, and want to learn more about the tools used to test Swift, Clang, and LLVM? Daniel Dunbar has <a href="https://twitter.com/daniel_dunbar/status/780436782605230080">asked</a> for help maintaining <a href="http://llvm.org/docs/CommandGuide/lit.html">lit</a>, the LLVM Integrated Tester. You can follow the <a href="http://llvm.org/docs/GettingStarted.html">LLVM Getting Started Guide</a> to download the LLVM source code. LLVM uses Phabricator for code reviews, and you can learn how to use it <a href="http://llvm.org/docs/Phabricator.html">here</a>. Brian Gesiak <a href="https://reviews.llvm.org/D24968">added</a> instructions on how to run lit’s test suite, and where to look for work to be done.</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Swift 3.0.1 Preview 1 has been <a href="https://github.com/apple/swift/releases/tag/swift-3.0.1-PREVIEW-1">released</a>.</p>
<p>Shortly after it was featured in last week’s brief, Erik Eckstein <a href="https://github.com/apple/swift/pull/4927">fixed</a> a <a href="https://bugs.swift.org/browse/SR-1901">bug</a> that forced internal Foundation and XCTest symbols to be marked as <code class="language-plaintext highlighter-rouge">public</code>. Thanks to this, Brian Gesiak was able to <a href="https://github.com/apple/swift-corelibs-xctest/pull/174">correct</a> access controls for API in XCTest.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/4933">implemented</a> the second half of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md">SE-0139</a> by bridging Swift numeric types to Objective-C <code class="language-plaintext highlighter-rouge">NSNumber</code>.</p>
<p>Andrew Trick <a href="https://github.com/apple/swift/pull/4954">implemented</a> evolution proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md">SE-0138</a>, adding <code class="language-plaintext highlighter-rouge">UnsafeRawBufferPointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeRawMutableBufferPointer</code> to the standard library.</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift/pull/4972">sent</a> a pull request that allows macOS host machines to compile the Swift runtime for Android. Previously only Linux machines could compile for Android.</p>
<p>Work continues to improve compiler diagnostics. Harlan Haskins <a href="https://github.com/apple/swift/pull/4980">fixed</a> a compiler assertion that occurred when incorrectly using <code class="language-plaintext highlighter-rouge">var</code> for type-inferred parameters in closures, such as <code class="language-plaintext highlighter-rouge">takesClosure { (var d) in d }</code>. With Harlan’s change, this now produces the error “parameters may not have the ‘var’ specifier”. Mark Lacey <a href="https://github.com/apple/swift/pull/4998">fixed</a> this confusing error message:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span><span class="p">,</span> <span class="n">_</span> <span class="nv">y</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">x</span> <span class="o">+</span> <span class="n">y</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">bar</span><span class="p">()</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span>
<span class="k">return</span> <span class="nf">foo</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="mi">5</span><span class="p">)</span> <span class="c1">// error: unnamed argument #2 must precede unnamed argument #1</span>
<span class="p">}</span></code></pre></figure>
<p>Mark’s work corrects the error message:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="nf">bar</span><span class="p">()</span> <span class="o">-></span> <span class="kt">Int</span> <span class="p">{</span>
<span class="k">return</span> <span class="nf">foo</span><span class="p">(</span><span class="mi">3</span><span class="p">,</span> <span class="mi">5</span><span class="p">)</span> <span class="c1">// error: missing argument label 'x' in call</span>
<span class="p">}</span></code></pre></figure>
<p>Dave Abrahams <a href="https://github.com/apple/swift/pull/3796">uploaded</a> a work-in-progress pull request from Maxim Moiseev that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>, protocol-oriented integers. If you’re curious what pull requests look like before they’re ready to merge, take a look!</p>
<p>@lplarson <a href="https://github.com/apple/swift/pull/4989">added</a> an option to the script used to build the Swift compiler that allows it to be built with <a href="http://clang.llvm.org/docs/UsersManual.html#profile-guided-optimization">profile guided optimization</a>. It’ll be interesting to see whether this results in improved Swift compiler performance! To learn how you can use this advanced Clang feature in your own applications, read Apple’s <a href="https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/xcode_profile_guided_optimization/pgo-using/pgo-using.html">documentation</a>.</p>
<p>Eli Perkins <a href="https://github.com/apple/swift/pull/4929">marked</a> <code class="language-plaintext highlighter-rouge">UnicodeScalar.utf16</code> and <code class="language-plaintext highlighter-rouge">UnicodeScalar.UTF16View</code> as <code class="language-plaintext highlighter-rouge">public</code>, completing one of the starter tasks introduced in last week’s brief. Despite being a “starter” task, it <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/027240.html">almost</a> turned into a Swift evolution proposal – phew!</p>
<p>Daniel Müllenborn <a href="https://github.com/apple/swift/pull/4928">added</a> a badge to the Swift README that displays the build status of Swift on Ubuntu 16.04. Swift now runs on Ubuntu 14, 15, and 16.</p>
<p>Ben Rimmington <a href="https://github.com/apple/swift-evolution/pull/534">added</a> support for proposals implemented in Swift 3.0.1 and 4.0. SE-0140 is now missing from the <a href="http://apple.github.io/swift-evolution/">site</a>, although it has already been <a href="https://github.com/apple/swift-evolution/commit/1202af531896d3e1708708ff09e4f6dd91d43f47">implemented</a>.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0141-available-by-swift-version.md">SE-0141</a>: <em>Availability by Swift version</em> from Graydon Hoare is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000286.html">under review</a>.</p>
<blockquote>
<p>Swift’s existing <code class="language-plaintext highlighter-rouge">@available(...)</code> attribute indicates the lifecycle of a given declaration, either unconditionally or relative to a particular platform or OS version range.</p>
<p>It does not currently support indicating declaration lifecycle relative to Swift language versions. This proposal seeks to extend it to do so.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md">SE-0142</a>: <em>Permit where clauses to constrain associated types</em> from David Hart, Jacob Bandes-Storch and Doug Gregor is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000287.html">under review</a>.</p>
<blockquote>
<p>This proposal seeks to introduce a <code class="language-plaintext highlighter-rouge">where</code> clause to associated type declarations and improvements to protocol constraints to bring associated types the same expressive power as generic type parameters.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0143-conditional-conformances.md">SE-0143</a>: <em>Conditional Conformances</em> from Doug Gregor, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000288.html">under review</a>. The proposal is a big part of the <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-">generics
manifesto</a>, and will likely have a large impact upon Swift code in the standard library and beyond.</p>
<blockquote>
<p>Conditional conformances express the notion that a generic type will conform to a particular protocol only when its type arguments meet certain requirements. For example, the <code class="language-plaintext highlighter-rouge">Array</code> collection can implement the <code class="language-plaintext highlighter-rouge">Equatable</code> protocol only when its elements are themselves <code class="language-plaintext highlighter-rouge">Equatable</code>, which can be expressed via the following conditional conformance on <code class="language-plaintext highlighter-rouge">Equatable</code>:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">extension</span> <span class="kt">Array</span><span class="p">:</span> <span class="kt">Equatable</span> <span class="k">where</span> <span class="kt">Element</span><span class="p">:</span> <span class="kt">Equatable</span> <span class="p">{</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="o">==</span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="kt">Array</span><span class="o"><</span><span class="kt">T</span><span class="o">></span><span class="p">,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">Array</span><span class="o"><</span><span class="kt">T</span><span class="o">></span><span class="p">)</span> <span class="o">-></span> <span class="kt">Bool</span> <span class="p">{</span> <span class="o">...</span> <span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Brian Michel <a href="https://bugs.swift.org/browse/SR-2741">proposed</a> adding options for the compiler to output structured information about compilation times.</p>
<p>Daniel Dunbar <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160919/003020.html">noticed</a> a large regression in how long it took to compile the Swift package manager source code. It appears a change in LLVM has caused the issue, but what exactly caused it has yet to be pinpointed.</p>
<h3 id="finally">Finally</h3>
<p>What’s the <a href="https://twitter.com/stephentyrone/status/781532588057976832">most Swift emoji</a> you can think of? 🤔</p>
Issue #39
https://swiftweeklybrief.com/issue-39
2016-09-22T00:00:00-07:00
2016-09-22T00:00:00-07:00
Brian Gesiak
https://twitter.com/modocache
https://github.com/modocache.png?size=100
modocache
<p>It was the Chinese philosopher Laozi who said 「千里之行,始於足下」, or “a journey of a thousand miles begins with a single step”. Oh wait, or was that Joe Groff who said that the journey to Swift 4 begins with a single pull request…?</p>
<p>In any case, with major Apple releases out of the way, the Swift repositories are buzzing with activity. This week, we cover ABI FIXME cataloging, source-breaking changes, and cross-platform developments for Android, FreeBSD, and Cygwin.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2627">SR-2627</a>: The Swift standard library’s <code class="language-plaintext highlighter-rouge">UnicodeScalar.utf16</code> does not have an access modifier, and is therefore considered <code class="language-plaintext highlighter-rouge">internal</code>. It should be marked <code class="language-plaintext highlighter-rouge">public</code>.</li>
<li><a href="https://bugs.swift.org/browse/SR-2626">SR-2626</a>: <code class="language-plaintext highlighter-rouge">String</code> to <code class="language-plaintext highlighter-rouge">Double</code> conversion fails on <code class="language-plaintext highlighter-rouge">snan</code> (signaling NaN) input. The task already has some discussion on the specifics of when exactly the converted value should signal. Some knowledge of Swift and C may be helpful in completing this task.</li>
<li><a href="https://bugs.swift.org/browse/SR-2653">SR-2653</a>: Add an option to the Swift build script to specify whether to build SourceKit. Basic knowledge of Python, shell scripting, or CMake would be helpful, but not strictly necessary.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Many private API in libdispatch, Foundation, and XCTest are currently marked <code class="language-plaintext highlighter-rouge">public</code> due to a <a href="https://bugs.swift.org/browse/SR-1901">bug</a> in SIL linkage. This week, Chris Bailey <a href="https://github.com/apple/swift-corelibs-foundation/pull/651">sent</a> a pull request to expose internal variables and methods on <code class="language-plaintext highlighter-rouge">Operation</code> as a workaround. Brian Gesiak <a href="https://github.com/apple/swift-corelibs-xctest/pull/173">sent</a> a pull request to mark internal variables as <code class="language-plaintext highlighter-rouge">final</code>, which works around the bug in some cases.</p>
<p>Airspeed Velocity <a href="https://github.com/apple/swift/pull/4868">numbered and categorized</a> each of the FIXMEs associated with ABI stability. Now you can tell your friends about the difficulty of resolving ABI FIXME #104, and they’ll know exactly which issue you’re referring to.</p>
<p>Swift and its tooling is being maintained to work on many different platforms. Han Sangjin <a href="https://github.com/apple/swift-llbuild/pull/35">fixed</a> Cygwin support in llbuild. K Staring <a href="https://github.com/apple/swift/pull/4804">sent</a> a pull request to fix FreeBSD support.</p>
<p>Several improvements have been made to Swift diagnostics’ <a href="https://github.com/apple/swift/blame/c49b171f4bad368cae289bce2acc89cbebfea823/docs/Lexicon.rst#L191-L199">QoI</a>. Jordan Rose <a href="https://github.com/apple/swift/pull/4777">added</a> a fix-it for when a trailing closure causes ambiguity as to which function will be called. Harlan Haskins <a href="https://github.com/apple/swift/pull/4683">sent</a> a pull request to improve the error diagnostics for closures that incorrectly take a <code class="language-plaintext highlighter-rouge">var</code> parameter, such as <code class="language-plaintext highlighter-rouge">myClosure { (var foo) in ... }</code>.</p>
<p>What makes a “source-breaking” change in Swift? Sometimes it’s not clear. Slava Pestov <a href="https://github.com/apple/swift/pull/4878">changed</a> variadic closure arguments to be <code class="language-plaintext highlighter-rouge">@escaping</code> by default, which is technically a source breaking change, but only for invalid code. Jordan Rose <a href="https://github.com/apple/swift/pull/4568">sent</a> a pull request to change all CoreFoundation types to conform to <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> by default. Jordan’s pull request is a source-breaking change, but only for code that’s manually extended a CoreFoundation type to conform to <code class="language-plaintext highlighter-rouge">Equatable</code> or <code class="language-plaintext highlighter-rouge">Hashable</code>. Unfortunately, some code that does just that was found on GitHub, and so his changes may be delayed until Swift 4.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/4875">fixed</a> <a href="https://bugs.swift.org/browse/SR-993">SR-993</a>, a bug in which <code class="language-plaintext highlighter-rouge">static let</code> variables defined on Objective-C class extensions would be inferred to be both <code class="language-plaintext highlighter-rouge">final</code> and <code class="language-plaintext highlighter-rouge">dynamic</code>.</p>
<p>Erik Eckstein <a href="https://github.com/apple/swift/pull/4836">added</a> new SIL instructions to support tail-allocated arrays in SIL. Maybe as a result we’ll see some improved benchmarks for appending objects to an array?</p>
<p>Graydon Hoare <a href="https://github.com/apple/swift/pull/4826">added</a> a <code class="language-plaintext highlighter-rouge">-swift-version <n></code> option. This would allow you to use a the Swift compiler released as “Swift 3.1”, but pass the option <code class="language-plaintext highlighter-rouge">-swift-version 2.2.1</code> to force it to compile code as Swift 2.2.1. Of course, there’s no guarantee that a modern Swift compiler could correctly compile Swift 2.2.1 code, but the option to force it to do so is handy.</p>
<p>Three weeks ago Daniel Dunbar <a href="https://github.com/apple/swift-package-manager/commit/b5dd8e2b3de4c818f153eba3768def42f2781ac6">added</a> a new dependency resolver to SwiftPM. This week Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/665">added</a> support for the <code class="language-plaintext highlighter-rouge">update</code> command. You can try it out yourself by building SwiftPM from source and running <code class="language-plaintext highlighter-rouge">swift package update --enable-new-resolver</code>.</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/669">fixed</a> a bug in which SwiftPM could not be built using an Xcode application that had a space in its name.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/4849">sent</a> a massive pull request to refactor code completion and module interface printing in libAST and libIDE.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/4865">sent</a> a pull request to implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md">SE-0139</a>, NSValue bridging.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Andrew Trick’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md">SE-0138</a>: <em>UnsafeRawBufferPointer</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160919/027167.html">accepted</a>.</p>
<blockquote>
<p>Community feedback to this proposal was nearly all positive. It was
pointed out that Foundation’s Data API should make use of this new type,
and there is a clear intention to do that. The core team agrees that the
proposal is a reasonable addition to make in Swift 3 because it fills in
missing functionality from SE-0107: UnsafeRawPointer and will help with
code migration. As a result of the discussion, the proposed component’s
name was changed from <code class="language-plaintext highlighter-rouge">UnsafeBytes</code> to <code class="language-plaintext highlighter-rouge">UnsafeRawBufferPointer</code>; that
change is already reflected in the proposal.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ever think you’d be able to ask <code class="language-plaintext highlighter-rouge">@swift-ci please test Android</code>? Well, Apple is considering additional CI platforms, including one for Android. Brian Gesiak <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160919/002952.html">sent an email</a> with a summary of the approach being considered, as well as an offer of additional resources to make it happen.</p>
<p>Between Xcode 7.3.1, Xcode 8, and Xcode 8.1 beta, you probably have more than one Xcode installed right now. Brian Gesiak <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160919/002959.html">asked</a> about how to compile Swift with a specific version of Xcode. Daniel Dunbar <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160919/002961.html">explained</a> it can be done by setting the <code class="language-plaintext highlighter-rouge">DEVELOPER_DIR</code> when compiling.</p>
<p>Updating Xcode is a chore no one is free from – not even Apple’s continuous integration servers. Nicole Jacque <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160919/002990.html">announced</a> some downtime to install Xcode 8.1 beta.</p>
<p>Ron Olson <a href="https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20160919/003336.html">confirmed</a> that Swift builds on Ubuntu 16.</p>
<h3 id="finally">Finally</h3>
<p>The long winter is over: Steve T-S is <a href="https://twitter.com/stroughtonsmith/status/776487916180738048">back</a> on Twitter. He’s uncovered interesting iOS internals like SceneKit’s <a href="https://twitter.com/stroughtonsmith/status/776487557370699776"><code class="language-plaintext highlighter-rouge">SCNHeadMountedDisplayRenderingTechnique</code></a>, and <a href="https://twitter.com/stroughtonsmith/status/776528404761997316">released</a> a Swift playground that allows you to browse files on your iPad.</p>
Issue #38
https://swiftweeklybrief.com/issue-38
2016-09-15T00:00:00-07:00
2016-09-15T00:00:00-07:00
JP Simard
https://twitter.com/simjp
https://github.com/jpsim.png?size=100
simjp
<p>The push and pull of Swift’s duality as an open source project that’s intimately tied to closed source products came to a culminating point this week, with the official release of <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000285.html">Swift 3.0</a> 🎉, coinciding with <a href="https://itunes.apple.com/app/xcode/id497799835">Xcode 8</a>, the <a href="https://www.apple.com/swift/playgrounds/">Swift Playgrounds iPad app</a>, iOS 10, tvOS 10 and watchOS 3. One can’t help but respect the amount of effort it must have taken to coordinate so many moving parts and align all these releases.</p>
<p>The Swift 3.0 <a href="https://swift.org/blog/swift-3-0-released/">release post</a> on swift.org provides a great overview of all the changes that were included, tips to migrate, links to an updated Swift book, and other details about the release.</p>
<p>Apple is the first to share that Swift 3 was made possible by a significant number of community contributions, so all you fine readers deserve a moment to celebrate… ok, break’s over, Swift 4 won’t write itself, so read on!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<p>The Swift team uses a Python script named <code class="language-plaintext highlighter-rouge">cmpcodesize</code> to measure the size of Swift build products. Improving that script is one way to contribute to reducing the size of Swift code. If you know some Python, try these tasks:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-407">SR-407</a>: <code class="language-plaintext highlighter-rouge">cmpcodesize</code> is capable of analyzing the size and segments of macOS Mach-O build products. Complete this task to allow it to analyze code size on Linux, by supporting the ELF object format.</li>
<li><a href="https://bugs.swift.org/browse/SR-2595">SR-2595</a>: The current output format for <code class="language-plaintext highlighter-rouge">cmpcodesize</code> can’t be easily parsed by other programs, making it hard to measure code size improvements and regressions over time. This task tracks adding additional output formats to <code class="language-plaintext highlighter-rouge">cmpcodesize</code>, such as CSV.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Dmitri Gribenko <a href="https://github.com/apple/swift/pull/4621">replaced</a> the String hashing algorithm on non-ObjC platforms with an implementation of <a href="https://131002.net/siphash/">SipHash-1-3</a>.</p>
<p>Vedant Kumar <a href="https://github.com/apple/swift/pull/4667">fixed</a> code coverage not being generated for top-level declarations.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/4676">added support</a> for implicit <code class="language-plaintext highlighter-rouge">self</code> in lazy var initializers, fixing <a href="https://bugs.swift.org/browse/SR-2203">SR-2203</a>.</p>
<p>Anders Bertelrud <a href="https://github.com/apple/swift-package-manager/pull/639">improved</a> the Xcode project generation to use a layered data model instead of print statements. Much nicer!</p>
<p>Michael Ilseman <a href="https://github.com/apple/swift/pull/4706">refactored</a> around 3,000 lines of code, reducing the code browsing burden of the ClangImporter.</p>
<p>The one and only Jesse Squires <a href="https://github.com/apple/swift-evolution/pull/526">updated</a> the Swift Evolution <a href="https://apple.github.io/swift-evolution/">status site</a> to distinguish between withdrawn and rejected proposals.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md">SE-0139</a>: <em>Bridge Numeric Types to <code class="language-plaintext highlighter-rouge">NSNumber</code> and Cocoa Structs to <code class="language-plaintext highlighter-rouge">NSValue</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000283.html">accepted with modifications</a>.</p>
<blockquote>
<p>The proposal has been accepted with one modification: numeric values bridged to <code class="language-plaintext highlighter-rouge">NSNumber</code> will maintain their type identity (e.g., an <code class="language-plaintext highlighter-rouge">Int8</code> bridged to an <code class="language-plaintext highlighter-rouge">NSNumber</code> can be cast via <code class="language-plaintext highlighter-rouge">as!</code>/<code class="language-plaintext highlighter-rouge">as?</code> to an <code class="language-plaintext highlighter-rouge">Int8</code>) while other instances of <code class="language-plaintext highlighter-rouge">NSNumber</code> (e.g., those created in Objective-C) can be cast to any numeric type that can represent their value. This matches the existing bridging behavior introduced in id-to-Any bridging (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md">SE-0116</a>). The proposal text has been updated accordingly.</p>
</blockquote>
<p>Joe Groff’s other proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md">SE-0140</a>: <em>Warn when <code class="language-plaintext highlighter-rouge">Optional</code> converts to <code class="language-plaintext highlighter-rouge">Any</code>, and bridge <code class="language-plaintext highlighter-rouge">Optional</code> As Its Payload Or <code class="language-plaintext highlighter-rouge">NSNull</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000284.html">accepted with one modification</a>.</p>
<blockquote>
<p>The proposal is accepted with one modification (described below).</p>
<p>Reviews on this proposal were mixed, with many expressing significant concerns about the ability to place an optional value into an <code class="language-plaintext highlighter-rouge">Any</code>, particularly when the <code class="language-plaintext highlighter-rouge">Any</code> comes from a nonnull-annotated Objective-C API:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-objc" data-lang="objc"><span class="c1">// Objective-C</span>
<span class="k">@interface</span> <span class="nc">MyClass</span> <span class="p">:</span> <span class="nc">NSObject</span>
<span class="k">-</span> <span class="p">(</span><span class="kt">void</span><span class="p">)</span><span class="nf">doSomething</span><span class="p">:(</span><span class="n">nonnull</span> <span class="n">id</span><span class="p">)</span><span class="nv">object</span><span class="p">;</span>
<span class="k">@end</span></code></pre></figure>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Swift</span>
<span class="k">let</span> <span class="nv">stringOpt</span><span class="p">:</span> <span class="kt">String</span><span class="p">?</span> <span class="o">=</span> <span class="nf">getSomeString</span><span class="p">()</span>
<span class="kt">MyClass</span><span class="p">()</span><span class="o">.</span><span class="nf">doSomething</span><span class="p">(</span><span class="n">stringOpt</span><span class="p">)</span> <span class="c1">// allowed; likely a programmer error</span></code></pre></figure>
<blockquote>
<p>This behavior was introduced as part of id-as-Any bridging (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md">SE-0116</a>)). As an amendment to SE-0140, Swift will produce a warning when an optional value is converted to a value of type <code class="language-plaintext highlighter-rouge">Any</code>, e.g.,</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// warning: optional value of type ‘String?’ is converted to an ‘Any’</span>
<span class="kt">MyClass</span><span class="p">()</span><span class="o">.</span><span class="nf">doSomething</span><span class="p">(</span><span class="n">stringOpt</span><span class="p">)</span>
<span class="c1">// note: use ‘!’ to force-unwrap the optional</span>
<span class="c1">// note: use ‘??’ to provide a default value if the optional is nil</span>
<span class="c1">// note: use ‘as Any’ to silence this warning</span></code></pre></figure>
<blockquote>
<p>Such a warning will address most accidental injections of optional values into <code class="language-plaintext highlighter-rouge">Any</code>, and the core team felt that this addresses accidental boxing of optional values better than leaving the opaque object types to fail fast in Objective-C code that inspects them (e.g., see <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160905/026961.html">this</a> message for a negative review partly on these grounds).</p>
<p>To the main point of this proposal, which is to bridging to either the payload or <code class="language-plaintext highlighter-rouge">NSNull</code>, the core team felt that:</p>
<ol>
<li>Bridging to the payload or <code class="language-plaintext highlighter-rouge">NSNull</code> brings to Objective-C code the same behavior that is already present in Swift’s type system, where an optional containing a payload can be dynamically casted to its payload type. For example, this is well-formed in Swift:</li>
</ol>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">optString</span><span class="p">:</span> <span class="kt">String</span><span class="p">?</span> <span class="o">=</span> <span class="s">"hello"</span>
<span class="k">let</span> <span class="nv">anyValue</span><span class="p">:</span> <span class="kt">Any</span> <span class="o">=</span> <span class="n">optString</span>
<span class="k">let</span> <span class="nv">stringValue</span><span class="p">:</span> <span class="kt">String</span> <span class="o">=</span> <span class="n">any</span> <span class="k">as!</span> <span class="n">stringValue</span> <span class="c1">// downcast succeeds, produces a String</span></code></pre></figure>
<blockquote>
<ol>
<li>While <code class="language-plaintext highlighter-rouge">NSNull</code> is not widely used in Cocoa APIs, it is better to enable those APIs to work properly when <code class="language-plaintext highlighter-rouge">nil</code> optional values do get bridged than to have an opaque-to-Objective-C boxed type that does not work well with any Objective-C APIs.</li>
</ol>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Andrew Trick’s proposal (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md">SE-0138</a>) from last week has been <a href="https://github.com/apple/swift-evolution/pull/523">renamed to <code class="language-plaintext highlighter-rouge">UnsafeRawBufferPointer</code></a> and its review period was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000282.html">extended</a> by one week.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Mishal Shah <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160905/002883.html">announced</a> that Swift CI is now capable of testing combinations of pull requests. CI can even test pull requests made to two separate repositories! For example, if Swift PR #123 makes a change to the Swift standard library, and swift-corelibs-foundation PR #456 updates Foundation for that change, the two can be tested together by posting the following comment:</p>
<figure class="highlight"><pre><code class="language-html" data-lang="html"><span class="c"><!-- As a comment on apple/swift pull request #123 --></span>
Please test with following PR:
https://github.com/apple/swift-corelibs-foundation/pull/456
@swift-ci Please test</code></pre></figure>
<p>Pushkar Kulkarni and Philippe Hausler <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160905/000924.html">discussed</a> important differences in bridging on Apple versus other platforms.</p>
<blockquote>
<p>Pushkar: There’ve been a few bug reports related to the coercion problems between Swift and Foundation types on Linux. For example this one: https://bugs.swift.org/browse/SR-2477 (Double/Int don’t coerce with NSNumber on Linux).</p>
<p>Philippe: From a technical perspective it is not impossible to do however as of current reference type to structural type bridging is conflated with the objective c runtime being present (specifically present on Darwin targets). Personally I think we need a better answer than what we have today but I don’t see the winds changing in the immediate future to support ref type bridges uniformly in a cross platform manner.</p>
</blockquote>
<p>Philippe has been advocating for better bridging support on non-Darwin platforms since Swift was open sourced nearly a year ago, and despite portability having been a <a href="https://github.com/apple/swift-evolution#development-major-version--swift-30">strong goal for Swift 3</a>, there are still important areas where the behavior varies between platforms, and this is one of them.</p>
<h3 id="finally">Finally</h3>
<p><a href="https://github.com/apple/swift/pull/4690">Sightings</a> of the elusive Swift 3.1 have been <a href="https://github.com/apple/swift-evolution/pull/522">reported</a> in the <a href="https://twitter.com/lottadot/status/775834633128718337">wild</a>, so please stay alert! You may have to migrate your apps again soon… 😳</p>
Issue #37
https://swiftweeklybrief.com/issue-37
2016-09-08T00:00:00-07:00
2016-09-08T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Of course, the big news this week was the <a href="http://www.apple.com/apple-events/september-2016/">Apple Event</a> yesterday. The <a href="http://www.apple.com/iphone-7/">iPhone 7</a> was announced, along with <a href="http://www.apple.com/apple-watch-series-2/">Apple Watch Series 2</a>. But more importantly, the GM seeds for Xcode 8, iOS 10, macOS 10.12, watchOS 3, and tvOS 10 <a href="https://developer.apple.com/download/">were released</a> — and that means we have our Swift 3.0 GM release. However, this still hasn’t been posted to <a href="https://swift.org/download/#releases">Swift.org</a>.</p>
<p>The public releases of iOS 10 and macOS Sierra will be September 13 and September 20, respectively.</p>
<!--excerpt-->
<h3 id="stats">Stats</h3>
<p>It’s been awhile since I last wrote about GitHub stats for the project overall, so let’s take a look!</p>
<ul>
<li>394 <a href="https://github.com/apple/swift/graphs/contributors">contributors</a></li>
<li>33,690 <a href="https://github.com/apple/swift/stargazers">stars</a></li>
<li>4,757 <a href="https://github.com/apple/swift/network">forks</a></li>
<li>4,661 <a href="https://github.com/apple/swift/pulls?q=is%3Apr+is%3Aopen">pull requests</a></li>
<li>41,925 <a href="https://github.com/apple/swift/commits/master">commits</a></li>
<li>140 <a href="http://apple.github.io/swift-evolution/">swift-evolution proposals</a></li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>John Holdsworth opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/622#discussion_r77898383">pull request</a> to port corelibs-foundation to Android. 🎉 This is a great step towards making Swift on Android useful, and potentially sharing code across platforms.</p>
<p>Anders Bertelrud <a href="https://github.com/apple/swift-package-manager/pull/639">improved</a> Xcode project generation in SwiftPM. “This is a first version of a more layered, robust, and readable Xcode project generation. The idea is to provide a simple representation of the Xcode project model, so that the logic that creates a project is readable, understandable, and maintainable.”</p>
<p>Jacob Bandes-Storch <a href="https://github.com/apple/swift/pull/4628">improved diagnostics</a> for invalid operator declarations.</p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>The following proposals definitely address some pain points in Swift 3 and it would be great to seem them accepted and implemented!</p>
<hr />
<p>Andrew Trick’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0138-unsaferawbufferpointer.md">SE-0138</a>: <em>UnsafeRawBufferPointer</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000275.html">under review</a>. This is a purely additive proposal to improve the Swift 3 migration experience.</p>
<blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md">SE-0107: UnsafeRawPointer</a> formalized Swift’s memory model with respect to strict aliasing and prevented arbitrary conversion between <code class="language-plaintext highlighter-rouge">UnsafePointer</code> types. When moving to Swift 3, users will need to migrate much of their code dealing with <code class="language-plaintext highlighter-rouge">UnsafePointer</code>s. The new <code class="language-plaintext highlighter-rouge">UnsafeRawPointer</code> makes that possible. It provides a legal means to operate on raw memory (independent of the type of values in memory), and it provides an API for binding memory to a type for subsequent normal typed access. However, migrating to these new APIs is not always straightforward. It has become customary to use <code class="language-plaintext highlighter-rouge">[UInt8]</code> in APIs that deal with a buffer of bytes and are agnostic to the type of values held by the buffer. However, converting between <code class="language-plaintext highlighter-rouge">UInt8</code> and the client’s element type at every API transition is difficult to do safely.</p>
</blockquote>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0139-bridge-nsnumber-and-nsvalue.md">SE-0139</a>: <em>Bridge Numeric Types to <code class="language-plaintext highlighter-rouge">NSNumber</code> and Cocoa Structs to <code class="language-plaintext highlighter-rouge">NSValue</code></em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000274.html">under review</a>.</p>
<blockquote>
<p>A handful of Swift numeric types are bridged to <code class="language-plaintext highlighter-rouge">NSNumber</code> when passed into Objective-C object contexts. We should extend this bridging behavior to all Swift numeric types. We should also bridge common Cocoa structs such as <code class="language-plaintext highlighter-rouge">NSRange</code> by boxing them into <code class="language-plaintext highlighter-rouge">NSValue</code> objects.</p>
</blockquote>
<p>Another proposal by Joe Groff, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0140-bridge-optional-to-nsnull.md">SE-0140</a>: <em>Bridge <code class="language-plaintext highlighter-rouge">Optional</code> As Its Payload Or <code class="language-plaintext highlighter-rouge">NSNull</code></em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-September/000281.html">under review</a>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">Optional</code>s can be used as values of <code class="language-plaintext highlighter-rouge">Any</code> type. After <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md">SE-0116</a>, this means you can pass an <code class="language-plaintext highlighter-rouge">Optional</code> to an Objective-C method expecting nonnull <code class="language-plaintext highlighter-rouge">id</code>.
This is often a mistake, and we should raise a warning when it occurs, but is occasionally useful. When an <code class="language-plaintext highlighter-rouge">Optional</code> is intentionally passed into Objective-C as a nonnull object, we should bridge <code class="language-plaintext highlighter-rouge">some</code> value by bridging the wrapped value, and bridge <code class="language-plaintext highlighter-rouge">none</code>s to a singleton such as <code class="language-plaintext highlighter-rouge">NSNull</code>.</p>
</blockquote>
<p>This would change this code:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">s1</span><span class="p">:</span> <span class="kt">String</span><span class="p">?</span> <span class="o">=</span> <span class="kc">nil</span><span class="p">,</span> <span class="nv">s2</span><span class="p">:</span> <span class="kt">String</span><span class="p">?</span> <span class="o">=</span> <span class="s">"hello"</span>
<span class="c1">// works, should warn, currently produces an opaque object type</span>
<span class="kt">ObjCClass</span><span class="p">()</span><span class="o">.</span><span class="nf">imported</span><span class="p">(</span><span class="n">s1</span><span class="p">)</span>
<span class="c1">// works, should warn, currently produces an opaque object type</span>
<span class="kt">ObjCClass</span><span class="p">()</span><span class="o">.</span><span class="nf">imported</span><span class="p">(</span><span class="n">s2</span><span class="p">)</span></code></pre></figure>
<p>To the following:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">s1</span><span class="p">:</span> <span class="kt">String</span><span class="p">?</span> <span class="o">=</span> <span class="kc">nil</span><span class="p">,</span> <span class="nv">s2</span><span class="p">:</span> <span class="kt">String</span><span class="p">?</span> <span class="o">=</span> <span class="s">"hello"</span>
<span class="c1">// proposed to bridge to NSNull.null</span>
<span class="kt">ObjCClass</span><span class="p">()</span><span class="o">.</span><span class="nf">imported</span><span class="p">(</span><span class="n">s1</span><span class="p">)</span>
<span class="c1">// proposed to bridge to NSString("hello")</span>
<span class="kt">ObjCClass</span><span class="p">()</span><span class="o">.</span><span class="nf">imported</span><span class="p">(</span><span class="n">s2</span><span class="p">)</span></code></pre></figure>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Still not much activity on the lists! Everyone must be busy preparing their apps for iOS 10 and macOS Sierra, or maybe everyone is distracted by that shiny new iPhone 7. 😎</p>
<h3 id="finally">Finally</h3>
<p>And finally — 😂</p>
<blockquote>
<p>“Try to realize the truth, there is no compiler. Then you will see it is not the compiler that’s broken, it is only yourself.”</p>
<p>— <a href="https://twitter.com/NeoNacho/status/773664214019964928">@NeoNacho</a></p>
</blockquote>
Issue #36
https://swiftweeklybrief.com/issue-36
2016-09-01T00:00:00-07:00
2016-09-01T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>It’s almost that time of the year again when <a href="http://www.apple.com/apple-events/september-2016/">Apple will reveal new iPhone models</a>. Invitations were sent to the press earlier this week for an event on September 7 — less than a week away! This likely means a final (or at least GM) release of Xcode 8 and the other platforms, and thus a final (or GM) release of Swift 3.</p>
<p>For me, this is least attractive aspect of Swift — being tied to the release cycles of Xcode, Apple’s platforms, and hardware. Along with <a href="http://bugreport.apple.com">radar</a>, these deadlines (and thus the <em>real deadline</em> for Swift 3) present a closed door to the open source community. I think these things could eventually be detrimental to the health of the project, but let’s see how the Swift 4 development cycle goes first! In any case, I think we’re all excited and ready for Swift 3 to be finished! 😄</p>
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2451">SR-2451</a>: [Compiler] Wording for labels in function types suggests that specific label cannot be used</li>
<li><a href="https://bugs.swift.org/browse/SR-2442">SR-2442</a>: [Compiler] Need better diagnostics for multi-value assignment with missing parentheses</li>
<li><a href="https://bugs.swift.org/browse/SR-2409">SR-2409</a>: [Compiler] Diagnostic refers to “Objective-C module” even on Linux</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Tim Bodeit <a href="https://github.com/apple/swift/pull/4578">found and fixed</a> a bug that would allow mutating a <code class="language-plaintext highlighter-rouge">let</code> constant of a non-class protocol type. There’s an example in the pull request. Also, this is one of the best pull requests I’ve ever seen! 😎</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/4529">implemented</a> an amendment to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md">SE-0112</a> that provides default implementations for all of the <code class="language-plaintext highlighter-rouge">CustomNSError</code> requirements.</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/625">added</a> documentation for the SwiftPM manifest file. 👌 Reminder: improving documentation is a great way to get involved!</p>
<h3 id="proposals">Proposals</h3>
<p>Still <a href="https://media.giphy.com/media/4pMX5rJ4PYAEM/giphy.gif">nothing to see here</a>!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>The mailing lists are still relatively quiet. I suspect the Core Team, as well as many other teams at Apple, are busy preparing for next week’s event. There are some small threads, but <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/026726.html">most pitches</a> are <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160829/026796.html">being deferred</a> from formal discussion due to being out of scope for Swift 4 stage 1. It’s clear that the Core Team is focused on completing the goals for Swift 4, and avoiding some of the “distractions” that were present the Swift 3 release cycle — namely, the overwhelming feedback and involvement from the open source community. To be clear, this wasn’t <em>a bad thing</em> but it dramatically impacted the roadmap for Swift 3. 😄 It seems like swift-evolution may be quieter during Swift 4.</p>
<h3 id="finally">Finally</h3>
<p>And finally — did you hear about the new <a href="https://twitter.com/slava_pestov/status/768558067885551616">access control modifier in Swift 4</a>? 😂</p>
Issue #35
https://swiftweeklybrief.com/issue-35
2016-08-25T00:00:00-07:00
2016-08-25T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Like last week, the <a href="https://lists.swift.org/pipermail/swift-evolution/">swift-evolution</a> list is unusually quiet, with few responses from the Core Team. As you know, we’re in beta 6 of Xcode 8, Swift 3, and Apple’s various OSes. With August coming to an end, we should expect GM releases pretty soon. The focus right now is still on finishing up and refining this release.</p>
<!--excerpt-->
<h3 id="community">Community</h3>
<p>Matt Rajca and Alex Lorenz launched a <a href="http://robotaryapp.com">Swift IDE</a> that lets users program robots in Swift.</p>
<p>John Holdsworth has started a <a href="https://github.com/SwiftJava/SwiftJava">project</a> to bridge Swift to Java. There are also a number of sub-projects under the <a href="https://github.com/SwiftJava">SwiftJava</a> GitHub organization. If Swift is ever to become a first-class language on Android, it will need to successfully bridge to Java as it does with C and Objective-C. This seems to be a great start! I’m sure contributions are welcome. 😊</p>
<h3 id="repositories">Repositories</h3>
<p>A number of new repositories have shown up under the <a href="https://github.com/apple">Apple GitHub organization</a>. Most relevant to this community would be the new <a href="https://github.com/apple/swift-xcode-playground-support">Xcode playground support</a> project — <em>Logging and communication to allow Swift toolchains to communicate with Xcode.</em></p>
<p>The other new repositories are all related to the <a href="https://www.calendarserver.org">Calendar and Contacts Server</a> project, which is a standards-compliant server implementing the CalDAV and CardDAV protocols. The project is accompanied by a number of sub-projects, all prefixed with “ccs”.</p>
<p>This project isn’t particularly relevant to the Swift community, although it is interesting to see more open source projects from Apple being hosted on GitHub. It was originally <a href="https://en.wikipedia.org/wiki/Calendar_and_Contacts_Server">released in 2006 at WWDC</a>, but I’m not sure if it had been open source before this week or not (perhaps on <a href="https://opensource.apple.com">opensource.apple.com</a>).</p>
<p>Calendar and Contacts Server repositories:</p>
<ul>
<li><a href="https://github.com/apple/ccs-calendarserver">ccs-calendarserver</a></li>
<li><a href="https://github.com/apple/ccs-twistedextensions">ccs-twistedextensions</a></li>
<li><a href="https://github.com/apple/ccs-pysecuretransport">ccs-pysecuretransport</a></li>
<li><a href="https://github.com/apple/ccs-pyosxframeworks">ccs-pyosxframeworks</a></li>
<li><a href="https://github.com/apple/ccs-pycalendar">ccs-pycalendar</a></li>
<li><a href="https://github.com/apple/ccs-caldavtester">ccs-caldavtester</a></li>
<li><a href="https://github.com/apple/ccs-pykerberos">ccs-pykerberos</a></li>
<li><a href="https://github.com/apple/ccs-caldavclientlibrary">ccs-caldavclientlibrary</a></li>
<li><a href="https://github.com/apple/ccs-pyopendirectory">ccs-pyopendirectory</a></li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>John McCall <a href="https://github.com/apple/swift/pull/4448">fixed</a> some bugs with dynamic casting: (1) fixed the cast optimizer to handle CF/NS bridging correctly, and (2) fixed the dynamic cast runtime to handle <code class="language-plaintext highlighter-rouge">class</code> and <code class="language-plaintext highlighter-rouge">enum</code> casts to <code class="language-plaintext highlighter-rouge">AnyHashable</code> correctly. This should unblock the fix for <a href="https://bugs.swift.org/browse/SR-2388">SR-2388</a>.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/4431">removed</a> a ton of dead code. 🤓</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift/pull/4437">added</a> a new driver option: <code class="language-plaintext highlighter-rouge">swiftc -continue-building-after-errors</code>.</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift/pull/4367">added</a> another new driver option: <code class="language-plaintext highlighter-rouge">swiftc -driver-time-compilation</code>. This option measures the amount of time each step of the compilation process takes. Here’s an example:</p>
<figure class="highlight"><pre><code class="language-bash" data-lang="bash"><span class="nv">$ </span>swiftc <span class="nt">-emit-library</span> <span class="nt">-module-name</span> Crispix <span class="se">\</span>
Crispix/A.swift Crispix/B.swift Crispix/C.swift <span class="se">\</span>
<span class="nt">-driver-time-compilation</span>
<span class="o">===</span><span class="nt">-------------------------------------------------------------------------</span><span class="o">===</span>
Driver Time Compilation
<span class="o">===</span><span class="nt">-------------------------------------------------------------------------</span><span class="o">===</span>
Total Execution Time: 0.0000 seconds <span class="o">(</span>0.0875 wall clock<span class="o">)</span>
<span class="nt">---Wall</span> Time--- <span class="nt">---</span> Name <span class="nt">---</span>
0.0245 <span class="o">(</span> 28.0%<span class="o">)</span> <span class="nb">link </span>Crispix/A.swift Crispix/B.swift Crispix/C.swift
0.0211 <span class="o">(</span> 24.1%<span class="o">)</span> compile Crispix/A.swift
0.0209 <span class="o">(</span> 23.9%<span class="o">)</span> compile Crispix/B.swift
0.0176 <span class="o">(</span> 20.1%<span class="o">)</span> compile Crispix/C.swift
0.0035 <span class="o">(</span> 4.0%<span class="o">)</span> swift-autolink-extract Crispix/A.swift Crispix/B.swift Crispix/C.swift
0.0875 <span class="o">(</span>100.0%<span class="o">)</span> Total</code></pre></figure>
<p>You can even add the flag to your Xcode project settings, in order to have time measurements printed to your build logs.</p>
<p>Maxim Moiseev & Daniel Dunbar implemented proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md">SE-0137</a>. You can find the various pull requests here: <a href="https://github.com/apple/swift/pull/4361">swift (1)</a>, <a href="https://github.com/apple/swift/pull/4391">swift (2)</a>, <a href="https://github.com/apple/swift/pull/4406">swift (3)</a>, <a href="https://github.com/apple/swift-package-manager/pull/592">swift-package-manager (1)</a>, <a href="https://github.com/apple/swift-package-manager/pull/613">swift-package-manager (2)</a>.</p>
<p>Gonzalo Larralde <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/162">opened a pull request</a> on corelibs-libdispatch with initial work for Android support.</p>
<h3 id="proposals">Proposals</h3>
<p>No new proposals! There’s nothing in review, upcoming, or waiting to be scheduled. We should take this rare opportunity to relax and take stock of Swift 3.0.</p>
<p>Note: there are seven proposals that were accepted for Swift 3 but were not implemented. Those will be rolling into a subsequent release. You can find them on the <a href="http://apple.github.io/swift-evolution/">proposal status page</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Daniel Dunbar <a href="https://lists.swift.org/pipermail/swift-build-dev//Week-of-Mon-20160815/000608.html">shared an update</a> on the status of Swift Package Manager:</p>
<blockquote>
<p>The package manager was a brand new project released with open source Swift, and we have made significant progress as part of Swift 3.0. Starting from that humble beginning we now estimate there are around 3,500 Swift Packages on GitHub (*), with more and more showing up every day.</p>
<p>Since release, we have seen a rapid explosion in the package ecosystem with brand new Swift-based web frameworks (like Kitura, Perfect, Vapor, and Zewo), tooling and infrastructure (like the IBM Package Catalog and swiftenv), or simply adoption by existing popular Swift frameworks (like Alamofire, SnapKit, SwiftJSON, and RxSwift).</p>
<p>We wanted to lay out our plans for the package manager with regard to the upcoming Swift 3.0 release, some project status, and a bit about our future directions.</p>
<h4 id="release-plan">Release Plan</h4>
<p>Our <code class="language-plaintext highlighter-rouge">swift-3.0</code> branch was cut along with the Swift compiler project and will be our final release branch for the Swift 3.0 release. At this point, the only changes we anticipate taking onto the branch are ones that have significant impact on our current user base (primarily those focused on server-side Swift development).</p>
<p>Swift 3.0 will be the first official release including the package manager, which is also shipping as a command line tool inside Xcode 8. We are looking forward to seeing the ecosystem develop as these tools GM alongside the now source stable Swift 3.0!</p>
<p><a href="https://lists.swift.org/pipermail/swift-build-dev//Week-of-Mon-20160815/000608.html">Continue reading…</a></p>
</blockquote>
<p>Unfortunately, it looks like <a href="https://twitter.com/SmileyKeith/status/766046454288818176">SwiftPM won’t be useful</a> for the iOS and macOS communities in the near future. Daniel Dunbar <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160815/000611.html">reiterates</a> the challenges of Xcode integration mentioned <a href="https://lists.swift.org/pipermail/swift-users/2015-December/000052.html">last year</a>. Rick Ballard <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160815/000613.html">further elaborated</a> on this (emphasis mine):</p>
<blockquote>
<p>We plan for you to be able to write iOS Swift Packages, but rather than creating a complete iOS build system in SwiftPM, this will likely work by leveraging Xcode’s build system. We think that great Xcode integration is a requirement before we will see mass SwiftPM adoption by the iOS developer community. <strong>Since Xcode is not part of the open source project</strong>, the schedule and specific plans for that work are not public – but there will be work done in the open source project to give SwiftPM a library architecture suitable for allowing it to integrate with IDEs like Xcode.</p>
<p>[…]</p>
</blockquote>
<p>You can check <a href="http://isxcodeopensourceyet.github.io">this site</a> for updates on Xcode’s open source status. 😏</p>
<p>Doug Gregor and Joe Groff pitched two proposal drafts, which are follow-ups to previously implemented proposals in Swift 3. Both deal with improving the bridging behavior between Swift and Objective-C — a feature that has seen frequent changes through the evolution process.</p>
<ol>
<li><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/026560.html">Bridge Numeric Types to NSNumber and Cocoa Structs to NSValue</a></li>
<li><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160822/026561.html">Bridge Optional As Its Payload Or NSNull</a></li>
</ol>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/_ryannystrom/status/766435769657466880">buttons</a>. <code class="language-plaintext highlighter-rouge">¯\_(ツ)_/¯</code></p>
Issue #34
https://swiftweeklybrief.com/issue-34
2016-08-18T00:00:00-07:00
2016-08-18T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome back to the weekly! I took a much needed break last week, so I’ll try to report on the last two weeks today. As always, if I missed anything, <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">send a pull request</a>!</p>
<p>Xcode 8 beta 6 <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_8_beta_6/Release_Notes_for_Xcode_8_beta_6.pdf">was released</a> this week. It’s a huge update from the previous beta, containing a number of completed swift-evolution proposals.</p>
<p>Generally speaking, it looks like the Core Team is still in the process of fixing, refining, and finishing Swift 3. There’s little to no activity on GitHub or the mailing lists about Swift 4 yet — aside from Chris Lattner’s <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000269.html">original email</a> and some initial minor discussions. In fact, if you look at the <a href="https://lists.swift.org/pipermail/swift-evolution/">swift-evolution archives</a> since Ted Kremenek’s “end of Swift 3” <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000264.html">announcement</a>, the past few weeks have had substantially fewer messages than previous weeks — roughly 100-300 instead of 500-1,000 messages.</p>
<p>I’m definitely looking forward to a calmer Swift development cycle that focuses more on stability and reducing churn for users — and so far it seems like Swift 4 will do just that! 😄</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2354">SR-2354</a>: [Compiler] <code class="language-plaintext highlighter-rouge">inout</code> parameter in subscript gives the wrong error message</li>
<li><a href="https://bugs.swift.org/browse/SR-2145">SR-2145</a>: [Compiler] Incorrect fix-it application when correcting optionals as booleans in a ternary in a lazy-var initializer</li>
<li><a href="https://bugs.swift.org/browse/SR-2083">SR-2083</a>: [SwiftPM] Don’t error if a directory contains only ignored files</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Paul Meng <a href="https://github.com/apple/swift/pull/4102">merged</a> changes to swift/sema to continue the work on <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a>.</p>
<p>Daniel Dunbar <a href="https://github.com/apple/swift-package-manager/pull/589">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md">SE-0135</a>. (See below)</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/commit/ed01f89401674e7c738657880c399671637a2d40">fixed</a> an issue to allow <code class="language-plaintext highlighter-rouge">Any</code> as an <code class="language-plaintext highlighter-rouge">IBAction</code>’s sender and an <code class="language-plaintext highlighter-rouge">IBOutlet</code>’s type.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/4356">fixed</a> a SILGen and IRGen bug that caused crashes and linker errors when Objective-C generic classes conformed to Swift protocols.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md">SE-0135</a>: <em>Package Manager Support for Differentiating Packages by Swift version</em> by Anders Bertelrud was <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160801/000587.html">accepted</a>.</p>
<blockquote>
<p>There was little feedback on the proposal, in particular relative to the complexity of the proposal and space of possible things we could do. We found this unfortunate, but are still accepting the proposal for the following reasons:</p>
<ol>
<li>Since we cannot anticipate in advance how widely or for how long the Swift 3.0 package manager will be used, we feel it is important to have some escape hatch for Swift/SwiftPM version specific dependency selection.</li>
<li>The proposal is purely additive and intended to only be a short term mechanism. If it turns out to never be needed, or not suffice for the purpose for which it was designed, then we can remove it in a future release with little overhead.</li>
</ol>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0137-avoiding-lock-in.md">SE-0137</a>: <em>Avoiding Lock-In to Legacy Protocol Designs</em> by Dave Abrahams and Dmitri Gribenko was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-August/000270.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-August/000272.html">accepted</a>.</p>
<blockquote>
<p>Community feedback to this proposal was light but positive. The core team agrees that the proposal is a reasonable change to make for Swift 3, even at this late date. Thanks go to Dave Abrahams for pushing to get this into the release.</p>
</blockquote>
<p>SE-0137 Proposal summary:</p>
<blockquote>
<p>We propose to deprecate or move protocols that shouldn’t be a part of the standard library’s public API going forward.</p>
<p>We’ve always known that when Swift reached ABI stability (now slated for Swift 4), we would be committed to supporting many of the standard library’s design decisions for years to come.</p>
<p>We only realized very recently that, although Swift 3.0 is not shipping with a stable ABI, the promise that Swift 3.0 code will work with Swift 4.0 means that many of the standard library’s protocols will be locked down now. Especially where these protocols show up in refinement hierarchies, we won’t be able to keep Swift 3 code working in the future without carrying them forward into future standard library binaries.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ivan Akulov <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160815/002689.html">announced</a> that they have <a href="http://swiftbook.ru/doc/about-swift">translated</a> <em>The Swift Programming Language</em> book into Russian! There’s also a <a href="https://github.com/IvanAkulov/The-Swift-Programming-Language-RUS">repo on GitHub</a> where you can report issues. 😎</p>
<p>On the LLVM-dev list, Doug Gregor <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-August/103742.html">announced</a> a job opening for a Swift frontend compiler engineer. 🤓</p>
<h3 id="finally">Finally</h3>
<p>And finally — what were your <a href="https://twitter.com/NeoNacho/status/764909840699449344">#FirstSevenLanguages</a>? 😂</p>
Issue #33
https://swiftweeklybrief.com/issue-33
2016-08-04T00:00:00-07:00
2016-08-04T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>What a week it’s been! <a href="/issue-32/">Last week</a> there were 23 accepted proposals that were “awaiting implementation”. Now <a href="http://apple.github.io/swift-evolution/">only 8</a> remain! It’s incredible how much contributors from the community and the Core Team managed to accomplish in such a short time. The <a href="https://developer.apple.com/news/?id=08012016a">fourth beta</a> of Xcode 8 was also released this week.</p>
<!--excerpt-->
<h3 id="community">Community</h3>
<p>Russ Bishop <a href="https://realm.io/news/slug-russ-bishop-contributing-open-source-swift-proposal/">gave a great talk</a> titled <em>Contributing to Swift: From Proposal to Shipped</em>. Definitely check it out if you are interested in getting involved with swift-evolution!</p>
<p>Brian Gesiak wrote a <a href="http://modocache.io/contributing-to-nuclide-swift">blog post</a> on <em>Contributing to Nuclide’s Swift Integration: Why and How</em>. If you want to help make <a href="https://nuclide.io">Nuclide</a> a viable editor for Swift, then read on!</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Han Sangjin <a href="https://github.com/apple/swift-corelibs-foundation/pull/381">started</a> an initial port of corelibs-foundation to Cygwin.</p>
<p>As mentioned above, it was a big week for getting the final proposals for Swift 3 finished!</p>
<ul>
<li>Xiaodi Wu <a href="https://github.com/apple/swift/pull/3816">implemented</a> SE-0134.</li>
<li>Anders Bertelrud <a href="https://github.com/apple/swift-package-manager/pull/566">implemented</a> SE-0129.</li>
<li>Jacob Bandes-Storch <a href="https://github.com/apple/swift/pull/3809">implemented</a> SE-0133.</li>
<li>Doug Gregor <a href="https://github.com/apple/swift/pull/3837">implemented</a> SE-0111.</li>
<li>Robert Widmann <a href="https://github.com/apple/swift/pull/3761">finished implementing</a> SE-0089.</li>
<li>Michael Ilseman <a href="https://github.com/apple/swift/pull/3853">implemented</a> SE-0103.</li>
<li>Rintaro Ishizaki <a href="https://github.com/apple/swift/pull/3854">implemented</a> SE-0101.</li>
<li>Richard Wei and Robert Widmann <a href="https://github.com/apple/swift/pull/3878">implemented</a> SE-0096.</li>
<li>John McCall <a href="https://github.com/apple/swift/pull/3882">implemented</a> SE-0117.</li>
</ul>
<h3 id="proposal-status">Proposal status</h3>
<p>The proposals for Swift 3 that were accepted, but <a href="http://apple.github.io/swift-evolution/">not implemented</a> are:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md">SE-0042</a>: <em>Flattening the function type of unapplied method references</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md">SE-0045</a>: <em>Add <code class="language-plaintext highlighter-rouge">prefix(while:)</code> and <code class="language-plaintext highlighter-rouge">drop(while:)</code> to the stdlib</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md">SE-0068</a>: <em>Expanding Swift <code class="language-plaintext highlighter-rouge">Self</code> to class members and value types</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>: <em>Adding a Build Configuration Import Test</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080</a>: <em>Failable Numeric Conversion Initializers</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md">SE-0082</a>: <em>Package Manager Editable Packages</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a>: <em>Distinguish between single-tuple and multiple-argument function types</em></li>
</ul>
<p>It’s still not clear what is going to happen to these. Some are additive, so they could be implemented at any time. However, others contain source-breaking changes. There hasn’t been any communication from the Core Team on the fate of <em>accepted-but-unimplemented</em> proposals for Swift 3. I hope these make it into a Swift 3.x release, but it seems they may not be revisited until Swift 4.0 or later.</p>
<p><code class="language-plaintext highlighter-rouge">¯\_(ツ)_/¯</code></p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0135-package-manager-support-for-differentiating-packages-by-swift-version.md">SE-0135</a>: <em>Package Manager Support for Differentiating Packages by Swift version</em> by Anders Bertelrud is <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160725/000578.html">under review</a>.</p>
<blockquote>
<p>As new, source-incompatible versions of Swift come into use, there is a growing need for packages to be authored in a way that makes them usable from multiple versions of Swift. While package authors want to adopt new Swift versions as soon as possible, they also need to support their existing clients.</p>
<p>Source incompatibilities can arise not only from changes to the language syntax, but also from changes to the Swift Standard Library and the Package Description API of the Swift Package Manager itself.</p>
<p>Support for multiple Swift versions could in theory be implemented using <code class="language-plaintext highlighter-rouge">#if</code> directives in the package source code, but that approach can become unwieldy when the required code differences are significant.</p>
<p>The Swift Package Manager should therefore provide facilities that make it as easy as possible for package authors to support clients using different versions of Swift. The proposal described here intends to solve an immediate need for Swift Package Manager 3; the need for version-specific packages will hopefully diminish as the language and libraries stabilize. We can revisit the need for this support in a future version of Swift.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p><a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000269.html">Looking back on Swift 3 and ahead to Swift 4</a>, from Chris Lattner:</p>
<blockquote>
<p>The Swift 3 release is nearing completion, so it is time to look back on the release, learn from what happened, and use it to shape what we (the Swift community) do in the year ahead. Overall, Swift 3 is going to be an absolutely <em>amazing</em> release, and it is impressive how much got done. Thank you to everyone who contributed to making it happen. Instead of diving into a flurry of new proposals immediately, it is important to take stock of where we are, and look at the bigger picture.</p>
<p>Metapoint: this email is ridiculously long and covers multiple topics. Instead of replying to it directly, it is best to start new threads on individual topics that you’d like to discuss. Just tag them with “[Swift 4]” in the subject line.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000269.html">continue reading…</a></p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — have you seen this painting of <a href="https://twitter.com/zats/status/760891188366802944">Jonathan Swift holding the first *.swift file</a>? 😄 I wonder if he ever wrote any proposals. 😉</p>
Issue #32
https://swiftweeklybrief.com/issue-32
2016-07-28T00:00:00-07:00
2016-07-28T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Yesterday was the big day — the last day for Swift 3 breaking changes! Which means Swift 3 evolution <a href="https://github.com/apple/swift-evolution/commit/aea8b836d21051076663c5692ec1d09bb3222527">is done</a>!</p>
<p>According to Ted Kremenek’s email (below), any proposals that are in active development <em>and near completion</em> have an extended deadline of Friday, July 29. So, tomorrow! 😄 As of this writing the current <a href="http://apple.github.io/swift-evolution/">status page</a> lists 23 proposals that are “awaiting implementation”, however I know many of these are in-flight. It should be more clear exactly which proposals are <strong>not</strong> going to be included in the final Swift 3.0 release by the end of the day tomorrow, or early next week.</p>
<p>Unfortunately, it looks like a decent amount of proposals that contain source-breaking changes likely <strong>will not</strong> make the deadline for Swift 3. This means that Swift still has not reached (complete) source-stability, but it will be a great release nonetheless. At the moment, it’s not clear what the plan is for these proposals. Perhaps one or more Swift 3.x releases will address them?</p>
<p>In any case, Swift 3 is a dramatic step forward for the language. The Swift Core Team and open source contributors deserve a huge congratulations for all of their hard work! 🎉👏</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2083">SR-2083</a>: [SwiftPM] Don’t error if a directory contains only ignored files</li>
<li><a href="https://bugs.swift.org/browse/SR-2022">SR-2022</a>: [Compiler] Add better fixit for type checking in switch statements</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md">SE-0102</a> was <a href="https://github.com/apple/swift/pull/3658">implemented</a> by Slava Pestov. This replaces the <code class="language-plaintext highlighter-rouge">@noreturn</code> attribute with a return type of <code class="language-plaintext highlighter-rouge">Never</code>:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Old</span>
<span class="kd">@noreturn</span> <span class="kd">func</span> <span class="nf">runAndExit</span><span class="p">()</span> <span class="p">{</span> <span class="cm">/* ... */</span> <span class="p">}</span>
<span class="c1">// New</span>
<span class="kd">func</span> <span class="nf">runAndExit</span><span class="p">()</span> <span class="o">-></span> <span class="kt">Never</span> <span class="p">{</span> <span class="cm">/* ... */</span> <span class="p">}</span></code></pre></figure>
<p>As part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md">SE-0086</a>, <code class="language-plaintext highlighter-rouge">Process</code> was <a href="https://github.com/apple/swift/pull/3598">renamed</a> to <code class="language-plaintext highlighter-rouge">CommandLine</code>, and <code class="language-plaintext highlighter-rouge">NSTask</code> was <a href="https://github.com/apple/swift/pull/3670">renamed</a> to <code class="language-plaintext highlighter-rouge">Process</code>:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Old</span>
<span class="k">let</span> <span class="nv">task</span> <span class="o">=</span> <span class="kt">NSTask</span><span class="p">()</span>
<span class="n">task</span><span class="o">.</span><span class="n">launchPath</span> <span class="o">=</span> <span class="s">"/usr/bin/echo"</span>
<span class="n">task</span><span class="o">.</span><span class="n">arguments</span> <span class="o">=</span> <span class="kt">Process</span><span class="o">.</span><span class="n">arguments</span>
<span class="c1">// New</span>
<span class="k">let</span> <span class="nv">process</span> <span class="o">=</span> <span class="kt">Process</span><span class="p">()</span>
<span class="n">process</span><span class="o">.</span><span class="n">launchPath</span> <span class="o">=</span> <span class="s">"/usr/bin/echo"</span>
<span class="n">process</span><span class="o">.</span><span class="n">arguments</span> <span class="o">=</span> <span class="kt">CommandLine</span><span class="o">.</span><span class="n">arguments</span></code></pre></figure>
<p>As part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md">SE-0086</a>, <code class="language-plaintext highlighter-rouge">OutputStream</code> was <a href="https://github.com/apple/swift/pull/3576">renamed</a> to <code class="language-plaintext highlighter-rouge">TextOutputStream</code> and <code class="language-plaintext highlighter-rouge">NSOutputStream</code> was <a href="https://github.com/apple/swift/pull/3667">renamed</a> to <code class="language-plaintext highlighter-rouge">OutputStream</code>.</p>
<p>Ayaka Nonaka <a href="https://github.com/apple/swift/pull/3745">merged</a> changes to import Objective-C’s <code class="language-plaintext highlighter-rouge">@compatibility_alias</code> compiler directive as a Swift <code class="language-plaintext highlighter-rouge">typealias</code>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md">SE-0131</a> was <a href="https://github.com/apple/swift/pull/3554">implemented</a> by Dmitri Gribenko. This adds a type-erased <code class="language-plaintext highlighter-rouge">AnyHashable</code> container to the standard library.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md">SE-0130</a> was <a href="https://github.com/apple/swift/pull/3758">implemented</a> by Roman Levenstein. This cleans up a number of <code class="language-plaintext highlighter-rouge">String</code> initializers.</p>
<p>Dave Liu <a href="https://github.com/apple/swift-corelibs-foundation/pull/482">submitted</a> a pull request to implement starter bug <a href="https://bugs.swift.org/browse/SR-1608">SR-1608</a>, implementing <code class="language-plaintext highlighter-rouge">NSStream</code>, <code class="language-plaintext highlighter-rouge">NSInputStream</code> and <code class="language-plaintext highlighter-rouge">NSOutputStream</code> in corelibs-foundation.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0128-unicodescalar-failable-initializer.md">SE-0128</a>: <em>Change failable UnicodeScalar initializers to failable</em> by Xin Tong was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000252.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000259.html">accepted</a>.</p>
<blockquote>
<p>Feedback was universally positive, and the proposal is straight forward.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0130-string-initializers-cleanup.md">SE-0130</a>: <em>Replace repeating <code class="language-plaintext highlighter-rouge">Character</code> and <code class="language-plaintext highlighter-rouge">UnicodeScalar</code> forms of <code class="language-plaintext highlighter-rouge">String.init</code></em> by Roman Levenstein was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000253.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000260.html">accepted</a>.</p>
<blockquote>
<p>There was very little public discussion about this proposal, but the core team believes this eliminates a real ambiguity, while leaving doors open for future improved designs.</p>
<p>Thank you to Roman Levenstein for driving this discussion forward.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nonobjectivecbase.md">SE-0125</a>: <em>Remove <code class="language-plaintext highlighter-rouge">NonObjectiveCBase</code> and <code class="language-plaintext highlighter-rouge">isUniquelyReferenced</code></em> by Arnold Schwaighofer was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000261.html">accepted</a>.</p>
<blockquote>
<p>This proposal had significant community feedback to help refine and improve its design, and Arnold has incorporated that into his v2 of the proposal. The core team agrees the new revision is a good design.</p>
<p>Thank you to Arnold Schwaighofer for driving this discussion forward!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md">SE-0127</a>: <em>Cleaning up stdlib Pointer and Buffer Routines</em> by Charlie Monroe was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000262.html">accepted</a>.</p>
<blockquote>
<p>The proposal has been <em>accepted with a modification</em>.</p>
<p>This proposal got a significant amount of helpful feedback, which Charlie has already incorporated into the proposal. The core team requests one additional minor change, which is to drop the addition of the <code class="language-plaintext highlighter-rouge">ObjectIdentifier.unsafeAddress</code> field.</p>
<p>Thank you to Charlie Monroe for driving this discussion forward!</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0131-anyhashable.md">SE-0131</a>: <em>Add <code class="language-plaintext highlighter-rouge">AnyHashable</code> to the standard library</em> by Dmitri Gribenko was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000254.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000263.html">accepted</a>.</p>
<blockquote>
<p>The feedback on this proposal was quite positive. A few questions were raised, but were answered on-thread. Thank you to Dmitri Gribenko for writing this proposal and driving this discussion forward.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0133-rename-flatten-to-joined.md">SE-0133</a>: <em>Rename <code class="language-plaintext highlighter-rouge">flatten()</code> to <code class="language-plaintext highlighter-rouge">joined()</code></em> by Jacob Bandes-Storch was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000255.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000265.html">accepted</a>.</p>
<blockquote>
<p>This proposal had significant positive community feedback for aligning common operation names, but raised questions about whether ‘flatten’ was term of art, and what it would mean for related operations like ‘flatMap’. The core team discussed both sides of this debate, and decided it is best to rename ‘flatten’ to ‘joined’, but keep ‘flatMap’ as it is, to preserve its term of art. The core team prefers that it remain a distinct overload of joined(separator:) to preserve performance. It also requests that the returned collection types (FlattenCollection and friends) be left as-is for now, since they are not names commonly directly referenced, and we’d like to keep the change minimal.</p>
<p>Thank you to Jacob Bandes-Storch for driving this discussion forward! Time is short, we’d appreciate it if someone could implement this ASAP.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0134-rename-string-properties.md">SE-0134</a>: <em>Rename two UTF8-related properties on String</em> by Xiaodi Wu and Erica Sadun was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000257.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000266.html">accepted</a> with revision.</p>
<blockquote>
<p>This proposal has two parts. The core team approves the first part: “Rename <code class="language-plaintext highlighter-rouge">nulTerminatedUTF8CString</code> to <code class="language-plaintext highlighter-rouge">utf8CString</code>”. This property is intended for use when interoperating with APIs that take C-style <code class="language-plaintext highlighter-rouge">char *</code> parameters.</p>
<p>For the second part, the proposal suggests “Rename <code class="language-plaintext highlighter-rouge">nulTerminatedUTF8</code> to <code class="language-plaintext highlighter-rouge">nullTerminatedUTF8</code>.” The core team discussed this, looked at various uses of the API (among code bases publicly available on github) and came to the conclusion that it is best to just remove this property outright. The clients we found would be better served using the <code class="language-plaintext highlighter-rouge">.utf8CString</code> property.</p>
<p>Thank you to Xiaodi Wu and Erica Sadun for driving this discussion forward! Time is short, we’d appreciate it if someone could implement this ASAP.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md">SE-0117</a>: <em>Allow distinguishing between public access and public overridability</em> by Javier Soto and John McCall had its <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000249.html">third review</a> (most reviews of any proposal so far!) and was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000268.html"><strong>accepted</strong></a>!</p>
<blockquote>
<p>This proposal was far better received by the community than previous versions of the proposal, and the “first design” was the favored path within it. However, there were some concerns raised about the complexity of the model, stemming from non-obvious combinations like “open private”. As such, the core team has requested that the proposal be revised to make “open” function as another access control specifier. “open” is now simply “more public than public”, providing a very simple and clean model.</p>
<p>John has already revised the proposal to the new model, I encourage you to read it if you haven’t already.</p>
<p>Thank you to John McCall and also Javier Soto for driving this discussion forward! John is already working on an implementation of this now.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0129-package-manager-test-naming-conventions.md">SE-0129</a>: <em>Package Manager Test Naming Conventions</em> by Anders Bertelrud was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025590.html">accepted</a>.</p>
<blockquote>
<p>There was relatively little feedback on the proposal but it had unanimous support, along with additional support for the future directions that are unblocked by the proposal with regard to allowing additional target types under the <code class="language-plaintext highlighter-rouge">Tests</code> convention directory.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md">SE-0119</a>: <em>Remove access modifiers from extensions</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000250.html">rejected</a>.</p>
<blockquote>
<p>The majority of the feedback on this proposal was opposed to it, because it eliminated the useful ability to apply access control to a batch of methods and properties.</p>
<p>Thank you to Adrian Zubarev for raising this proposal.</p>
</blockquote>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md">SE-0122</a>: <em>Use colons for subscript declarations</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000258.html">rejected</a>.</p>
<blockquote>
<p>The review of “SE-0122: Use colons for subscript declarations” ran from July 19…24. The proposal has been <em>rejected</em>.</p>
<p>The feedback on this proposal from the community was overall divided with a slight bias towards reject. Reasonable arguments were made on both sides: subscripts are definitely property-like in some ways, but they are also function-like in other ways. Further, if we were aiming to align declaration syntax with use, arguably the parameter list should be enclosed in square brackets (but to be clear, we’re not going to do that). Overall, the core team agrees with the pervasive sentiment that this is not important enough to make a change for.</p>
<p>Thank you to James Froggatt for raising this proposal.</p>
</blockquote>
<h3 id="deferred-proposals">Deferred proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0132-sequence-end-ops.md">SE-0132</a>: <em>Rationalizing Sequence end-operation names</em> by Becca Royal-Gordon and Dave Abrahams was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000256.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000267.html">deferred</a>.</p>
<blockquote>
<p>This is a very large proposal very late in the Swift 3 schedule. It has some clearly good pieces to it, but also many parts that are controversial with the community, and requires more design and iteration than time permits. It is best to defer this and make a change when we have something truly great, giving the benefit of proper time to design and evaluate the proposal.</p>
<p>Thank you to Becca Royal-Gordon and Dave Abrahams for driving this discussion. When the goals and parameters of Swift 4 are established, we should pick up this thread and see what makes sense to do here.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md">SE-0126</a>: <em>Refactor Metatypes, repurpose <code class="language-plaintext highlighter-rouge">T.self</code> and <code class="language-plaintext highlighter-rouge">Mirror</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000251.html">withdrawn for revision</a>.</p>
<blockquote>
<p>The authors of SE-0126 have requested that we withdraw the proposal. The idea will be revised, return back to the “pitch” phase, and when that converges, SE-0126 will be revised.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>All proposals for Swift 3 have been reviewed! 🎉</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000264.html">sent an update</a> on the <em>end of source-breaking changes for Swift 3</em>:</p>
<blockquote>
<p>Dear friends,</p>
<p>Today is July 27 — and the last planned day to take source-breaking changes for Swift 3. It has been an incredible ride to this point, so let’s take stock of where we are. Here are the list of currently accepted — but not yet (fully) implemented — evolution proposals (this is drawn from the “accepted” but not marked “implemented” proposals from the <a href="https://github.com/apple/swift-evolution">swift-evolution</a> repository):</p>
<p>[…]</p>
<p>These are all changes the community has approved for Swift but did not make today’s cutoff. Some of these proposals have implementations actively underway. For those proposals already in active development — and near completion — I am okay with extending the deadline for those changes to Friday, July 29. Such changes need to be approved by the release manager (myself) and should be merged into master via a pull request. When creating the pull request, please assign it to me (tkremenek), and mention the pull request on the swift-dev mailing list as well with the SE number in the email title.</p>
<p>The rest of the unimplemented proposals do not make Swift 3. This leaves us with the question of what to do with them. These proposals represent the known and reviewed changes we want to make to Swift, but inevitably there will also be changes that we don’t even know about today that we will want to take into Swift that can impact core source stability. That said, we also have a very strong desire to maintain source compatibility with Swift 3 and Swift 4 as much as possible to provide some stability for which Swift users to build upon. The challenge of course is reconciling these diametrically opposing goals: maintaining source stability while having the ability to incorporate more core (and important) language changes that are possibly source-breaking.</p>
<p>The Swift team at Apple has reflected on this and decided what it “means” for Swift 3 to be source compatible with Swift 4 and later releases going forward. Our goal is to allow app developers to combine a mix of Swift modules (e.g., SwiftPM packages), where each module is known to compile with a specific version of the language (module A works with Swift 3, module B works with Swift 3.1, etc.), then combine those modules into a single binary. The key feature is that a module can be migrated from Swift 3 to 3.1 to 4 (and beyond) independently of its dependencies.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000264.html">continue reading full email</a>…</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/756233032512573440">they always get this wrong</a>. 😂</p>
Issue #31
https://swiftweeklybrief.com/issue-31
2016-07-21T00:00:00-07:00
2016-07-21T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #31! <a href="https://developer.apple.com/news/?id=07182016a">Beta 3</a> of Xcode and all the platforms are now available. The most important news this week was Ted Kremenek’s email on the <em>endgame for Swift 3</em> (see below). The last day for Swift 3 breaking changes is July 27, and discussions on Swift 4 will begin August 1. Moving fast! 😱</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1266">SR-1266</a>: Fix duplication of <code class="language-plaintext highlighter-rouge">@VARIABLES@</code> in <code class="language-plaintext highlighter-rouge">test</code> and <code class="language-plaintext highlighter-rouge">validation-test</code>. This starter task is from April, but it <a href="https://github.com/apple/swift/pull/3577#issuecomment-233464806">continues to cause pain</a> for Swift compiler developers today. The goal of this task is to make it easier for developers to modify the variables being passed to the Swift test suite – developers currently need to modify two files in two different parts of the codebase. Completing this task would reduce that down to just one file. Basic knowledge of Python would be helpful in completing this task, but is not necessary.</li>
<li><a href="https://bugs.swift.org/browse/SR-2117">SR-2117</a>: Add documentation for SourceKit request types. SourceKit has a lot of functionality that could be very useful when building developer tools for Swift, but very little documentation on how to use those tools. The goal for this task is to use SourceKit, see what it does, and document its behavior. Being able to read the C++ source code for SourceKit would help, but is not required.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="community">Community</h3>
<p>Brian Gesiak has <a href="http://modocache.io/nuclide-swift-ide">hacked together</a> Swift support for the <a href="https://nuclide.io">Nuclide</a> IDE! 🤓 It’s still a work-in-progress and you couldn’t replace Xcode yet, but if you’re looking for a Swift IDE on Linux, this will be <a href="https://github.com/facebook/nuclide/pull/621">ready soon</a>. 👌</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Jacob Bandes-Storch <a href="https://github.com/apple/swift-evolution/pull/433">merged</a> his work on the new <a href="http://apple.github.io/swift-evolution/">proposal status page</a> for swift-evolution. Fancy! ✨</p>
<p>JP Simard is continuing the work of porting SourceKit to Linux. Building Swift from source <a href="https://github.com/apple/swift/pull/3595">now builds</a> Brian Croom’s in-process implementation of sourcekitd, and will soon <a href="https://github.com/apple/swift/pull/3594">link it against libdispatch</a>.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md">SE-0095</a>, which replaces <code class="language-plaintext highlighter-rouge">protocol<P1,P2></code> syntax with <code class="language-plaintext highlighter-rouge">P1 & P2</code> syntax, has been <a href="https://github.com/apple/swift/commit/a6dad0091bbb099b1c44d691204b5861e3332a1d">implemented</a> by Josef Willsher.</p>
<p><a href="https://github.com/apple/swift-evolution/blob/37ca495862e07ea7cc13c72b934a85501710bf78/proposals/0109-remove-boolean.md">SE-0109</a>, which removes the <code class="language-plaintext highlighter-rouge">Boolean</code> protocol, has been <a href="https://github.com/apple/swift/pull/3567">implemented</a>. Usages of <code class="language-plaintext highlighter-rouge">Boolean</code> in the core libraries have been <a href="https://github.com/apple/swift-corelibs-xctest/commit/544608dbf891326f254bb8d048267aa29247742c">replaced</a> with <code class="language-plaintext highlighter-rouge">Bool</code>.</p>
<p>Russ Bishop <a href="https://github.com/apple/swift/pull/3600">started work</a> on implementing <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md">SE-0045</a>, which adds <code class="language-plaintext highlighter-rouge">prefix(while:)</code> and <code class="language-plaintext highlighter-rouge">drop(while:)</code> to the stdlib.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0124-bitpattern-label-for-int-initializer-objectidentfier.md">SE-0124</a>: <em><code class="language-plaintext highlighter-rouge">Int.init(ObjectIdentifier)</code> and <code class="language-plaintext highlighter-rouge">UInt.init(ObjectIdentifier)</code> should have a <code class="language-plaintext highlighter-rouge">bitPattern:</code> label</em> from Arnold Schwaighofer was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000237.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000241.html">accepted</a>.</p>
<blockquote>
<p>There was very sparse commentary, and all of it was positive. The core team believes this is an “obvious” proposal.</p>
<p>Thank you to Arnold Schwaighofer for proposing this cleanup!</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md">SE-0120</a>: <em>Revise <code class="language-plaintext highlighter-rouge">partition</code> Method Signature</em> from Lorenzo Racca, Jeff Hajewski, and Nate Cook was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000242.html">accepted</a>.</p>
<blockquote>
<p>There was very sparse commentary, and all of it was positive. The one requested change from the discussion is to remove <code class="language-plaintext highlighter-rouge">@discardableResult</code>, which has already been made to the proposal.</p>
<p>Thank you to Lorenzo Racca, Jeff Hajewski, and Nate Cook for proposing this cleanup!</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md">SE-0116</a>: <em>Import Objective-C <code class="language-plaintext highlighter-rouge">id</code> as Swift <code class="language-plaintext highlighter-rouge">Any</code> type</em> from Joe Groff was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000243.html">accepted</a>.</p>
<blockquote>
<p>The proposal has been <em>accepted</em>, pending more implementation experience: This proposal was very positively received by the community, and garnered a lot of feedback (which has already been incorporated into the proposal). This proposal has significant implementation complexity, but the work to build it is nearing completion. When this lands, there is some risk that we’ll need to revise the design in small ways due to unanticipated effects, but the core team believes it is the right overall design to aim for.</p>
<p>Thank you to Joe Groff for driving the design and discussion around this feature, as well as many people who are contributing to the implementation and design effort.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md">SE-0101</a>: <em>Reconfiguring <code class="language-plaintext highlighter-rouge">sizeof</code> and related functions into a unified <code class="language-plaintext highlighter-rouge">MemoryLayout</code> struct</em> from Erica Sadun and Dave Abrahams was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000244.html">accepted</a>.</p>
<blockquote>
<p>The proposal has been <em>accepted</em>, with a revision to change <code class="language-plaintext highlighter-rouge">MemoryLayout</code> into an <code class="language-plaintext highlighter-rouge">enum</code> with no cases. The overall feedback was very positive. The core team did discuss a proposal to move the generic type to each member, but felt that that would increase the verbosity of using the API (since <code class="language-plaintext highlighter-rouge">T.self</code> would be required) and would lead to possible confusion in the API (because it wouldn’t be clear whether you were asking for the size of a type, or the size of its metatype).</p>
<p>Thank you to Erica Sadun and Dave Abrahams for driving this discussion forward.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md">SE-0121</a>: <em>Remove <code class="language-plaintext highlighter-rouge">Optional</code> Comparison Operators</em> from Jacob Bandes-Storch was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000245.html">accepted</a>.</p>
<blockquote>
<p>Feedback has been universally positive from both the community and the core team, because it eliminates a surprising part of the Swift model at very little utility cost.</p>
<p>Thank you to Jacob Bandes-Storch for driving this discussion forward.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md">SE-0117</a>: <em>Default classes to be non-subclassable publicly</em> from Javier Soto and John McCall was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000234.html">returned for revision</a>. The proposal then had a <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000236.html">second review</a>, after which it was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000247.html">returned for revision</a> <em>again</em>. 😄</p>
<p>From the <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000234.html">first</a> return:</p>
<blockquote>
<p>As expected, this proposal was extremely polarizing, with valid arguments on both sides. The opinions held by supporters and opposers are held very strongly, and hundreds of emails were generated in a healthy debate about this topic.</p>
<p>The review manager read every post on this topic, and the core team discussed this topic at length. The core team concluded three things:</p>
<ul>
<li>First, the core team <em>agrees with conviction</em> that it is the right default for public classes to be non-subclassable outside their module, unless they carry some additional indication from the API author that the class was designed to be subclassed.</li>
<li>Second, there was insufficient discussion about anything <em>other</em> than the first point. The proposal also contains the “overridable” concept, which is highly impactful, but lacked significant discussion.</li>
<li>Third, the core team agrees that the concrete syntax of “subclassable class” is … suboptimal.</li>
</ul>
<p>On the first point, there are three related arguments against SE-0117:</p>
<ul>
<li>First is that clients of Apple frameworks often choose to subclass classes that Apple publicly documents as being “not for subclassing”, as a way of “getting their job done,” typically as a way to work around claimed bugs in Apple frameworks. The core team and others at Apple feel that this argument is analogous to the argument that Swift should “support method swizzling by default”. Swift loves dynamic features, but has already taken a stance against unanticipated method swizzling, by requiring an API author to indicate where they allow method swizzling with the ‘dynamic’ keyword. Almost all classes vended by Apple APIs are subclassable (which isn’t changed by this proposal) so this argument is not compelling to the core team, nor is it consistent with the existing design of Swift. It is also important to note that Cocoa also makes heavy use of delegation (via protocols) which allows client code to customize framework behavior without subclassing.</li>
<li>Second is that clients of some other public API vended by a non-Apple framework (e.g. a SwiftPM package) may end up in a situation where the framework author didn’t consider subclass-ability, but the client desires it. In this situation, the core team feels that a bigger problem happened: the vendor of the framework did not completely consider the use cases of the framework. This might have happened due to the framework not using sufficient black box unit testing, a failure of the imagination of the designer in terms of use cases, or because they have a bug in their framework that needs unanticipated subclass-ability in order to “get a job done”. Similar to the first point, the core team feels that the language is not the right place to solve this problem. Instead, there is a simple and general solution: communicate with the framework author and get them to add the capabilities that you desire. If they simply need to add subclass-ability, then that is no problem: it is a source-compatible change to a dependency.</li>
<li>Third is a longer-term meta-concern, wherein a few people are concerned that future pure-Swift APIs will not consider subclass-ability in their design and will accidentally choose-by-omission to prevent subclass-ability on a future pure-Swift API (vended by Apple or otherwise). The core team feels that this is an extremely unlikely situation for several reasons. First of which is that it heavily overlaps the first two concerns. More significantly, any newly-designed and from-scratch APIs that are intended for Swift-only clients will make use of a breadth of abstractions supported by Swift—structs, enums, protocols, classes. The primary reasons to use classes in Swift are subclassability and reference semantics, so the core team feels that the likelihood of accidental omission is small. Likewise, the decision to require every member of a public class to be marked public in Swift indicates a commitment (in line with SE-0117) that expects cross-module API authors to think carefully about the API they are authoring as well as their use cases.</li>
</ul>
<p>To reiterate, as a summary, the core team <em>agrees with conviction</em> that it is the right default for public classes to be non-subclassable outside their module, unless they carry some additional indication by the API author that the class was designed to be subclassed. However, it does not yet have an opinion as to what that concrete syntax is.</p>
<p>To sum this all up, the core team is rejecting this proposal and requesting a revision to change the concrete syntax to <code class="language-plaintext highlighter-rouge">public open class Foo</code> instead of <code class="language-plaintext highlighter-rouge">subclassable class Foo</code>. This approach satisfies the <em>unwavering</em> goal of requiring additional thought when publishing a class as public API, makes subclass-ability orthogonal to access control, and (admittedly as a bit of a swift-evolution process hack) asks the community for an in-depth discussion of the secondary points of the proposal: does it make sense to require every member to be marked as <code class="language-plaintext highlighter-rouge">overridable</code> in order to be overridden by an open subclass outside of the current module?</p>
<p>The core team appreciates that this is a situation where it is impossible to please everyone, while also recognizing that the challenges faced by developers of pure-Swift code are not exactly analogous to those faced by Objective-C developers. Thank you to the many and diverse opinions and perspectives that have come in as part of this review cycle!</p>
</blockquote>
<p>From the <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000247.html">second</a> return:</p>
<blockquote>
<p>As with the first round of discussion, the community generated a large number of emails, exploring the various aspects of the proposal. While many community members agree with the thrust of the proposal, a number of people are concerned with the boilerplate being introduced by the proposal, among other issues. The core team spent over two and a half hours discussing this topic from first principles, and has come up with a similar-but-different approach that should reduce the boilerplate, while still accomplishing the primary aims of the proposal. John McCall will be revising the proposal today and we’ll restart a short discussion period about it tomorrow.</p>
<p>Thank you to Javier Soto and John McCall for driving this discussion forward.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md">SE-0123</a>: <em>Disallow coercion to optionals in operator arguments</em> from Mark Lacey, Doug Gregor, and Jacob Bandes-Storch was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000246.html">rejected</a>.</p>
<blockquote>
<p>The majority of the feedback on this proposal was opposed to it. While the goal of the proposal is laudable, SE-0121 eliminated the most surprising problem that this proposal aimed to address, and the rest of it (notably the <code class="language-plaintext highlighter-rouge">??</code> operator) can be addressed in other ways in the Swift 3 timeframe. The core team recommends that the <code class="language-plaintext highlighter-rouge">??</code> case be handled by having the compiler produce a warning when the left side of the <code class="language-plaintext highlighter-rouge">??</code> operator is implicitly promoted to optional. In the post-Swift 3 timeframe, we can investigate other broader options for solving this problem more generally (e.g. a new parameter attribute).</p>
<p>Thank you to Mark Lacey, Doug Gregor, and Jacob Bandes-Storch for driving this discussion forward.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md">SE-0122</a>: <em>Use colons for subscript declarations</em> from James Froggatt is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000238.html">under review</a>. Currently, subscripts have the form: <code class="language-plaintext highlighter-rouge">subscript(param: P) -> ElementType</code>. James argues that the similarities between subscript and function declarations can cause confusion.</p>
<blockquote>
<p>The arrow, borrowed from function syntax, is very much out of place in this context, and so can act as a mental stumbling block. It is also misleading, as it implies that subscripts have the full capabilities of functions, such as the ability to throw. If throwing functionality were to be added to accessors, it is likely the specific get/set accessor would be annotated. In this case, the effects on a subscript’s ‘function signature’ could become a source of confusion.</p>
<p>Subscripts act like parameterised property accessors. This means, like a property, they can appear on the left hand side of an assignment, and values accessed through subscripts can be mutated in-place. The colon has precedent in declaring this kind of construct, so it makes sense to reuse it here.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0125-remove-nonobjectivecbase.md">SE-0125</a>: <em>Remove <code class="language-plaintext highlighter-rouge">NonObjectiveCBase</code> and <code class="language-plaintext highlighter-rouge">isUniquelyReferenced</code></em> from Arnold Schwaighofer is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000239.html">under review</a>.</p>
<blockquote>
<p>Remove <code class="language-plaintext highlighter-rouge">NonObjectiveCBase</code> and <code class="language-plaintext highlighter-rouge">isUniquelyReferenced<T: NonObjectiveCBase>(_ object: T)</code>. <code class="language-plaintext highlighter-rouge">isUniquelyReferenced</code> can be replaced by <code class="language-plaintext highlighter-rouge">isUniquelyReferencedNonObjC<T: AnyObject>(_ object: T)</code>. This replacement is as performant as the call to <code class="language-plaintext highlighter-rouge">isUniquelyReferenced</code> in cases where the compiler has static knowledge that the type of <code class="language-plaintext highlighter-rouge">object</code> is a native Swift class and dyamically has the same semantics for native swift classes. This change will remove surface API.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0126-refactor-metatypes-repurpose-t-dot-self-and-mirror.md">SE-0126</a>: <em>Refactor Metatypes, repurpose <code class="language-plaintext highlighter-rouge">T.self</code> and <code class="language-plaintext highlighter-rouge">Mirror</code></em> from Adrian Zubarev and Anton Zhilin is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000240.html">under review</a>.</p>
<blockquote>
<p>This proposal wants to revise metatypes <code class="language-plaintext highlighter-rouge">T.Type</code>, repurpose <em>public</em> <code class="language-plaintext highlighter-rouge">T.self</code> notation to return a new <code class="language-plaintext highlighter-rouge">Type<T></code> type instance rather than a metatype, merge <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md">SE-0101</a> into <code class="language-plaintext highlighter-rouge">Type<T></code>, rename the global function from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md">SE-0096</a> to match the changes of this proposal and finally rename current <code class="language-plaintext highlighter-rouge">Mirror</code> type to introduce a new (lazy) <code class="language-plaintext highlighter-rouge">Mirror</code> type.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0127-cleaning-up-stdlib-ptr-buffer.md">SE-0127</a>: <em>Cleaning up stdlib Pointer and Buffer Routines</em> from Charlie Monroe is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000248.html">under review</a>.</p>
<blockquote>
<p>This proposal deals with three routines and one class related to pointers and buffers. The goal of this proposal is to update the API to match new API guidelines and remove redundant identifiers.</p>
<p>The stdlib has been thoroughly updated to follow the new API guidelines and these are the few places that need to be updated in pointer and buffer APIs…</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000235.html">sent an email</a> on the <em>endgame for Swift 3</em>, highlighting the development plans for the release and the proposals that have not yet been completed.</p>
<blockquote>
<p>Swift 3 has shaped up to be a remarkable release — a product of the inspiration, ideas, and hard labor many people from across the Swift open source community. It is now time, however, to talk about the endgame for the release.</p>
<p>Here are the key points:</p>
<p>The last day to take planned source-breaking changes for Swift 3 is July 27.</p>
<p>On that day, there will likely be a set of approved-but-not-implemented proposals for Swift 3 — including proposals for source-breaking changes. Will have an open discussion on that day on the fate of those unimplemented proposals in the context of Swift 3 and future Swift releases.</p>
<p>Starting on August 1 we will open up discussion about Swift 4. Part of this discussion will likely be guided by important work that was deferred from Swift 3, as well as the a goal of achieving binary stability in Swift 4. Until then, however, discussion should remain focused on Swift 3.</p>
<p>Note that there is an intentional gap of a few days between the last planned day to take source-breaking changes for Swift 3 and when we start talking about Swift 4. The idea is to provide some time for the community to take stock of where things have ended up for Swift 3.</p>
<p>The final branching plan for Swift 3 development is to be determined, but the final convergence branch is likely to be cut from master around that date or shortly after. Part of it comes down to the discussion on July 27 on how to handle the remaining unimplemented proposals for Swift 3.</p>
<p>The final release date for Swift 3 is TBD, but essentially after July 27 the intent is that Swift 3 is in full convergence and not in active development.</p>
<p>With these dates in mind, I want to call attention to some approved-but-not-yet-implemented proposals that currently I have nobody on Apple’s Swift team able to tackle in the next couple weeks: …</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://github.com/apple/swift/commit/af30ae32226813ec14c2bef80cb090d3e6c586fb">“We still love you George, even if we forgot your e.”</a> 😄</p>
<p>(If you aren’t familiar, this is a reference to <a href="https://en.wikipedia.org/wiki/George_Boole">George Boole</a>.)</p>
Issue #30
https://swiftweeklybrief.com/issue-30
2016-07-14T00:00:00-07:00
2016-07-14T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #30! Swift <a href="https://github.com/apple/swift/milestone/4?closed=1">preview 3.0</a> is underway, and the Core Team is still pushing through <strong>tons</strong> of Swift evolution proposals — it’s amazing, and slightly overwhelming! 😅 Because of this, I’m not going to dive too deep into the mailing lists, just like last week.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-2025">SR-2025</a>: [SwiftPM] “swift build” usage text should specify defaults</li>
<li><a href="https://bugs.swift.org/browse/SR-2022">SR-2022</a>: [Compiler] Improve the fixit for type checking in switch statements</li>
<li><a href="https://bugs.swift.org/browse/SR-1894">SR-1894</a>: [Compiler] Return type of <code class="language-plaintext highlighter-rouge">NSCoding.Protocol</code> is considered ObjC-compatible, but crashes</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="community">Community</h3>
<p><a href="https://twitter.com/slava_pestov">Slava Pestov</a> wrote two excellent (unofficial) blog posts this week on the Swift compiler type system. These are the first of what will be a four-part series, so stay tuned. Each post is extremely well-written and incredibly thorough. If you have any interest in the Swift compiler, you should read these. Oh, and be sure to say thanks to <a href="https://twitter.com/slava_pestov">Slava</a>! 🙌</p>
<ul>
<li>Part 1: <a href="https://medium.com/@slavapestov/the-secret-life-of-types-in-swift-ff83c3c000a5#.li1oxk4nk">The secret life of types in Swift</a></li>
<li>Part 2: <a href="https://medium.com/@slavapestov/how-to-talk-to-your-kids-about-sil-type-use-6b45f7595f43#.uxcykx4kx">How to talk to your kids about SIL type use</a></li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/3404">implemented</a> changes for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scope Access Level</em> (<code class="language-plaintext highlighter-rouge">private</code> and <code class="language-plaintext highlighter-rouge">fileprivate</code>) that allow public members inside internal types.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/3459">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md">SE-0112</a>: <em>Improved <code class="language-plaintext highlighter-rouge">NSError</code> Bridging</em>.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/3475">added</a> preliminary SILGen and runtime support for importing Objective-C <code class="language-plaintext highlighter-rouge">id</code> as Swift <code class="language-plaintext highlighter-rouge">Any</code>.</p>
<p>Jordan Rose <a href="https://github.com/apple/swift-corelibs-foundation/pull/445">updated</a> corelibs-foundation for proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scope Access Level</em> (<code class="language-plaintext highlighter-rouge">private</code> and <code class="language-plaintext highlighter-rouge">fileprivate</code>).</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Matthew Johnson’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md">SE-0115</a>: <em>Rename Literal Syntax Protocols</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000220.html">accepted</a>.</p>
<blockquote>
<p>The community and core team agree that this proposal is a better set of names for these protocols. The core team agrees with the community sentiment that “By” is better than “As” in the protocol names, and has accepted the proposal with this revision.</p>
<p>Thank you to Matthew Johnson and many others for driving this discussion forward!</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0114-buffer-naming.md">SE-0114</a>: <em>Updating Buffer “Value” Names to “Header” Names</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000221.html">accepted</a>.</p>
<blockquote>
<p>The community discussion and core team unanimously agree that this is the right thing to do.</p>
<p>Thank you to Erica Sadun for driving this discussion forward!</p>
</blockquote>
<p>The second version of Anton Zhilin’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md">SE-0077</a>: <em>Improved operator declarations</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000219.html">accepted</a> with minor revisions.</p>
<blockquote>
<p>This round of feedback focused on naming, both of the attributes for precedence groups and the conventions to use for naming the groups themselves:</p>
<ul>
<li>
<p>The community expressed a strong preference for ‘higherThan’ and ‘lowerThan’ precedence relationships over the previously-proposed ‘strongerThan’ and ‘weakerThan’, and the core team <em>agrees</em> that these are better terms of art. The proposal is accepted with these terms revised.</p>
</li>
<li>
<p>The standard library team reviewed the proposed names for the standard precedence groups, and suggests the following minor naming revisions:</p>
<ul>
<li>AssignmentPrecedence</li>
<li>TernaryPrecedence</li>
<li>DefaultPrecedence</li>
<li>LogicalDisjunctionPrecedence</li>
<li>LogicalConjunctionPrecedence</li>
<li>ComparisonPrecedence</li>
<li>NilCoalescingPrecedence</li>
<li>CastingPrecedence</li>
<li>RangeFormationPrecedence</li>
<li>AdditionPrecedence</li>
<li>MultiplicationPrecedence</li>
<li>BitwiseShiftPrecedence</li>
</ul>
</li>
</ul>
<p>establishing a convention of <Noun>Precedence for precedence group names. The core team accepts the proposal with these revised standard precedence names.</p>
<p>Thanks Anton for shepherding this proposal through the review process!</p>
</blockquote>
<p>Doug Gregor’s and Charles Srstka’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md">SE-0112</a>: <em>Improved <code class="language-plaintext highlighter-rouge">NSError</code> Bridging</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000222.html">accepted</a>.</p>
<blockquote>
<p>The community and core team agree that this proposal is a huge step forward that enriches the experience working with and extending the Cocoa <code class="language-plaintext highlighter-rouge">NSError</code> model in Swift. The core team requests one minor renaming of “attemptRecovery(optionIndex:andThen:)” to “attemptRecovery(optionIndex:resultHandler:)”. It also discussed renaming <code class="language-plaintext highlighter-rouge">CustomNSError</code> and <code class="language-plaintext highlighter-rouge">RecoverableError</code>, but decided to stay with those names.</p>
<p>Thank you to Doug Gregor and Charles Srstka for driving this discussion forward, and for Doug Gregor taking the charge on the implementation effort to make this happen for Swift 3!</p>
</blockquote>
<p>Anton Zhilin’s and Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md">SE-0109</a>: <em>Remove the <code class="language-plaintext highlighter-rouge">Boolean</code> protocol</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000228.html">accepted</a>.</p>
<blockquote>
<p>The community and core team are overall positive on the removal of the Boolean protocol, under the rationale that it is not pulling its weight and its name is confusing next to Bool. Several members of the core team and a member of the community points out that the <em>functionality</em> provided by the Boolean protocol could make sense for Swift if a well-considered design was available, but the core team feels that we should remove Boolean for Swift 3, and consider adding back a replacement when and if a compelling use-case presents itself to motivate that work.</p>
</blockquote>
<p>Tony Parker’s and Philippe Hausler’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md">SE-0086</a>: <em>Drop NS Prefix in Swift Foundation</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000229.html">accepted</a>.</p>
<blockquote>
<p>This proposal has evolved greatly from a single bullet item in the original proposal for improving the translation of Objective-C APIs (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md">SE-0005</a>: Better Translation of Objective-C APIs Into Swift). Discussion spawned the transformative work on Foundation value types (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md">SE-0069</a>: Mutability and Foundation Value Types), and other improvements to the mapping of Objective-C APIs into Swift (e.g., <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md">SE-0033</a>: Import Objective-C Constants as Swift Types, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md">SE-0044</a>: Import as Member, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md">SE-0112</a>: Improved NSError Bridging) have informed and improved this proposal.</p>
<p>Big thanks to Tony Parker and Philippe Hausler for driving this proposal (and Foundation in Swift) forward!</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md">SE-0118</a>: <em>Closure Parameter Names and Labels</em> from Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000230.html">accepted</a>.</p>
<blockquote>
<p>The proposal has been very well received by the community and core team. The core team agrees with community contributions that <code class="language-plaintext highlighter-rouge">ManagedBuffer<Header,Element>.create(minimumCapacity: 10, makingValueWith: makeHeader)</code> should be renamed to <code class="language-plaintext highlighter-rouge">makingHeaderWith:</code>. The core team extensively discussed the name of <code class="language-plaintext highlighter-rouge">lines.split(whereSeparator: isAllWhitespace)</code> and agreed to keep the name as proposed, because the alternative name <code class="language-plaintext highlighter-rouge">lines.split(where: isAllWhitespace)</code> could be confusing given the behavior of dropping the “separator” from the result.</p>
<p>Thank you to Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev for driving this discussion forward! I filed <a href="https://bugs.swift.org/browse/SR-2072">SR-2072</a> to track implementation of this feature.</p>
</blockquote>
<p>Andrew Trick’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md">SE-0107</a>: <em>UnsafeRawPointer API</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000231.html">accepted</a>.</p>
<blockquote>
<p>The community and core team agree that this proposal clarifies the rules around the unsafe pointer APIs, while making them “work by default” and balance safety and unsafety in an understandable way. Andy has revised the proposal several times due to community feedback (which is why we extended the review period), which makes my job easier because the core team agrees to accept it nearly as-is :-). The only request from the core team is to remove the default value from the “alignedTo:” parameters of the allocate and deallocate methods, forcing their callers to be explicit about the alignment required by an allocation.</p>
<p>Thank you to Andrew Trick for driving this discussion as well as the implementation forward!</p>
</blockquote>
<p>Tony Allevato’s and Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md">SE-0091</a>: <em>Improving operator requirements in protocols</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000232.html">accepted</a>.</p>
<blockquote>
<p>The second iteration of this proposal has been very well received by both the community and core team. The core team requests one minor modification: in an effort to reduce the scope of the proposal, it should specifically require that operator declarations in classes be written as static (or equivalently, as “final class”). In the future, support for operators may be extended to support dynamic dispatch, and the core team wants to keep the design space open. The core team also observed that the impact on the standard library is not captured in this proposal, but that can be incorporated later (as an amendment to this proposal) since it should have little user impact.</p>
<p>Thank you to Tony Allevato and Doug Gregor for driving this discussion forward! I filed <a href="https://bugs.swift.org/browse/SR-2073">SR-2073</a> to track implementation work on this.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Adrian Zubarev’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0119-extensions-access-modifiers.md">SE-0119</a>: <em>Remove access modifiers from extensions</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000223.html">under review</a>.</p>
<blockquote>
<p>One great goal for Swift 3 is to sort out any source breaking language changes. This proposal aims to fix access modifier inconsistency on extensions compared to other scope declarations types.</p>
<p>[…] Extensions however behave differently when it comes to their access control:</p>
<ul>
<li>The access modifier of an extension sets the default modifier of its members which do not have their own locally defined modifier.</li>
<li>Any type members added in an extension have the same default access level as type members declared in the original type being extended.</li>
<li>The access modifier can be overridden by the member with a lower access modifier.</li>
</ul>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0120-revise-partition-method.md">SE-0120</a>: <em>Revise <code class="language-plaintext highlighter-rouge">partition</code> Method Signature</em> from Lorenzo Racca, Jeff Hajewski, and Nate Cook is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000224.html">under review</a>.</p>
<blockquote>
<p>This proposal revises the signature for the collection partition algorithm. Partitioning is a foundational API for sorting and for searching through sorted collections.</p>
<p>The standard library’s current <code class="language-plaintext highlighter-rouge">partition</code> methods, which partition a mutable collection using a binary predicate based on the value of the first element of a collection, are used by the standard library’s sorting algorithm but don’t offer more general partitioning functionality. A more general partition algorithm using a unary (single-argument) predicate would be more flexible and generally useful.</p>
</blockquote>
<p>Jacob Bandes-Storch’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0121-remove-optional-comparison-operators.md">SE-0121</a>: <em>Remove <code class="language-plaintext highlighter-rouge">Optional</code> Comparison Operators</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000225.html">under review</a>.</p>
<blockquote>
<p>Swift’s <code class="language-plaintext highlighter-rouge">Comparable</code> <a href="https://developer.apple.com/reference/swift/comparable">protocol</a> requires 4 operators, <a href="https://github.com/apple/swift/blob/master/stdlib/public/core/Policy.swift#L729-L763"><code class="language-plaintext highlighter-rouge"><</code>, <code class="language-plaintext highlighter-rouge"><=</code>, <code class="language-plaintext highlighter-rouge">></code>, and <code class="language-plaintext highlighter-rouge">>=</code></a>, beyond the requirements of <code class="language-plaintext highlighter-rouge">Equatable</code>.</p>
<p>The standard library <a href="https://github.com/apple/swift/blob/2a545eaa1bfd7d058ef491135cca270bc8e4be5f/stdlib/public/core/Optional.swift#L383-L419">additionally defines</a> the following 4 variants, which accept operands of Optional type, with the semantics that <code class="language-plaintext highlighter-rouge">.none < .some(_)</code>:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">public</span> <span class="kd">func</span> <span class="o"><</span> <span class="o"><</span><span class="kt">T</span> <span class="p">:</span> <span class="kt">Comparable</span><span class="o">></span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?)</span> <span class="o">-></span> <span class="kt">Bool</span>
<span class="kd">public</span> <span class="kd">func</span> <span class="o">></span> <span class="o"><</span><span class="kt">T</span> <span class="p">:</span> <span class="kt">Comparable</span><span class="o">></span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?)</span> <span class="o">-></span> <span class="kt">Bool</span>
<span class="kd">public</span> <span class="kd">func</span> <span class="o"><=</span> <span class="o"><</span><span class="kt">T</span> <span class="p">:</span> <span class="kt">Comparable</span><span class="o">></span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?)</span> <span class="o">-></span> <span class="kt">Bool</span>
<span class="kd">public</span> <span class="kd">func</span> <span class="o">>=</span> <span class="o"><</span><span class="kt">T</span> <span class="p">:</span> <span class="kt">Comparable</span><span class="o">></span><span class="p">(</span><span class="nv">lhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?,</span> <span class="nv">rhs</span><span class="p">:</span> <span class="kt">T</span><span class="p">?)</span> <span class="o">-></span> <span class="kt">Bool</span></code></pre></figure>
<blockquote>
<p>This proposal removes the above 4 functions.</p>
</blockquote>
<p>Erica Sadun’s and Dave Abrahams’ proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md">SE-0101</a>: <em>Reconfiguring <code class="language-plaintext highlighter-rouge">sizeof</code> and related functions into a unified <code class="language-plaintext highlighter-rouge">MemoryLayout</code> struct</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000226.html">under review</a> for the second time.</p>
<blockquote>
<p>This proposal addresses <code class="language-plaintext highlighter-rouge">sizeof</code>, <code class="language-plaintext highlighter-rouge">sizeofValue</code>, <code class="language-plaintext highlighter-rouge">strideof</code>, <code class="language-plaintext highlighter-rouge">strideofValue</code>, <code class="language-plaintext highlighter-rouge">align</code>, and <code class="language-plaintext highlighter-rouge">alignOf</code>. It discards the value-style standalone functions and combines the remaining items into a unified structure.</p>
<p>Although <code class="language-plaintext highlighter-rouge">sizeof()</code>, etc are treated as terms of art, these names are appropriated from C. The functions do not correspond to anything named <code class="language-plaintext highlighter-rouge">sizeof</code> in LLVM. Swift’s six freestanding memory functions increase the API surface area while providing lightly-used and unsafe functionality.</p>
<p>These APIs are not like <code class="language-plaintext highlighter-rouge">map</code>, <code class="language-plaintext highlighter-rouge">filter</code>, and <code class="language-plaintext highlighter-rouge">Dictionary</code>. They’re specialty items that you should only reach for when performing unsafe operations, mostly inside the guts of higher-level constructs.</p>
<p>Refactoring this proposal to use a single namespace increases discoverability, provides a single entry point for related operations, and enables future expansions without introducing further freestanding functions.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0123-disallow-value-to-optional-coercion-in-operator-arguments.md">SE-0123</a>: <em>Disallow coercion to optionals in operator arguments</em> from Mark Lacey, Doug Gregor, and Jacob Bandes-Storch is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000227.html">under review</a>.</p>
<blockquote>
<p>Swift provides syntactic sugar for declaring and using them (for example, <code class="language-plaintext highlighter-rouge">T?</code> to declare an <code class="language-plaintext highlighter-rouge">Optional<T></code>). As another convenience, Swift provides coercion of non-optional types to optional types…</p>
<p>The convenience of coercing values to optionals is very nice in the context of normal function calls, but in the context of operators, it can lead to some strange and unexpected behavior.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Chris Lattner provided <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html">an update</a> and in-depth commentary on the status of proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md">SE-0111</a>: <em>Remove type system significance of function argument labels</em>. It’s a lengthy email, but worth reading.</p>
<blockquote>
<p>Shortly after SE-0111 was accepted last week, several people newly noticed the proposal and started a discussion about how it appears to be a regression for closure parameters (e.g. callbacks) that could formerly carry labels, but are now not allowed to. These folks observed that it would be more expressive (and consistent with the rest of Swift) to allow parameter labels in function types, because the invocation site of a closure “should” be required to provide those labels. The core team has been following the discussion, agrees that this is a concern, and wants to update the community with a path forward.</p>
<p>The reality of the situation is that the current implementation of parameter labels in function types is inherently broken. Specifically, as one example, there is an implicit conversion from <code class="language-plaintext highlighter-rouge">(a: Int) -> Int</code> to <code class="language-plaintext highlighter-rouge">(Int) -> Int</code>. However, there is also an implicit conversion from <code class="language-plaintext highlighter-rouge">(Int) -> Int</code> to <code class="language-plaintext highlighter-rouge">(b : Int) -> Int</code>. This means that the compiler currently allows converting from <code class="language-plaintext highlighter-rouge">(a: Int) -> Int</code> to <code class="language-plaintext highlighter-rouge">(b: Int) -> Int</code>, which doesn’t make sense, introduces surprising behavior, introduces complexity into the compiler implementation, and is generally a problem. We do have one specific hack to prevent conversion of (e.g.) <code class="language-plaintext highlighter-rouge">(a : Int, b : Int) -> Void</code> to <code class="language-plaintext highlighter-rouge">(b : Int, a : Int) -> Void</code>, but this only triggers in specific cases. There are other more complex cases as well, e.g. when using generics <code class="language-plaintext highlighter-rouge">T<(a : Int)->Int></code> cannot be considered compatible with <code class="language-plaintext highlighter-rouge">T<(b : Int)->Int></code>.</p>
<p>These problems are what initially motivated SE-0111. However, given the feedback, the core team went back to the drawing board to determine whether: a) SE-0111 by itself is the right long term answer, b) whether there were alternate models that could solve the same problems in a different way, or c) whether SE-0111 was the right first step to “ultimate glory” in the field of closure parameter labels. After a long discussion, and many alternatives considered, the core team believes in c), that SE-0111 (with a minor modification) is the right step for Swift 3, because it paves the way for the right model over the long term.</p>
<p>…..</p>
</blockquote>
<p>Jacob Bandes-Storch <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024336.html">shared</a> a mock up of a new <a href="http://jtbandes.github.io/swift-evolution/">proposal status site</a> that he hacked together. 😎 It’s a work-in-progress and it’s not clear if the main swift-evolution repository will adopt this, but it’s pretty cool! If most of the work can be automated, then I think this is a nice improvement over the current README.</p>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024222.html">replied</a> to a thread about changing Cocoa APIs, reminding us that the Swift open source project does not control Apple’s APIs. If there are issues with using Cocoa from Swift, be sure to file a radar.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/752556978891689987">Check out Swift’s new <em>FiPri</em> district</a>. 😂</p>
Issue #29
https://swiftweeklybrief.com/issue-29
2016-07-07T00:00:00-07:00
2016-07-07T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #29! This week Xcode 8 beta 2 <a href="https://developer.apple.com/news/?id=07052016b">was released</a> and <em>a lot</em> of proposals were reviewed, accepted, or rejected. There are well over 100 proposals now. It’s hard to believe we’ve seen so many in such a relatively short time!</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Patrick Pijnappel <a href="https://github.com/apple/swift/pull/3287">refactored</a> <code class="language-plaintext highlighter-rouge">UTF8.decode(_:)</code> and <code class="language-plaintext highlighter-rouge">UTF16.decode(_:)</code> for speed-ups based on the iterator nil-guarantee introduced in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md">SE-0052</a>. 😎</p>
<p>Harlan Haskins <a href="https://github.com/apple/swift/pull/3335">implemented</a> a fixit for a misplaced <code class="language-plaintext highlighter-rouge">throws</code>, which corrects <code class="language-plaintext highlighter-rouge">func f() -> throws T</code> to <code class="language-plaintext highlighter-rouge">func f() throws -> T</code>. 👌</p>
<p>Ankit Aggarwal opened a <a href="https://github.com/apple/swift-package-manager/pull/460">pull request</a> that proposes a method of executing tests in parallel in SwiftPM. 🎉</p>
<p>Josef Willsher <a href="https://github.com/apple/swift/pull/3293">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md">SE-0095</a>: <em>Replace <code class="language-plaintext highlighter-rouge">protocol<P1,P2></code> syntax with <code class="language-plaintext highlighter-rouge">P1 & P2</code> syntax</em>. 👏</p>
<p><strong>@practicalswift</strong> <a href="https://github.com/apple/swift/pull/3345">found</a> <a href="https://github.com/apple/swift/pull/3359">two more</a> compiler crashers and added test cases for them. 💥</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Trent Nadeau’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md">SE-0103</a>: <em>Make non-escaping closures the default</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000204.html">accepted</a>.</p>
<blockquote>
<p>The proposal is <em>accepted</em> for Swift 3 with a minor revision: instead of a <code class="language-plaintext highlighter-rouge">asUnsafeEscapingClosure(_:)</code> function that removes the <code class="language-plaintext highlighter-rouge">@escaping</code> attribute, the core team prefers a function with this signature (roughly) like:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="n">withoutActuallyEscaping</span><span class="o"><</span><span class="kt">ClosureType</span><span class="p">,</span> <span class="kt">ResultType</span><span class="o">></span><span class="p">(</span><span class="n">_</span> <span class="nv">closure</span><span class="p">:</span> <span class="kt">ClosureType</span><span class="p">,</span> <span class="nv">do</span><span class="p">:</span> <span class="p">(</span><span class="nv">fn</span> <span class="p">:</span> <span class="kd">@escaping</span> <span class="kt">ClosureType</span><span class="p">)</span> <span class="o">-></span> <span class="kt">ResultType</span><span class="p">)</span> <span class="o">-></span> <span class="kt">ResultType</span> <span class="p">{</span>
<span class="c1">// ...</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>This allows one to safely add the <code class="language-plaintext highlighter-rouge">@escaping</code> attribute in situations where a closure is known not to actually escape. For example, in a situation where you might want to use a lazy algorithm, you could use:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="nf">yourFunction</span><span class="p">(</span><span class="nv">fn</span> <span class="p">:</span> <span class="p">(</span><span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Int</span><span class="p">)</span> <span class="p">{</span> <span class="c1">// fn defaults to non-escaping.</span>
<span class="nf">withoutActuallyEscaping</span><span class="p">(</span><span class="n">fn</span><span class="p">)</span> <span class="p">{</span> <span class="n">fn</span> <span class="k">in</span> <span class="c1">// fn is now marked @escaping inside the closure</span>
<span class="o">...</span> <span class="n">somearray</span><span class="o">.</span><span class="kd">lazy</span><span class="o">.</span><span class="nf">map</span><span class="p">(</span><span class="n">fn</span><span class="p">)</span> <span class="c1">// pass fn to something that is notationally @escaping</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>The key to this approach is that the <code class="language-plaintext highlighter-rouge">withoutActuallyEscaping</code> function can verify that the closure has not actually escaped when it completes, providing a safe model for locally adding the <code class="language-plaintext highlighter-rouge">@escaping</code> attribute when needed. The core team believes that the actual implementation of <code class="language-plaintext highlighter-rouge">withoutActuallyEscaping</code> will require some magic, but that it should be implementable.</p>
<p>Many thanks to Trent Nadeau for driving this proposal forward. I filed <a href="https://bugs.swift.org/browse/SR-1952">SR-1952</a> to track implementation of this feature.</p>
</blockquote>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md">SE-0102</a>: <em>Remove <code class="language-plaintext highlighter-rouge">@noreturn</code> attribute and introduce an empty <code class="language-plaintext highlighter-rouge">Never</code> type</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000205.html">accepted</a>.</p>
<blockquote>
<p>The core team <em>accepted</em> the proposal for Swift 3 with a revision to change the name of the type from “NoReturn” to “Never”.</p>
<p>The feedback on the proposal was generally very positive from the community. The only significant concern was from people who felt that merging the concept of “does not return” into the result type of the function conflates two concepts. The core team feels that unifying these concepts overall reduces the surface area of the language by eliminating an obscure (but important) type system concept outright.</p>
<p>The other significant discussion was about the actual name for the “NoReturn” type. The core team enjoyed the community idea of naming it “💥” or ”🔃” but decided that the name lacked clarity. Ultimately the core team agreed with the loud voice of the community that “Never” is the right name for this type.</p>
<p>Thank you to Joe Groff for driving this proposal forward! I filed <a href="https://bugs.swift.org/browse/SR-1953">SR-1953</a> to track implementation of this feature.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> from Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000206.html">accepted</a>.</p>
<blockquote>
<p>The feedback from the community was very positive and contributed a number of improvements to the design of the proposal. The core team has accepted the proposal, subject to the following changes:</p>
<ul>
<li>The <code class="language-plaintext highlighter-rouge">Integer</code> protocol should be renamed to <code class="language-plaintext highlighter-rouge">BinaryInteger</code> to be more accurate and avoid confusion between <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">Integer</code>.</li>
<li>The <code class="language-plaintext highlighter-rouge">FloatingPoint</code> protocol should conform to the <code class="language-plaintext highlighter-rouge">Arithmetic</code> protocol.</li>
<li>Rename the <code class="language-plaintext highlighter-rouge">absoluteValue</code> property to <code class="language-plaintext highlighter-rouge">magnitude</code>, and sink it down to the <code class="language-plaintext highlighter-rouge">Arithmetic</code> protocol.</li>
<li>Eliminate the <code class="language-plaintext highlighter-rouge">AbsoluteValuable</code> protocol, since <code class="language-plaintext highlighter-rouge">abs</code> can now be defined in terms of <code class="language-plaintext highlighter-rouge">Arithmetic</code>.</li>
<li>Rename the <code class="language-plaintext highlighter-rouge">signBitIndex</code> property to <code class="language-plaintext highlighter-rouge">minimumSignedRepresentationBitWidth</code>.</li>
<li>Add a <code class="language-plaintext highlighter-rouge">popcount</code> property requirement to the <code class="language-plaintext highlighter-rouge">FixedWidthInteger</code> protocol.</li>
<li>Change the <code class="language-plaintext highlighter-rouge">countLeadingZeros()</code> member of concrete types to be a <code class="language-plaintext highlighter-rouge">leadingZeros</code> property on <code class="language-plaintext highlighter-rouge">FixedWidthInteger</code>.</li>
<li>Rename <code class="language-plaintext highlighter-rouge">func nthWord(n: Int) -> UInt</code> to <code class="language-plaintext highlighter-rouge">func word(at: Int) -> UInt</code>.</li>
<li>Rename the <code class="language-plaintext highlighter-rouge">and</code>, <code class="language-plaintext highlighter-rouge">or</code>, and <code class="language-plaintext highlighter-rouge">xor</code> members of <code class="language-plaintext highlighter-rouge">FixedWidthInteger</code> to <code class="language-plaintext highlighter-rouge">bitwiseAnd</code>, <code class="language-plaintext highlighter-rouge">bitwiseOr</code> and <code class="language-plaintext highlighter-rouge">bitwiseXor</code>.</li>
<li>Change <code class="language-plaintext highlighter-rouge">doubleWidthMultiply</code> to be a static member, and add a <code class="language-plaintext highlighter-rouge">doubleWidthDivide</code> member as its dual. The latter will return both quotient and remainder of type <code class="language-plaintext highlighter-rouge">Self</code>. Both are to be added to the <code class="language-plaintext highlighter-rouge">FixedWidthInteger</code> protocol.</li>
</ul>
<p>Many thanks to Maxim Moiseev, Dave Abrahams and Dmitri Gribenko for driving this proposal forward, Steve Canon for his important input, and to Maxim Moiseev for driving the implementation work forward.</p>
</blockquote>
<p>Vladimir S. and Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md">SE-0110</a>: <em>Distinguish between single-tuple and multiple-argument function types</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000201.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000215.html">accepted</a>.</p>
<blockquote>
<p>The community and core team agree that this proposal is the right thing to do, and many agree that this could probably have been treated as a bug fix on a previous proposal.</p>
<p>Thank you to Vladimir S. and Austin Zheng for driving this discussion forward! I filed <a href="https://bugs.swift.org/browse/SR-2008">SR-2008</a> to track implementation work on this, this would be a great area for someone interested in the type checker to dive into the Swift compiler.</p>
</blockquote>
<p>SE-0110 proposal summary:</p>
<blockquote>
<p>Swift’s type system should properly distinguish between functions that take one tuple argument, and functions that take multiple arguments.
Right now, the following is possible:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">let</span> <span class="nv">fn1</span> <span class="p">:</span> <span class="p">(</span><span class="kt">Int</span><span class="p">,</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Void</span> <span class="o">=</span> <span class="p">{</span> <span class="n">x</span> <span class="k">in</span>
<span class="c1">// The type of x is the tuple (Int, Int)</span>
<span class="p">}</span>
<span class="k">let</span> <span class="nv">fn2</span> <span class="p">:</span> <span class="p">(</span><span class="kt">Int</span><span class="p">,</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Void</span> <span class="o">=</span> <span class="p">{</span> <span class="n">x</span><span class="p">,</span> <span class="n">y</span> <span class="k">in</span>
<span class="c1">// The type of x is Int, the type of y is Int</span>
<span class="p">}</span></code></pre></figure>
<p>Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0111-remove-arg-label-type-significance.md">SE-0111</a>: <em>Remove type system significance of function argument labels</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000202.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000216.html">accepted</a>.</p>
<blockquote>
<p>The community and core team agree that this proposal will lead to a simplification and clarification of the type system, as well as a more clear user model for parameter labels. In response to community feedback, the core team is accepting the proposal with a revision to allow “purely cosmetic” parameter labels in closure types for documentation (as outlined in the alternatives section). The core team also wants to clarify that a call to a value of closure type would not allow use of any parameter labels, some interpretations thought that “arbitrary” parameter labels could be used.</p>
<p>Thank you to Austin Zheng for driving this discussion forward! I filed <a href="https://bugs.swift.org/browse/SR-2009">SR-2009</a> to track implementation work on this.</p>
</blockquote>
<p>SE-0111 proposal summary:</p>
<blockquote>
<p>Swift’s type system should not allow function argument labels to be expressed as part of a function type.</p>
<p>Right now, argument labels are considered significant by the type system, and the type system establishes subtyping relationships between function types with and without argument labels. Here is an example:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">func</span> <span class="nf">doSomething</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="kt">Int</span><span class="p">,</span> <span class="nv">y</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Bool</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">x</span> <span class="o">==</span> <span class="n">y</span>
<span class="p">}</span>
<span class="k">let</span> <span class="nv">fn1</span> <span class="p">:</span> <span class="p">(</span><span class="kt">Int</span><span class="p">,</span> <span class="kt">Int</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Bool</span> <span class="o">=</span> <span class="n">doSomething</span>
<span class="c1">// Okay</span>
<span class="nf">fn1</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">)</span>
<span class="c1">// fn2's type is actually (x: Int, y: Int) -> Bool</span>
<span class="k">let</span> <span class="nv">fn2</span> <span class="o">=</span> <span class="n">doSomething</span>
<span class="c1">// Okay</span>
<span class="nf">fn2</span><span class="p">(</span><span class="nv">x</span><span class="p">:</span> <span class="mi">1</span><span class="p">,</span> <span class="nv">y</span><span class="p">:</span> <span class="mi">2</span><span class="p">)</span>
<span class="c1">// NOT ALLOWED</span>
<span class="nf">fn2</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="mi">2</span><span class="p">)</span></code></pre></figure>
<blockquote>
<p>As currently implemented, this feature can lead to surprising behavior. Removing this feature simplifies the type system. It also changes the way argument labels are treated to be consistent with how default arguments are treated; that is, tied to a declaration and not part of the type system.</p>
</blockquote>
<p>Karl Wagner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0113-rounding-functions-on-floatingpoint.md">SE-0113</a>: <em>Add integral rounding functions to FloatingPoint</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000207.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000217.html">accepted</a>.</p>
<blockquote>
<p>The community and core team agree that this proposal helps to “round out” the other Swift 3 numerics work. One minor revision is necessary to make the proposal implementable in Swift 3. Since protocol requirements cannot currently have default arguments, the desired behavior should be achieved with two overloads of each operation:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">protocol</span> <span class="kt">FloatingPoint</span> <span class="p">{</span>
<span class="c1">/// Returns a rounded representation of `self`, according to the specified rounding rule.</span>
<span class="kd">func</span> <span class="nf">rounded</span><span class="p">()</span> <span class="o">-></span> <span class="k">Self</span>
<span class="kd">func</span> <span class="nf">rounded</span><span class="p">(</span><span class="n">_</span> <span class="nv">rule</span><span class="p">:</span> <span class="kt">RoundingRule</span><span class="p">)</span> <span class="o">-></span> <span class="k">Self</span>
<span class="c1">/// Mutating form of `rounded`.</span>
<span class="k">mutating</span> <span class="kd">func</span> <span class="nf">round</span><span class="p">()</span>
<span class="k">mutating</span> <span class="kd">func</span> <span class="nf">round</span><span class="p">(</span><span class="n">_</span> <span class="nv">rule</span><span class="p">:</span> <span class="kt">RoundingRule</span><span class="p">)</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>Where the no argument cases can be implemented with a protocol extension that forwards to the single-argument versions.
Thank you to Karl Wagner for driving this discussion forward! I filed <a href="https://bugs.swift.org/browse/SR-2010">SR-2010</a> to track implementation work on this.</p>
</blockquote>
<p>SE-0113 proposal summary:</p>
<blockquote>
<p>The standard library lacks equivalents to the <code class="language-plaintext highlighter-rouge">floor()</code> and <code class="language-plaintext highlighter-rouge">ceil()</code> functions found in the standard libraries of most other languages. Currently, we need to import <code class="language-plaintext highlighter-rouge">Darwin</code> or <code class="language-plaintext highlighter-rouge">Glibc</code> in order to access the C standard library versions.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md">SE-0105</a>: <em>Removing Where Clauses from For-In Loops</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000199.html">rejected</a>.</p>
<blockquote>
<p>The vast majority of the community of the community prefers to keep this language feature, and the core team agrees. Even though ‘where’ is a small bit of syntactic sugar, it improves the expressivity (therefore readability and maintainability) of important loops.</p>
<p>Many thanks to Erica Sadun for driving this discussion and writing the proposal. This proposal was important and fit with an important goal of Swift 3, which is to re-evaluate all of the existing language features to make sure they are a good for the language over the long term.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md">SE-0108</a>: <em>Remove associated type inference</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000214.html">rejected</a>.</p>
<blockquote>
<p>The community and core team agree that removing this feature will impose an unacceptable user experience regression for developers using Swift generics, including important protocols like Collection. While we all seek the simplifications to the compiler internals that the proposal would allow, we will have to consider other approaches to achieving that in subsequent releases.</p>
<p>Thank you to Douglas Gregor and Austin Zheng for driving this discussion forward!</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md">SE-0101</a>: <em>Reconfiguring <code class="language-plaintext highlighter-rouge">sizeof</code> and related functions into a unified <code class="language-plaintext highlighter-rouge">MemoryLayout</code> struct</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000203.html">returned for revision</a>.</p>
<blockquote>
<p>The proposal is <em>returned for revision</em>, with the goal for a revised version to make it into Swift 3. The thread discussing it has already turned towards new ways to express these ideas, so when that thread runs its course we’ll restart review of the revised proposal.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md">SE-0091</a>: <em>Improving operator requirements in protocols</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000209.html">returned for revision</a>.</p>
<blockquote>
<p>While many people were positive about improving lookup of operators, several concerns about introduction of boilerplate were raised. Tony and Doug have discussed it further and plan to revise and resubmit the proposal for another round of review.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Doug Gregor’s and Charles Srstka’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0112-nserror-bridging.md">SE-0112</a>: <em>Improved <code class="language-plaintext highlighter-rouge">NSError</code> Bridging</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000200.html">under review</a>.</p>
<blockquote>
<p>Swift bridges between <code class="language-plaintext highlighter-rouge">ErrorProtocol</code>-conforming types and <code class="language-plaintext highlighter-rouge">NSError</code> so, for example, a Swift <code class="language-plaintext highlighter-rouge">enum</code> that conforms to <code class="language-plaintext highlighter-rouge">ErrorProtocol</code> can be thrown and will be reflected as an <code class="language-plaintext highlighter-rouge">NSError</code> with a suitable domain and code. Moreover, an <code class="language-plaintext highlighter-rouge">NSError</code> produced with that domain and code can be caught as the Swift <code class="language-plaintext highlighter-rouge">enum</code> type, providing round-tripping so that Swift can deal in <code class="language-plaintext highlighter-rouge">ErrorProtocol</code> values while Objective-C deals in <code class="language-plaintext highlighter-rouge">NSError</code> objects.</p>
<p>However, the interoperability is incomplete in a number of ways, which results in Swift programs having to walk a careful line between the <code class="language-plaintext highlighter-rouge">ErrorProtocol</code>-based Swift way and the <code class="language-plaintext highlighter-rouge">NSError</code>-based way. This proposal attempts to bridge those gaps.</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0114-buffer-naming.md">SE-0114</a>: <em>Updating Buffer “Value” Names to “Header” Names</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000208.html">under review</a>.</p>
<blockquote>
<p>This proposal updates parameters and generic type parameters from <code class="language-plaintext highlighter-rouge">value</code> names to <code class="language-plaintext highlighter-rouge">header</code> names for <code class="language-plaintext highlighter-rouge">ManagedBuffer</code>, <code class="language-plaintext highlighter-rouge">ManagedProtoBuffer</code>, and <code class="language-plaintext highlighter-rouge">ManagedBufferPointer</code>.</p>
<p>All user-facing Swift APIs must go through Swift Evolution. While this is a trivial API change with an existing implementation, this formal proposal provides a paper trail as is normal and usual for this process.</p>
</blockquote>
<p>Matthew Johnson’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0115-literal-syntax-protocols.md">SE-0115</a>: <em>Rename Literal Syntax Protocols</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000210.html">under review</a>.</p>
<blockquote>
<p>This proposal renames the <code class="language-plaintext highlighter-rouge">*LiteralConvertible</code> protocols to <code class="language-plaintext highlighter-rouge">ExpressibleAs*Literal</code>.</p>
<p>The standard library currently has protocols that use the term <code class="language-plaintext highlighter-rouge">Convertible</code> in two different ways. The <code class="language-plaintext highlighter-rouge">*LiteralConvertible</code> protocols use the meaning of converting <em>from</em> a literal. The <code class="language-plaintext highlighter-rouge">Custom(Debug)StringConvertible</code> protocols use the meaning of converting <em>to</em> a <code class="language-plaintext highlighter-rouge">String</code>. This causes confusion for developers attempting to name their own protocols following the precedence established by the standard library.</p>
</blockquote>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0116-id-as-any.md">SE-0116</a>: <em>Import Objective-C <code class="language-plaintext highlighter-rouge">id</code> as Swift <code class="language-plaintext highlighter-rouge">Any</code> type</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000211.html">under review</a>.</p>
<blockquote>
<p>Objective-C interfaces that use <code class="language-plaintext highlighter-rouge">id</code> and untyped collections should be imported into Swift as taking the <code class="language-plaintext highlighter-rouge">Any</code> type instead of <code class="language-plaintext highlighter-rouge">AnyObject</code>.</p>
<p>Objective-C’s <code class="language-plaintext highlighter-rouge">id</code> type is currently imported into Swift as <code class="language-plaintext highlighter-rouge">AnyObject</code>. This is the intuitive thing to do, but creates a growing tension between idiomatic Objective-C and Swift code. One of Swift’s defining features is its value types, such as <code class="language-plaintext highlighter-rouge">String</code>, <code class="language-plaintext highlighter-rouge">Array</code>, and <code class="language-plaintext highlighter-rouge">Dictionary</code>, which allow for efficient mutation without the hazards of accidental state sharing prevalent with mutable classes. To interoperate with Objective-C, we transparently <strong>bridge</strong> value types to matching idiomatic Cocoa classes when we know the static types of method parameters and returns. However, this doesn’t help with polymorphic Objective-C interfaces, which to this day are frequently defined in terms of <code class="language-plaintext highlighter-rouge">id</code>. These interfaces come into Swift as <code class="language-plaintext highlighter-rouge">AnyObject</code>, which doesn’t naturally work with value types. To keep the Swift experience using value types with Cocoa feeling idiomatic, we’ve papered over this impedance mismatch via various language mechanisms…</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0118-closure-parameter-names-and-labels.md">SE-0118</a>: <em>Closure Parameter Names and Labels</em> from Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000212.html">under review</a>.</p>
<blockquote>
<p>We propose a revision to the names and argument labels of closure parameters in standard library APIs.</p>
<p>The names and argument labels of the standard library’s closure parameters have been chosen haphazardly, resulting in documentation comments that are inconsistent and often read poorly, and in code completion/documentation that is less helpful than it might be. Because of trailing closure syntax, the choice of argument labels for closures has less impact on use-sites than it might otherwise, but there are many contexts in which labels still do appear, and poorly-chosen labels still hurt readability.</p>
</blockquote>
<p>Javier Soto’s and John McCall’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md">SE-0117</a>: <em>Default classes to be non-subclassable publicly</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000213.html">under review</a>.</p>
<blockquote>
<p>Since Swift 1, marking a class <code class="language-plaintext highlighter-rouge">public</code> provides two different capabilities: it allows other modules to instantiate and use the class, and it also allows other modules to define subclasses of it. This proposal suggests splitting these into two different concepts. This means that marking a class <code class="language-plaintext highlighter-rouge">public</code> allows the class to be <em>used</em> by other modules, but does not allow other modules to define <em>subclasses</em>. In order to subclass from another module, the class would be marked <code class="language-plaintext highlighter-rouge">subclassable</code>.</p>
<p>Relatedly, Swift also conflates two similar concepts for class members (methods, properties, subscripts): <code class="language-plaintext highlighter-rouge">public</code> means that the member may be used by other modules, but also that it may be overriden by subclasses. This proposal introduces a new <code class="language-plaintext highlighter-rouge">overridable</code> modifier, which is used instead of <code class="language-plaintext highlighter-rouge">public</code> on members that are overridable.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ericasadun/status/750527991311011845">“Could you write me a nice reference letter?”</a></p>
Issue #28
https://swiftweeklybrief.com/issue-28
2016-06-30T00:00:00-07:00
2016-06-30T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #28! This week the <a href="https://github.com/apple/swift/tree/swift-3.0-preview-2-branch">Swift 3.0 preview 2 branch</a> was cut on GitHub and there’s a new <a href="https://github.com/apple/swift/pulls?q=milestone%3A%22Swift+3.0+Preview+2%22">milestone</a> tracking pull requests to include.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1894">SR-1894</a>: Return type of <code class="language-plaintext highlighter-rouge">NSCoding.Protocol</code> is considered ObjC-compatible, but crashes</li>
<li><a href="https://bugs.swift.org/browse/SR-1872">SR-1872</a>: Use runloop source in XCTestCase <code class="language-plaintext highlighter-rouge">waitForExpectations(withTimeout:file:line:handler:)</code></li>
<li><a href="https://bugs.swift.org/browse/SR-1840">SR-1840</a>: Calendar <code class="language-plaintext highlighter-rouge">range(of:, start:, interval:, for:)</code> has incorrect type for start parameter</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Saleem Abdulrasool opened a pull request to add <a href="https://github.com/apple/swift/pull/3221">PS4 support</a>.</p>
<p>Rintaro Ishizaki <a href="https://github.com/apple/swift/pull/3184">improved</a> diagnostics for a trailing closure in a condition statement.</p>
<p>Jamal Rogers resolved <a href="https://bugs.swift.org/browse/SR-1048">SR-1048</a>, a longstanding starter task to support building and testing debug and release builds of swift-corelibs-xctest.</p>
<p>Arsen Gasparyan <a href="https://github.com/apple/swift/pull/3212">started</a> implementing proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md">SE-0089</a>: <em>Renaming <code class="language-plaintext highlighter-rouge">String.init<T>(_: T)</code></em>.</p>
<p>Rintaro Ishizaki <a href="https://github.com/apple/swift/pull/3246">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md">SE-0060</a>: Enforcing order of defaulted parameters.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/3178">started work</a> on enabling leaks tracking for the stblib.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0106-rename-osx-to-macos.md">SE-0106</a>: <em>Add a <code class="language-plaintext highlighter-rouge">macOS</code> Alias for the <code class="language-plaintext highlighter-rouge">OSX</code> Platform Configuration Test</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000193.html">accepted</a>.</p>
<blockquote>
<p>The core team is proactively accepting SE-0106 “Add a macOS Alias for the OSX Platform Configuration Test” without a formal review, under the rationale that the proposal is “obvious” and probably should have been treated as a bug fix. Adding aliases for other uses of “OS X” in the language to use macOS are also proactively accepted.</p>
</blockquote>
<p>Adrian Zubarev’s and Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md">SE-0095</a>: <em>Replace <code class="language-plaintext highlighter-rouge">protocol<P1,P2></code> syntax with <code class="language-plaintext highlighter-rouge">P1 & P2</code> syntax</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000198.html">accepted</a>.</p>
<blockquote>
<p>This syntax has been extensively discussed by the community, and is a cornerstone of the “generalized existentials” work for future Swift releases. The community was overall positive on the feature with a few subjective concerns about “&” being tightly associated with bitwise logical operations. The core team believes this will not be contextually confusing since it appears in a type position, between two names that are obviously nominal types (e.g. they are capitalized).</p>
<p>I filed <a href="https://bugs.swift.org/browse/SR-1938">SR-1938</a> to track implementation of this work, this is a somewhat advanced starter project which would be a great place for someone to dive into the parsing logic in Swift.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Andrew Trick’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0107-unsaferawpointer.md">SE-0107</a>: <em>UnsafeRawPointer API</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000194.html">under review</a>.</p>
<blockquote>
<p>Swift enforces type safe access to memory and follows strict aliasing rules. However, code that uses unsafe APIs or imported types can circumvent the language’s natural type safety. […]</p>
<p>Swift already protects against undefined behavior as long as the code does not use “unsafe” constructs. However, <code class="language-plaintext highlighter-rouge">UnsafePointer</code> is an important API for interoperability and building high performance data structures. As such, the rules for safe, well-defined usage of the API should be clear. Currently, it is too easy to use <code class="language-plaintext highlighter-rouge">UnsafePointer</code> improperly.</p>
</blockquote>
<p>Anton Zhilin’s and Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0109-remove-boolean.md">SE-0109</a>: <em>Remove the <code class="language-plaintext highlighter-rouge">Boolean</code> protocol</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000195.html">under review</a>.</p>
<blockquote>
<p>For legacy and historical reasons Swift has supported a protocol named <code class="language-plaintext highlighter-rouge">Boolean</code> for abstracting over different concrete Boolean types. This causes problems primarily because it is pointless and very confusing to newcomers to Swift: is quite different than <code class="language-plaintext highlighter-rouge">Bool</code>, but shows up right next to it in documentation and code completion. Once you know that it is something you don’t want, you constantly ignore it. Boolean values are simple enough that we don’t need a protocol to abstract over multiple concrete implementations.</p>
<p>From a historical perspective, it was a very early solution to the bridging challenge of <code class="language-plaintext highlighter-rouge">BOOL</code> (which comes in as <code class="language-plaintext highlighter-rouge">ObjCBool</code>). In the time since then, Swift has developed a number of more advanced ways to solve these sorts of bridging problems, and <code class="language-plaintext highlighter-rouge">BOOL</code> is already bridged in automatically as <code class="language-plaintext highlighter-rouge">Bool</code> in almost all cases.</p>
<p>Another pragmatic problem with the <code class="language-plaintext highlighter-rouge">Boolean</code> protocol is that it isn’t used consistently in APIs that take Boolean parameters: almost everything takes <code class="language-plaintext highlighter-rouge">Bool</code> concretely. This means that its supposed abstraction isn’t useful. The only significant users are the unary <code class="language-plaintext highlighter-rouge">!</code>, and binary <code class="language-plaintext highlighter-rouge">&&</code> and <code class="language-plaintext highlighter-rouge">||</code> operators.</p>
</blockquote>
<p>Austin Zheng’s and Douglas Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md">SE-0108</a>: <em>Remove associated type inference</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000196.html">under review</a>.</p>
<blockquote>
<p>In Swift, a type <code class="language-plaintext highlighter-rouge">T</code> may choose to conform to a protocol <code class="language-plaintext highlighter-rouge">P</code>, where <code class="language-plaintext highlighter-rouge">P</code> has <a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Generics.html#//apple_ref/doc/uid/TP40014097-CH26-ID189">associated types</a> that may be used in the protocol requirements. If the associated types are used in the requirements, the types that <code class="language-plaintext highlighter-rouge">T</code> chooses to bind those associated types to can currently be inferred by the type checker by examining how <code class="language-plaintext highlighter-rouge">T</code> chooses to implement <code class="language-plaintext highlighter-rouge">P</code>’s requirements.</p>
<p>The main advantage of removing associated type witness inference is that it decreases the complexity of the type checker. Doing so removes the only aspect of Swift that depends upon global type inference. Simplifying the type checker makes it easier to improve the performance and correctness of the type checker code. Given that both are widely acknowledged issues with current versions of Swift, any opportunity for improvement should be carefully considered.</p>
</blockquote>
<p>Anton Zhilin’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md">SE-0077</a>: <em>Improved operator declarations</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000197.html">under review</a> for the second time. The previous rationale <a href="https://github.com/apple/swift-evolution/blob/40c2acad241106e1cfe697d0f75e1855dc9e96d5/proposals/0077-operator-precedence.md#rationale">here</a>.</p>
<blockquote>
<p>In the beginning, operators had nice precedence values: 90, 100, 110, 120, 130, 140, 150, 160.</p>
<p>As time went, new and new operators were introduced. Precedence could not be simply changed, as this would be a breaking change. Ranges got precedence 135, <code class="language-plaintext highlighter-rouge">as</code> got precedence 132. <code class="language-plaintext highlighter-rouge">??</code> had precedence greater than <code class="language-plaintext highlighter-rouge"><</code>, but less than <code class="language-plaintext highlighter-rouge">as</code>, so it had to be given precedence 131.</p>
<p>Now it is not possible to insert any custom operator between <code class="language-plaintext highlighter-rouge"><</code> and <code class="language-plaintext highlighter-rouge">??</code>. It is an inevitable consequence of current design: it will be impossible to insert an operator between two existing ones at some point.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022323.html">started a discussion</a> about the behavior of <code class="language-plaintext highlighter-rouge">@objc</code> on a class. However, it looks like <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022690.html">changes will not be made</a>.</p>
<blockquote>
<p>Hey, all. An engineer at Apple noticed the following behavior:</p>
<ol>
<li><code class="language-plaintext highlighter-rouge">class Foo: NSObject</code> → exposed to Objective-C, Swift-style (mangled) runtime name</li>
<li><code class="language-plaintext highlighter-rouge">@objc class Foo: NSObject</code> → exposed to Objective-C, Swift-style (mangled) runtime name</li>
<li><code class="language-plaintext highlighter-rouge">@objc(Foo) class Foo: NSObject</code> → exposed to Objective-C, unmangled runtime name</li>
</ol>
<p>(and 4. <code class="language-plaintext highlighter-rouge">@objc class Foo</code> → illegal, classes must have ObjC heritage to be <code class="language-plaintext highlighter-rouge">@objc</code>.)</p>
<p>They specifically observed that (1) and (2) have the same behavior, and suggested that maybe (2) should be shorthand for (3).</p>
<p>[…]</p>
</blockquote>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022338.html">proposed a draft</a> proposal for <code class="language-plaintext highlighter-rouge">NSError</code> bridging. These changes would dramatically improve error handling interoperability, which is surprisingly more nuanced than you might expect.</p>
<blockquote>
<p>Swift bridges between <code class="language-plaintext highlighter-rouge">ErrorProtocol</code>-conforming types and <code class="language-plaintext highlighter-rouge">NSError</code> so, for example, a Swift <code class="language-plaintext highlighter-rouge">enum</code> that conforms to <code class="language-plaintext highlighter-rouge">ErrorProtocol</code> can be thrown and will be reflected as an <code class="language-plaintext highlighter-rouge">NSError</code> with a suitable domain and code. Moreover, an <code class="language-plaintext highlighter-rouge">NSError</code> produced with that domain and code can be caught as the Swift <code class="language-plaintext highlighter-rouge">enum</code> type, providing round-tripping so that Swift can deal in <code class="language-plaintext highlighter-rouge">ErrorProtocol</code> values while Objective-C deals in <code class="language-plaintext highlighter-rouge">NSError</code> objects.</p>
<p>However, the interoperability is incomplete in a number of ways, which results in Swift programs having to walk a careful line between the <code class="language-plaintext highlighter-rouge">ErrorProtocol</code>-based Swift way and the <code class="language-plaintext highlighter-rouge">NSError</code>-based way. This proposal attempts to bridge those gaps.</p>
</blockquote>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160627/022362.html">A problem with SE-0025?</a> Jordan Rose and Robert Widmann <a href="https://github.com/apple/swift-evolution/pull/396/files">proposed</a> an amendment to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Access Level</em>. In short, <code class="language-plaintext highlighter-rouge">private</code> types get tricky when you consider nested types. Consider this example:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">class</span> <span class="kt">Outer</span> <span class="p">{</span>
<span class="kd">private</span> <span class="kd">class</span> <span class="kt">Inner</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">value</span> <span class="o">=</span> <span class="mi">0</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">test</span><span class="p">()</span> <span class="p">{</span>
<span class="c1">// Can Outer.test reference Inner's initializer?</span>
<span class="k">let</span> <span class="nv">inner</span> <span class="o">=</span> <span class="kt">Inner</span><span class="p">()</span>
<span class="c1">// Can Outer.test reference Inner's 'value' property?</span>
<span class="nf">print</span><span class="p">(</span><span class="n">inner</span><span class="o">.</span><span class="n">value</span><span class="p">)</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p>A new section in proposal, <em>Complications with private types</em>, explains the behavior of private types in detail.</p>
<h3 id="finally">Finally</h3>
<p>And finally — 🤔 <a href="https://twitter.com/modocache/status/746429457406230528">the Swift compiler is like a lamp</a>… 😂</p>
Issue #27
https://swiftweeklybrief.com/issue-27
2016-06-23T00:00:00-07:00
2016-06-23T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome back to the weekly brief! We had a great week at <a href="https://developer.apple.com/videos/wwdc2016/">WWDC</a> this year! A lot has happened since last issue. The <a href="https://swift.org/blog/swift-3-0-preview-1-released/">first developer preview</a> for Swift 3.0 was announced, as well as <a href="https://swift.org/blog/swift-2-3/">Swift 2.3</a>. Be sure to checkout the official <a href="https://swift.org/migration-guide/">migration guide</a> for moving your Swift 2.x code to Swift 3. Warning: it will be a bit overwhelming, but it will be worth it! Apple also released an <a href="https://developer.apple.com/xcode/">Xcode 8 beta</a>, along with beta OS releases for each of Apple’s platforms. And finally, the <a href="https://itunes.apple.com/gb/book/swift-programming-language/id1002622538?mt=11">Swift Programming Language</a> iBook has been updated for Swift 3 beta. You can also download the <a href="https://swift.org/documentation/">ePub directly</a> from Swift.org.</p>
<p>While there weren’t any surprises for the language itself announced at WWDC, Apple did announce <a href="http://www.apple.com/swift/playgrounds/">playgrounds</a> for iPad! I think we’re all very excited about this. 😄</p>
<p>I was lucky enough to attend the conference and <a href="https://twitter.com/zats/status/743580771143712768">was able to meet</a> most of the Swift Core Team. It was great to meet them in person, as well as <a href="https://twitter.com/KrauseFx/status/745682520415444996">all of</a> the <a href="https://twitter.com/simjp/status/743981049848307712">other developers</a> attending! It was a really great week. Hope to see you next year! 🤓</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1802">SR-1802</a>: Swift <code class="language-plaintext highlighter-rouge">enum</code> cases are exposed to Objective-C with lowercase naming instead of title-case</li>
<li><a href="https://bugs.swift.org/browse/SR-1872">SR-1872</a>: Instead of polling every tenth of a second, modify <code class="language-plaintext highlighter-rouge">XCTestCase.waitForExpectations(withTimeout:file:line:handler:)</code> to use a runloop source. This task can be done entirely in Swift – no C++, Python, or CMake knowledge required. 😊</li>
</ul>
<p>Support for <a href="https://github.com/apple/swift/pull/1714">running the Swift test suite on Android</a> was merged during WWDC, and there are a lot of improvements that can still be made. If you have an Ubuntu 15.10 development environment and an Android device, these may be a great way to get started to contributing to Swift on Android:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1748">SR-1748</a>: Make it possible to run the Swift test suite on an Android emulator, instead of a real device.</li>
<li><a href="https://bugs.swift.org/browse/SR-1749">SR-1749</a>: Allow contributors to run only tests that require an Android device, or all the tests that don’t require one.</li>
<li><a href="https://bugs.swift.org/browse/SR-1835">SR-1835</a>: Fix a test failure that occurs when referencing <code class="language-plaintext highlighter-rouge">stdout</code> on Android.</li>
<li><a href="https://bugs.swift.org/browse/SR-1836">SR-1836</a>: Fix several reflection test failures on Android, by addressing a linker error.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="wwdc-2016">WWDC 2016</h3>
<p>There were a number of sessions at WWDC this year about Swift, LLVM, and related topics. Below are all the videos relevant to this community. There’s something here for everyone, whether you are a beginner, already have commit access to Swift, or just want a refresher on the upcoming changes in Swift 3. Enjoy!</p>
<ul>
<li>Session 207: <a href="https://developer.apple.com/videos/play/wwdc2016/207/">What’s New in Foundation for Swift</a></li>
<li>Session 402: <a href="https://developer.apple.com/videos/play/wwdc2016/402/">What’s New in Swift</a></li>
<li>Session 403: <a href="https://developer.apple.com/videos/play/wwdc2016/403/">Swift API Design Guidelines</a></li>
<li>Session 404: <a href="https://developer.apple.com/videos/play/wwdc2016/404/">Getting Started with Swift</a></li>
<li>Session 405: <a href="https://developer.apple.com/videos/play/wwdc2016/405/">What’s New in LLVM</a></li>
<li>Session 412: <a href="https://developer.apple.com/videos/play/wwdc2016/412/">Thread Sanitizer and Static Analysis</a></li>
<li>Session 415: <a href="https://developer.apple.com/videos/play/wwdc2016/415/">Going Server-side with Swift Open Source</a></li>
<li>Session 416: <a href="https://developer.apple.com/videos/play/wwdc2016/416/">Understanding Swift Performance</a></li>
<li>Session 720: <a href="https://developer.apple.com/videos/play/wwdc2016/720/">Concurrent Programming With GCD in Swift 3</a></li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Brian Gesiak <a href="https://github.com/apple/swift/pull/1714">merged</a> adding Android testing support.</p>
<p>Robert Widmann opened a <a href="https://github.com/apple/swift/pull/3000">pull request</a> to implement the <code class="language-plaintext highlighter-rouge">fileprivate</code> access level from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>.</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/2989">merged</a> changes to prevent treating Swift methods named “init” as Objective-C ARC init methods.</p>
<p>Austin Zheng <a href="https://github.com/apple/swift/pull/3046">rewrote</a> native hashed collection indices to provide a number of improvements to <code class="language-plaintext highlighter-rouge">Dictionary</code> and <code class="language-plaintext highlighter-rouge">Set</code>.</p>
<p>Erica Sadun opened a <a href="https://github.com/apple/swift/pull/3066">pull request</a> that adds a “macOS” alias for conditional compilation blocks.</p>
<p>Daniel Dunbar <a href="https://github.com/apple/swift-package-manager/pull/418">merged</a> changes to SwiftPM to migrate off of <code class="language-plaintext highlighter-rouge">fputs()</code>.</p>
<p>Alsey Coleman Miller <a href="https://github.com/apple/swift-corelibs-foundation/pull/417">implemented</a> the <code class="language-plaintext highlighter-rouge">UUID</code> value type in corelibs-foundation for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md">SE-0069</a>.</p>
<p>Robert Widmann opened a <a href="https://github.com/apple/swift-package-manager/pull/410">pull request</a> on SwiftPM to update for using <code class="language-plaintext highlighter-rouge">fileprivate</code>.</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/392">added</a> C language support in tests for SwiftPM.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/3064">merged</a> work on preliminary SILGen and IRGen support for nested generic types.</p>
<p>Brian Gesiak opened a <a href="https://github.com/apple/swift/pull/3027">pull request</a> to allow <em>only</em> static libraries to be built. This enables more finely grained build options.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Austin Zheng’s and Becca Royal-Gordon’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md">SE-0089</a>: <em>Renaming <code class="language-plaintext highlighter-rouge">String.init<T>(_: T)</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000190.html">accepted</a> for <strong>Swift 3</strong>. 🎉</p>
<blockquote>
<p>The feedback from the community on this second round was light, which indicates that the extensive iteration on earlier rounds brought this to a good place. The core team discussed other possibilities for the parameter label (e.g. from: instead of describing:) but ended up agreeing that a more explicit “describing:” label is the best fit for this API.</p>
<p>Many thanks to Austin Zheng and Becca Royal-Gordon for driving this discussion, iterating on the design, and writing a great proposal! I filed <a href="https://bugs.swift.org/browse/SR-1881">SR-1881</a> to track implementation of this work. This would be a great project for someone who wants to work on the standard library.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p>Anton Zhilin’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md">SE-0077</a>: <em>Improved operator declarations</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000191.html">returned for revisions</a>. The core team outlined a number of issues that they would like addressed in the revision. Follow the link for the rationale if you’d like to read more.</p>
<blockquote>
<p>The core design proposed is a clear win over the Swift 2 design, but the core team feels that revisions are necessary for usability and consistency with the rest of the language…</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0101-standardizing-sizeof-naming.md">SE-0101</a>: <em>Rename <code class="language-plaintext highlighter-rouge">sizeof</code> and related functions to comply with API Guidelines</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000185.html">under review</a>.</p>
<blockquote>
<p>Upon accepting <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md">SE-0096</a>, the core team renamed the proposed stdlib function from <code class="language-plaintext highlighter-rouge">dynamicType()</code> to <code class="language-plaintext highlighter-rouge">type(of:)</code> to better comply with Swift’s API guidelines. This proposal renames <code class="language-plaintext highlighter-rouge">sizeof</code>, <code class="language-plaintext highlighter-rouge">sizeofValue</code>, <code class="language-plaintext highlighter-rouge">strideof</code>, <code class="language-plaintext highlighter-rouge">strideofValue</code>, <code class="language-plaintext highlighter-rouge">align</code>, and <code class="language-plaintext highlighter-rouge">alignOf</code> to emulate SE-0096’s example.</p>
</blockquote>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0102-noreturn-bottom-type.md">SE-0102</a>: <em>Remove <code class="language-plaintext highlighter-rouge">@noreturn</code> attribute and introduce an empty <code class="language-plaintext highlighter-rouge">NoReturn</code> type</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000186.html">under review</a>.</p>
<blockquote>
<p>We should remove the rarely-used <code class="language-plaintext highlighter-rouge">@noreturn</code> function type attribute and instead express functions that don’t return in terms of a standard uninhabited type.</p>
</blockquote>
<p>Trent Nadeau’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0103-make-noescape-default.md">SE-0103</a>: <em>Make non-escaping closures the default</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000187.html">under review</a>.</p>
<blockquote>
<p>The current default of closure arguments to functions (i.e., arguments to functions that themselves have function type such as <code class="language-plaintext highlighter-rouge">(T) -> U</code>) is to be “escaping”, meaning they can escape the function body such as saving it to a field in a struct or a global variable. In order to say that a closure argument cannot possibly escape the function body (“non-escaping”), the developer must explicitly add an <code class="language-plaintext highlighter-rouge">@noescape</code> annotation to the argument type.</p>
<p>This proposal switches the default to be non-escaping and requires an <code class="language-plaintext highlighter-rouge">@escaping</code> annotation if a closure argument can escape the function body. Since the escaping case can be statically detected, this annotation can be added via an error with a fixit. Other annotations that have consequences for escape semantics (e.g., <code class="language-plaintext highlighter-rouge">@autoclosure(escaping)</code>) will be altered to make use of the new <code class="language-plaintext highlighter-rouge">@escaping</code> annotation.</p>
</blockquote>
<p>Adrian Zubarev’s and Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md">SE-0095</a>: <em>Replace <code class="language-plaintext highlighter-rouge">protocol<P1,P2></code> syntax with <code class="language-plaintext highlighter-rouge">P1 & P2</code> syntax</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000188.html">under review</a>.</p>
<blockquote>
<p>The current <code class="language-plaintext highlighter-rouge">protocol<></code> construct, which defines an existential type consisting of zero or more protocols, should be replaced by an infix <code class="language-plaintext highlighter-rouge">&</code> type operator joining bare protocol type names.</p>
</blockquote>
<p>A proposal from Dave Abrahams, Dmitri Gribenko, and Maxim Moiseev, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0104-improved-integers.md">SE-0104</a>: <em>Protocol-oriented integers</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000189.html">under review</a>.</p>
<blockquote>
<p>This proposal cleans up Swifts integer APIs and makes them more useful for generic programming.</p>
<p>Swift’s integer protocols don’t currently provide a suitable basis for generic programming. See <a href="http://blog.krzyzanowskim.com/2015/03/01/swift_madness_of_generic_integer/">this blog post</a> for an example of an attempt to implement a generic algorithm over integers. […]</p>
<p>Finally, the current design predates many of the improvements that came in Swift 2, and hasn’t been revised since then.</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0105-remove-where-from-forin-loops.md">SE-0105</a>: <em>Removing Where Clauses from For-In Loops</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000192.html">under review</a>.</p>
<blockquote>
<p>This proposal removes <code class="language-plaintext highlighter-rouge">where</code> clauses from <code class="language-plaintext highlighter-rouge">for-in</code> loops, where they are better expressed (and read) as <code class="language-plaintext highlighter-rouge">guard</code> conditions.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Not on the lists, but <strong>@practicalswift</strong> posted <a href="https://twitter.com/practicalswift/status/745003709264977922">an update</a> on the number of open swiftc crashers. 42 open, 5090 closed. Thanks to <a href="https://twitter.com/slava_pestov">Slava Pestov</a> for his hard work on these. 👏</p>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021622.html">posted</a> another message on <em>Swift 3 vs “additive” proposals</em>. This is great reminder to the community to stay focused on finishing Swift 3. While we don’t know the <em>exact</em> deadline for Swift 3, we <em>do know</em> that it is fixed with the final release of Xcode 8 — which is fixed to the final releases of iOS, macOS, and the other platforms, which are fixed to (likely?) new hardware coming this fall. In other words, there is very little wiggle room for any of these releases to slip. There is <strong>a lot</strong> of work that needs to be done in just a few months!</p>
<blockquote>
<p>As I mentioned before, the Swift 3 release is winding down. There is still time left to make changes, but it is very short. As such, we — as a community — need to stay focused on the goals for this release, principally the goal to get to source stability. It is very important for users of Swift that Swift 3 and the Swift 4 compiler be as compatible as possible. This is important for the continued growth of Swift into new places, like new platforms (which don’t get the benefit of Xcode migration) and Swift Playgrounds.</p>
<p>As such, “additive” proposals will need very strong rationale explaining why they are critical for the Swift 3 release, and we won’t be merging these proposals into the swift-evolution repository unless they have that. We should stay focused on proposals that perfect the features we have, rather than adding new ones.</p>
<p>Similarly, general discussions on this mailing list about blue sky additions to the language are distracting from our important goals, and the core team generally isn’t paying attention to these anyway. I would really appreciate it if we could stay focused on what is important, until the time is right to look beyond Swift 3. This time is in August (which will be here way too soon :-), at which point we can look to the future. I outlined this <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html">here earlier</a>.</p>
<p>Sorry to be a “downer”, but Swift 3 really is a very important release for the Swift developer community as a whole.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/ayanonagon/status/743594792081252352">“I tried Objective-C but I found Swift better”</a>. Ha! 😎</p>
Issue #26
https://swiftweeklybrief.com/issue-26
2016-06-09T00:00:00-07:00
2016-06-09T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #26! This week was pretty light. Activity is somewhat winding down, presumably in preparation for <a href="https://developer.apple.com/wwdc/">WWDC</a> next week. I’ll be skipping the issue next week during the conference and will resume the week after. Hope to see you there!</p>
<p>Also, I forgot to mention last week that it was <a href="https://twitter.com/ayanonagon/status/738379261107523584">Swift’s 2nd birthday</a>! (And it’s rude to <a href="https://twitter.com/jckarter/status/738518275194159107">force-unwrap Swift on its birthday</a>. 😂)</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>The <a href="https://github.com/apple/swift/milestones/Swift%203.0%20Preview%201">Swift 3.0 Preview 1</a> milestone has grown to 98 (closed) issues. We’re still waiting on the first official Swift 3.0 preview. My guess is that this will be announced at WWDC. 😉</p>
<p><strong>@karwa</strong> <a href="https://github.com/apple/swift/pull/2912">added</a> a <code class="language-plaintext highlighter-rouge">-toolchain</code> option to <code class="language-plaintext highlighter-rouge">swiftc</code>. <em>“This works like clang/gcc’s <code class="language-plaintext highlighter-rouge">-B</code> flag (which allows specifying an alternate toolchain location).”</em></p>
<p>Chris Williams <a href="https://github.com/apple/swift/pull/2929">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md">SE-0093</a>: <em>Adding a public <code class="language-plaintext highlighter-rouge">base</code> property to slices</em>.</p>
<p>Erik Eckstein <a href="https://github.com/apple/swift/pull/2845">optimized</a> the mangling of specialized generic functions.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/2924">implemented</a> a Clang-like warning if source control conflict markers are detected during lexing.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Erica Sadun’s and Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md">SE-0099</a>: <em>Restructuring Condition Clauses</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000184.html">accepted</a> <strong>with revision</strong> for Swift 3.</p>
<blockquote>
<p>There was near unanimous agreement that the Swift 2 grammar was inconsistent and ambiguous and should be changed; most of the disagreement centered on how. Many alternatives were discussed, […]</p>
<p>Of these alternatives, the core team found the last one to be the best choice. <code class="language-plaintext highlighter-rouge">case</code> and <code class="language-plaintext highlighter-rouge">let</code> conditions should each specify a single declaration, comma should remain the condition separator, and the <code class="language-plaintext highlighter-rouge">where</code> keyword can be retired from its purpose as a boolean condition introducer. Some code becomes more verbose, but in common formatting patterns, it aligns more nicely, as in:</p>
</blockquote>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"> <span class="k">guard</span>
<span class="k">let</span> <span class="nv">x</span> <span class="o">=</span> <span class="nf">foo</span><span class="p">(),</span>
<span class="k">let</span> <span class="nv">y</span> <span class="o">=</span> <span class="nf">bar</span><span class="p">(),</span>
<span class="k">let</span> <span class="nv">z</span> <span class="o">=</span> <span class="nf">bas</span><span class="p">(),</span>
<span class="n">x</span> <span class="o">==</span> <span class="n">y</span> <span class="o">||</span> <span class="n">y</span> <span class="o">==</span> <span class="n">z</span> <span class="k">else</span> <span class="p">{</span>
<span class="p">}</span></code></pre></figure>
<blockquote>
<p>and though it breaks commonality between <code class="language-plaintext highlighter-rouge">let</code> conditions and <code class="language-plaintext highlighter-rouge">let</code> declarations, it’s more important to preserve higher-level consistency throughout the language in how components of expressions and statements are separated.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Austin Zheng’s and Becca Royal-Gordon’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md">SE-0089</a>: <em>Renaming <code class="language-plaintext highlighter-rouge">String.init<T>(_: T)</code></em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000183.html">under review</a> once again, after having been <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019018.html">returned for revision</a>.</p>
<blockquote>
<p>Swift’s <code class="language-plaintext highlighter-rouge">String</code> type ships with a large number of initializers that take one unlabeled argument. One of these initializers, defined as <code class="language-plaintext highlighter-rouge">init<T>(_: T)</code>, is used to create a string containing the textual representation of an object. It is very easy to write code which accidentally invokes this initializer by accident, when one of the other synonymous initializers was desired. Such code will compile without warnings and can be very difficult to detect.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Not from the Swift mailing lists but LLVM, Renato Golin discussed <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-May/100310.html">moving LLVM to GitHub</a>. Chris Lattner <a href="http://lists.llvm.org/pipermail/llvm-dev/2016-May/100314.html">supported the idea</a>. While not <em>directly</em> related to daily Swift development since mechanisms are in place to sync <a href="https://github.com/apple/swift-llvm">swift-llvm</a> with upstream, I imagine this could have a huge impact on contributions to LLVM.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/739936344344920064">prog rock or computer science</a>? 😂</p>
Issue #25
https://swiftweeklybrief.com/issue-25
2016-06-02T00:00:00-07:00
2016-06-02T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #25!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1615">SR-1615</a>: CoreFoundation should be audited for platform and architecture switches</li>
<li><a href="https://bugs.swift.org/browse/SR-1608">SR-1608</a>: <code class="language-plaintext highlighter-rouge">NSStream</code>, <code class="language-plaintext highlighter-rouge">NSInputStream</code>, and <code class="language-plaintext highlighter-rouge">NSOutputStream</code> need implementations</li>
<li><a href="https://bugs.swift.org/browse/SR-1602">SR-1602</a>: <code class="language-plaintext highlighter-rouge">NSEnergyFormatter</code> needs to be implemented</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/2767">finished</a> adding support in SILGen for nested generic functions. His <a href="https://github.com/apple/swift/commit/d2c8fbea9102e25ed1bf1e39481414c05946f8a5">update</a> to the changelog provides an example of the new functionality that this enables.</p>
<p>Trent Nadeau <a href="https://github.com/apple/swift/pull/2760">completed</a> the final part of the implementation for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md">SE-0047</a>, removing <code class="language-plaintext highlighter-rouge">@warn_unused_result</code> and adding a fixit.</p>
<p>Robert Widmann merged a <a href="https://github.com/apple/swift/pull/2755">pull request</a> to provide a better diagnostic for <code class="language-plaintext highlighter-rouge">nil</code> comparisons when attempting to use <code class="language-plaintext highlighter-rouge">===</code> for value types.</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/2801">fixed an error</a> in the <code class="language-plaintext highlighter-rouge">nextUp</code> and <code class="language-plaintext highlighter-rouge">nextDown</code> implementation.</p>
<p>Chris Williams opened a <a href="https://github.com/apple/swift/pull/2742">pull request</a> to implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080</a>: <em>Failable Numeric Conversion Initializers</em>.</p>
<p>Robert Widmann <a href="https://github.com/apple/swift/pull/2828">fixed</a> an off-by-one error in the <code class="language-plaintext highlighter-rouge">@noescape</code> fixit.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Max Moiseev’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0093-slice-base.md">SE-0093</a>: <em>Adding a public <code class="language-plaintext highlighter-rouge">base</code> property to slices</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019109.html">accepted</a> for Swift 3.</p>
<blockquote>
<p>There was little feedback from the community other than to get clarification. The core team recognizes the proposal as exposing an important basis operation of slice types.</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md">SE-0096</a>: <em>Converting <code class="language-plaintext highlighter-rouge">dynamicType</code> from a property to an operator</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000180.html">accepted</a> <strong>with revision</strong>.</p>
<blockquote>
<p>The feedback on the community on the proposal was very light, but there were significant concerns about its name. After discussion, the core team agrees that <code class="language-plaintext highlighter-rouge">x.dynamicType</code> should use the syntax of a global function as stated by the proposal, but would prefer for that function to be spelled <code class="language-plaintext highlighter-rouge">type(of: x)</code> to follow the naming guidelines. The rationale is:</p>
<ul>
<li>The function is side-effect free, so it should have a noun that describes what is returned.</li>
<li>“type” is ambiguously a noun, verb, and perhaps other things, so the “of” preposition is necessary for clarity.</li>
</ul>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p>Erica Sadun’s and Xiaodi Wu’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0050-floating-point-stride.md">SE-0050</a>: <em>Decoupling Floating Point Strides from Generic Implementations</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000178.html">returned for revision</a>.</p>
<blockquote>
<p>There was very little feedback from the community — the feedback was positive about solving the floating point error accumulation problem indicated by the proposal, but wasn’t strongly positive about the solution. The core team also agrees that the problem needs to be solved, however they don’t think this API change is the right approach. […] Once the design of this iterates on swift-evolution, it would be great to see a revised version of this proposal.</p>
</blockquote>
<p>Adrian Zubarev’s and Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md">SE-0095</a>: <em>Replace <code class="language-plaintext highlighter-rouge">protocol<P1,P2></code> syntax with <code class="language-plaintext highlighter-rouge">Any<P1,P2></code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000182.html">returned for revision</a>, with the intent that the revised proposal will be included for Swift 3. I recommend following the link to read Chris Lattner’s full response.</p>
<blockquote>
<p>There was an incredible amount of feedback from the community, continuing even today. The principle problem identified by community about the proposal is that <code class="language-plaintext highlighter-rouge">Any<T1, T2></code> implies very strongly an “any of T1 OR T2” relationship (aka disjunction) and not “any type conforming to T1 AND T2” relationship (aka conjunction). There was also some related discussion as to how the <code class="language-plaintext highlighter-rouge">Any<></code> syntax aligns with future generalized existential syntax, much discussion as to whether it should be spelled <code class="language-plaintext highlighter-rouge">Any<></code> or <code class="language-plaintext highlighter-rouge">any<></code>, and some discussion about “angle bracket blindness”.</p>
<p>The core team extensively discussed the feedback and considered many different possible paths forward. The conclusion of this is that it recommends that SE-0095 be revised into a fairly different proposal, one that introduces a new infix <code class="language-plaintext highlighter-rouge">&</code> type operator for representing protocol and other type compositions…</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md">SE-0098</a>: <em>Lowercase <code class="language-plaintext highlighter-rouge">didSet</code> and <code class="language-plaintext highlighter-rouge">willSet</code> for more consistent keyword casing</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000179.html">rejected</a>.</p>
<blockquote>
<p>The feedback on the proposal from both the core team and the community was that these should remain camel cased, particularly given that they may become user-definable aspect names in a future release.</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md">SE-0097</a>: <em>Normalizing naming for “negative” attributes</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-June/000181.html">rejected</a> for Swift 3.</p>
<blockquote>
<p>The core team agrees with the principle guiding the proposal (that negative attributes should start with “non” instead of “no”) and highly values standardized naming for attributes. The community was lukewarm about “nonescaping” but pretty significantly opposed to “nonreturning”.</p>
<p>The core team discussed this at length and agreed that the problem identified by the proposal needs to be solved, but prefers to explore directions that would define away these attributes completely:</p>
<ol>
<li>
<p>For noreturn, the core team prefers to explore a solution where a function can be declared as returning an non-constructable “bottom” type (e.g. an enum with zero cases). This would lead to something like: <code class="language-plaintext highlighter-rouge">func abort() -> NoReturn { … }</code>. This will require some new support in the compiler, but should flow better through the type system than <code class="language-plaintext highlighter-rouge">@noreturn</code> in function composition and other applications. Joe Groff offered to write a proposal for this.</p>
</li>
<li>
<p>For <code class="language-plaintext highlighter-rouge">@noescape</code>, the core team feels that the right solution is for closure arguments to <em>default</em> to <code class="language-plaintext highlighter-rouge">@noescape</code>, which means that the attribute we should really need is <code class="language-plaintext highlighter-rouge">@escaping</code>.</p>
</li>
</ol>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Erica Sadun’s and Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md">SE-0099</a>: <em>Restructuring Condition Clauses</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000177.html">under review</a>.</p>
<blockquote>
<p>Swift condition clauses appear in <code class="language-plaintext highlighter-rouge">guard</code>, <code class="language-plaintext highlighter-rouge">if</code>, and <code class="language-plaintext highlighter-rouge">while</code> statements. This proposal re-architects the condition grammar to enable an arbitrary mix of Boolean expressions, <code class="language-plaintext highlighter-rouge">let</code> conditions (which test and unwrap optionals), general <code class="language-plaintext highlighter-rouge">case</code> clauses for arbitrary pattern matching, and availability tests. It removes <code class="language-plaintext highlighter-rouge">where</code> clauses from optional binding conditions and case conditions, and introduces semicolons (optionally newlines) between unrelated condition types rather than commas, which are reserved for continuation lists. This eliminates ambiguity problems in the current syntax, and alleviates the situation where many Swift developers don’t know they can use arbitrary Boolean conditions after a value binding.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Harlan Haskins <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019407.html">pitched an idea</a> about introducing a <code class="language-plaintext highlighter-rouge">#warning</code> compiler directive that would emit a warning diagnostic. This would serve a similar purpose as a <code class="language-plaintext highlighter-rouge">// TODO </code> or <code class="language-plaintext highlighter-rouge">// FIXME</code> comment, but produce an actual warning in Xcode. Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019845.html">gave a +1</a> to the proposal, noting how this could have a positive impact <em>outside</em> of IDEs like Xcode, for example with SwiftPM.</p>
<p>Tony Allevato <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018920.html">drafted</a> a proposal for automatically deriving <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> for certain value types. It’s an interesting idea, but certainly has challenging edge cases. There was some discussion over adding specific keywords to include or exclude which properties of a type are used in the <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Hashable</code> definitions, but this seems overly complicated. Becca Royal-Gordon <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018971.html">warned</a> early on to keep it simple. Patrick Smith <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019145.html">suggested</a> providing implementations by default, and allowing users to override.</p>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018919.html">pitched an idea</a> about adding a <code class="language-plaintext highlighter-rouge">with</code> function to the standard library to address a common situation where developers want to duplicate and modify a constant value type (without having to use <code class="language-plaintext highlighter-rouge">var</code>). (<a href="https://gist.github.com/erica/96d9c5bb4eaa3ed3b2ff82dc35aa8dae">Gist here</a>) Example:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Before</span>
<span class="k">let</span> <span class="nv">john</span> <span class="o">=</span> <span class="kt">Person</span><span class="p">(</span><span class="nv">name</span><span class="p">:</span> <span class="s">"John"</span><span class="p">,</span> <span class="nv">favoriteColor</span><span class="p">:</span> <span class="o">.</span><span class="nf">blueColor</span><span class="p">())</span>
<span class="k">let</span> <span class="nv">jane</span><span class="p">:</span> <span class="kt">Person</span> <span class="o">=</span> <span class="p">{</span> <span class="k">var</span> <span class="nv">copy</span> <span class="o">=</span> <span class="nv">$0</span><span class="p">;</span> <span class="n">copy</span><span class="o">.</span><span class="n">name</span> <span class="o">=</span> <span class="s">"Jane"</span><span class="p">;</span> <span class="k">return</span> <span class="n">copy</span> <span class="p">}(</span><span class="n">john</span><span class="p">)</span>
<span class="c1">// After</span>
<span class="k">let</span> <span class="nv">jane</span> <span class="o">=</span> <span class="nf">with</span><span class="p">(</span><span class="n">john</span><span class="p">)</span> <span class="p">{</span> <span class="nv">$0</span><span class="o">.</span><span class="n">name</span> <span class="o">=</span> <span class="s">"Jane"</span> <span class="p">}</span></code></pre></figure>
<p>Austin Zheng <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/019138.html">started a discussion</a> on property reflection. <em>“For those who are interested I’d like to present a pre-pre-proposal for reflection upon a type’s properties and solicit feedback. First of all, some caveats: this is only a very small piece of what reflection in Swift might look like one day, and it’s certainly not the only possible design for such a feature.”</em> <a href="https://gist.github.com/austinzheng/699d47f50899b88645f56964c0b7109a">Here’s the gist</a> of a rough, possible “KVC-like” API. Somebody tell <a href="http://inessential.com/2016/06/01/oldie_praises_the_old_old_ways">Brent Simmons</a> and <a href="http://chris.eidhof.nl/post/undo-history-in-swift/">Chris Eidhof</a>. 😄</p>
<p>David Rönnqvist <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160530/019612.html">started a discussion</a> on the difference between how <code class="language-plaintext highlighter-rouge">static</code> and <code class="language-plaintext highlighter-rouge">lazy</code> variables are evaluated when initially assigned with a different value. Briefly, stored properties evaluate first before assigning a new value, but lazy properties do not.</p>
<h3 id="finally">Finally</h3>
<p>And finally — Did you ever realize that <code class="language-plaintext highlighter-rouge">UIViewController</code> <a href="https://twitter.com/ayanonagon/status/736153213146128384">has <em>troll</em> in its name</a>? 😂 It might be the biggest troll in all of UIKit. 😉</p>
Issue #24
https://swiftweeklybrief.com/issue-24
2016-05-26T00:00:00-07:00
2016-05-26T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #24! As noted last week, the first Swift 3 preview branch was cut and now there’s a <a href="https://github.com/apple/swift/milestones/Swift%203.0%20Preview%201">Swift 3.0 Preview 1</a> milestone on GitHub tracking pull requests to be included. Currently there are 60 closed and 4 open.</p>
<p>Swift is about to hit another important milestone — 100 proposals. As of this writing there have been 99 <a href="https://github.com/apple/swift-evolution/tree/master/proposals">Swift evolution proposals</a> merged into the repository, many of them from the community. Swift has only been open source for about 6 months, so that’s over 16 proposals per month — nearly one proposal every other day! I’m pretty sure coordinating, reviewing, and writing swift-evolution announcement emails is Chris Lattner’s new <a href="https://twitter.com/clattner_llvm/status/674254974629502976">“nights and weekends” passion</a>. 😉</p>
<p>Thus, last week’s <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html">announcement</a> about the goals of Swift 3 really should not have been a surprise. I think <a href="http://iosdevweekly.com/issues/251#start">Dave Verwer</a> said it best, <em>“It’s likely that this volume of high quality community input came as a surprise to the Swift team. Certainly, if it was still closed source, the scope and features of Swift 3 would have been different.”</em></p>
<p>In other news, Apple released new betas for <a href="https://developer.apple.com/news/?id=05232016c">iOS</a>, <a href="https://developer.apple.com/news/?id=05232016b">tvOS</a>, and <a href="https://developer.apple.com/news/?id=0232016a">OS X</a>.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1618">SR-1618</a>: [SPM] Xcode re-writes project.pbxproj for more than one module</li>
<li><a href="https://bugs.swift.org/browse/SR-1612">SR-1612</a>: Type comparison of certain CG types with AnyObject object is always true</li>
<li><a href="https://bugs.swift.org/browse/SR-1453">SR-1453</a>: [SPM] Improve error messages when building invalid packages</li>
<li><a href="https://bugs.swift.org/browse/SR-1560">SR-1560</a>: [Compiler] Implement support for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>, Adding a Build Configuration Import Test</li>
<li><a href="https://bugs.swift.org/browse/SR-1561">SR-1561</a>: [Parser] implement support for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md">SE-0081</a>, Move <code class="language-plaintext highlighter-rouge">where</code> clause to end of declaration</li>
</ul>
<p>Starter tasks are now much easier to discover in JIRA. See the <strong>Mailing List</strong> section below for details.</p>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="community">Community</h3>
<p><a href="https://twitter.com/UINT_MIN/status/735135603113660416">Jordan Rose</a> has written a fantastic <a href="http://belkadan.com/blog/2016/05/So-You-Want-To-Be-A-Compiler-Wizard/">article</a> on his thoughts and ideas for getting into compilers and programming languages. No formal education needed! I highly recommend reading this.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Bhaktavatsal Reddy <a href="https://github.com/apple/swift-corelibs-foundation/pull/380">fixed</a> a memory leak in <code class="language-plaintext highlighter-rouge">NSMutableData</code> and <code class="language-plaintext highlighter-rouge">NSData</code> in corelibs-foundation.</p>
<p>Han Sangjin <a href="https://github.com/apple/swift-corelibs-foundation/pull/381">submitted</a> a pull request to port corelibs-foundation to Cygwin.</p>
<p>Russ Bishop <a href="https://github.com/apple/swift-corelibs-foundation/pull/378">merged</a> changes to remove the use of <code class="language-plaintext highlighter-rouge">OpaquePointer</code> in corelibs-foundation, for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md">SE-0017</a>.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/2640">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md">SE-0062</a>, <em>Referencing Objective-C key-paths</em>.</p>
<p>Ankit Aggarwal added <a href="https://github.com/apple/swift-package-manager/pull/360">Objective-C support</a> and <a href="https://github.com/apple/swift-package-manager/pull/362">C++ support</a> to ClangModules for SwiftPM. He’s even written <a href="http://ankit.im/swift/2016/05/21/creating-objc-cpp-packages-with-swift-package-manager/">an article</a> on how to create Objective-C and C++ packages. 🙌</p>
<p>Bhargav Gurlanka added support for generating <a href="https://github.com/apple/swift-package-manager/pull/342">framework targets in Xcode</a> project created by SwiftPM.</p>
<p>Brian Croom opened a <a href="https://github.com/apple/swift-corelibs-xctest/pull/114">pull request</a> to add a command line flag for printing a list of the tests in the suite in corelibs-xctest.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2662">fixed</a> an issue that prevented properly lowering types of Objective-C generic methods dispatched off <code class="language-plaintext highlighter-rouge">AnyObject</code>.</p>
<p>Janek Spaderna submitted a <a href="https://github.com/apple/swift/pull/2637">pull request</a> to improve diagnostics in inheritance clauses.</p>
<p>Ted Kremenek <a href="https://github.com/apple/swift/pull/2667">fixed</a> an issue with <code class="language-plaintext highlighter-rouge">Dictionary</code> and <code class="language-plaintext highlighter-rouge">Set</code> that would result in over-allocating the bitmap by a factor of 32 or 64, depending on the platform.</p>
<p>Vivian Kong has opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/386">pull request</a> on corelibs-foundation to support Linux on IBM z Systems.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2687">fixed</a> crashes when conditionally looking up generic subscripts and properties via <code class="language-plaintext highlighter-rouge">AnyObject</code>.</p>
<p>Ankit Aggarwal submitted a <a href="https://github.com/apple/swift-package-manager/pull/363">pull request</a> that adds a helper tool to list tests from an XCTest bundle on OSX.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Matt Wright’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md">SE-0088</a>: <em>Modernize libdispatch for Swift 3 naming conventions</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000163.html">accepted</a> <strong>with revisions</strong> for Swift 3.</p>
<blockquote>
<p>The community and core team are both very positive about this massive improvement to the libdispatch APIs. Much of the discussion has centered around specific details in the proposal - for example the “.asynchronously” method on <code class="language-plaintext highlighter-rouge">DispatchQueue</code>. This great discussion leads to several requested revisions in the proposal:</p>
<ul>
<li>Rename the <code class="language-plaintext highlighter-rouge">DispatchQueue.[a]synchronously</code> methods to <code class="language-plaintext highlighter-rouge">.async</code> and <code class="language-plaintext highlighter-rouge">.sync</code>, to follow the term of art.</li>
<li>Rename <code class="language-plaintext highlighter-rouge">DispatchIO</code> <code class="language-plaintext highlighter-rouge">setHighWater</code>, <code class="language-plaintext highlighter-rouge">setLowWater</code> –> <code class="language-plaintext highlighter-rouge">setLimit(highWater:)</code>, <code class="language-plaintext highlighter-rouge">setLimit(lowWater:)</code></li>
<li>Rename <code class="language-plaintext highlighter-rouge">setTargetQueue(queue:)</code> and <code class="language-plaintext highlighter-rouge">DispatchSource.setTimer</code></li>
<li>Rename Semaphore, Group and WorkItem: <code class="language-plaintext highlighter-rouge">.wait(timeout:)</code> –> <code class="language-plaintext highlighter-rouge">wait()</code> and <code class="language-plaintext highlighter-rouge">wait(withTimeout:)</code></li>
<li>Expand source handler methods to take the same arguments as <code class="language-plaintext highlighter-rouge">async()</code></li>
<li>Expand <code class="language-plaintext highlighter-rouge">DispatchQueue.after</code> to take the same arguments as <code class="language-plaintext highlighter-rouge">async()</code> in addition to the <code class="language-plaintext highlighter-rouge">when:</code> argument</li>
</ul>
<p>Thank you to Matt Wright proposing this, and for all of the implementation work that has gone into this so far!</p>
</blockquote>
<p>Kevin Ballard’s and Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0094-sequence-function.md">SE-0094</a>: <em>Add <code class="language-plaintext highlighter-rouge">sequence(initial:next:)</code> and <code class="language-plaintext highlighter-rouge">sequence(state:next:)</code> to the stdlib</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000162.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000170.html">accepted</a> <strong>with revisions</strong> for Swift 3.</p>
<blockquote>
<ul>
<li>Feedback from the community & core team is positive.</li>
<li>Core team discussed whether it made sense to add just the first form, or whether it made sense to add both. They agree that although the form using an explicit state is much more infrequently used, when it is necessary, it is extremely helpful to have. It is also useful to consider both as a pair.</li>
<li>On naming, the core team agrees with the community that <code class="language-plaintext highlighter-rouge">sequence(first:next:)</code> is a better name than <code class="language-plaintext highlighter-rouge">sequence(initial:next:)</code>. <code class="language-plaintext highlighter-rouge">sequence(state:next:)</code> is approved as-is.</li>
</ul>
</blockquote>
<h3 id="amended-proposals">Amended proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>: <em>Referencing the Objective-C selector of a method</em> has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000164.html">amended</a>. You can find the diff <a href="https://github.com/apple/swift-evolution/commit/1dfd6cd4fc2e9874d5db8aef6a5f41d6556b2ca2">here</a>.</p>
<blockquote>
<p>Alex Hoppen, who undertook the work to implement the related proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md">SE-0064</a>, “Referencing the Objective-C selector of property getters and setters”, noted that by accepting arbitrary expressions inside a <code class="language-plaintext highlighter-rouge">#selector</code> expression, we made it difficult to handle the getter and setter selector cases introduced by <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md">SE-0064</a>. It was not the original proposal’s attempt to accept arbitrary expressions, only expressions that happened to form a valid method reference, and the amendment seeks to clarify this intent.</p>
</blockquote>
<h3 id="deferred-proposals">Deferred proposals</h3>
<p>Nate Cook’s and Sergey Bolshedvorsky’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0078-rotate-algorithm.md">SE-0078</a>: <em>Implement a rotate algorithm, equivalent to <code class="language-plaintext highlighter-rouge">std::rotate()</code> in C++</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000165.html">deferred</a> from Swift 3.</p>
<blockquote>
<p>The general “rotate a collection by N elements” operation is a powerful operation that is nice to have in certain domains, but also has very narrow applicability. Further, the proposal has high implementation complexity (particularly when dealing with lazy collections) due to missing generics features like constrained extensions. As such, the core team has decided to defer this feature until the dependent generics features are available.</p>
<p>One specific exception to this deferral is the <code class="language-plaintext highlighter-rouge">reverse()</code> algorithm proposed for <code class="language-plaintext highlighter-rouge">BidirectionalCollection</code>. This algorithm is simple and straight-forward, so it is approved for Swift 3.</p>
</blockquote>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md">SE-0083</a>: <em>Remove bridging conversion behavior from dynamic casts</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000173.html">deferred</a> for <strong>re-evaluation later in Swift 3</strong>.</p>
<blockquote>
<p>The core team and much of the community would like to get the predictability wins of this proposal. However, recent experience with the fallout of “<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md">SE-0072</a>: Fully eliminate implicit bridging conversions from Swift” has raised some concerns that it may have overly harmed Objective-C APIs designed around the “id” type. Joe Groff will be investigating a few ideas that may help make SE-0072 work better in practice, and until they are explored and understood, the core team prefers to defer discussion on SE-0083.</p>
<p>Once we have clarity on the fate of SE-0072 (in the next 3-6 weeks), we can discuss SE-0083 again. Thank you to Joe Groff for this proposal, and also for helping to sort out the issues related to SE-0072.</p>
</blockquote>
<p>Joe Groff’s and Tanner Nelson’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md">SE-0090</a>: <em>Remove <code class="language-plaintext highlighter-rouge">.self</code> and freely allow type references in expressions</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000174.html">deferred</a> from Swift 3.</p>
<blockquote>
<p>The community and core team all want this proposal (or something like it) to succeed, but the core team identified several serious implementation concerns with the proposal:</p>
<ul>
<li>Disambiguating type vs expression cannot be done in cases where there is no contextual type available or when that type is <code class="language-plaintext highlighter-rouge">Any</code>. For example, in the case of <code class="language-plaintext highlighter-rouge">let x = [Int]</code> it isn’t clear whether this is an array value that contains the metatype for <code class="language-plaintext highlighter-rouge">Int</code>, or whether it is a metatype value for the type <code class="language-plaintext highlighter-rouge">[Int]</code>. Similar problems exist with tuple literals, including the degenerate case of <code class="language-plaintext highlighter-rouge">let x = ()</code> which can either be the type of the empty tuple type or an empty tuple value.</li>
<li>As written, the proposal has a defaulting rule that fall back to the container literal when a type literal cannot be formed. The core team prefers that the compiler treat truly ambiguous cases (where a subexpression could be considered to be either a type or a value) to be ambiguous.</li>
<li>Resolving ambiguous cases requires some syntax to disambiguate between the cases, which we don’t have. This syntax should be part of the proposal.</li>
<li>Having the constraint solver determine whether a subexpression is in a type or expression context is conceptually beautiful, but it introduces significant complexity into the type checker and puts more pressure onto the constraint solver. The core team would prefer to see the already planned optimizations and simplifications go into the constraint solver before this happens. This would allow us to more accurately gauge the cost of this design in practice.</li>
<li>The goal of removing the <code class="language-plaintext highlighter-rouge">Int.self</code> syntax is a great one, but can be done at any point (beyond Swift 3) at little cost: the goal is to obsolete the <code class="language-plaintext highlighter-rouge">T.self</code> syntax, not to repurpose it to mean something else. This means that we can continue to accept it as deprecated syntax for a very long time with little cost to the community.</li>
</ul>
<p>The core team would definitely like to circle back to this proposal after Swift 3 is out the door, but would recommend that such a proposal be accompanied with a prototype implementation, to validation that the chosen approach can work in practice.</p>
</blockquote>
<h3 id="returned-proposals">Returned proposals</h3>
<p>Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md">SE-0089</a>: <em>Renaming <code class="language-plaintext highlighter-rouge">String.init<T>(_: T)</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000175.html">returned</a> for revision.</p>
<blockquote>
<p>The proposal has been <em>returned for revision</em> and another round of discussion - the core team would love to see the revised proposal make it into Swift 3.</p>
<p>The community and core team both want to remove this “footgun” from the standard library, where someone could write “String(x)” with the intention of getting a value-preserving conversion to String, but may instead get a potentially lossy and potentially expensive reflection-based conversion to a String. After extensive discussion, the core team recommends that the community consider a somewhat more elaborate design…</p>
</blockquote>
<h3 id="rejected-proposals">Rejected Proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md">SE-0084</a>: <em>Allow trailing commas in parameter lists and tuples</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000171.html">rejected</a>.</p>
<blockquote>
<p>The feedback from the community was quite divided on this topic…</p>
<p>Swift currently accepts a trailing comma in array and dictionary collection literals, for three reasons: evolution of a project often adds and removes elements to the collection over time, these changes do not alter the type of the collection (so those changes are typically spot changes), and the closing sigil of the collection (a right square bracket) is often placed on the line <em>following</em> the elements of the collection. Because of these properties, accepting a trailing comma in a collection literal can help reduce spurious diffs when elements are added or removed.</p>
<p>That said, these properties do not translate to other comma separated lists in Swift…</p>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md">SE-0087</a>: <em>Rename <code class="language-plaintext highlighter-rouge">lazy</code> to <code class="language-plaintext highlighter-rouge">@lazy</code></em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000172.html">rejected</a>.</p>
<blockquote>
<p>The community feedback on this proposal was that the most important thing was for the syntax to align with that of the forthcoming property behavior syntax. The core team does not know what that syntax will be, so it prefers to reject this proposal. […] …it would be worse to switch “lazy” to “@lazy” in Swift 3, only to switch it to something else in a subsequent release.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Adrian Zubarev’s and Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md">SE-0095</a>: <em>Replace <code class="language-plaintext highlighter-rouge">protocol<P1,P2></code> syntax with <code class="language-plaintext highlighter-rouge">Any<P1,P2></code></em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000166.html">under review</a>. Aside from the positive implications for generics, I think this is a great change to bring further consistency to the language. Repurposing the <code class="language-plaintext highlighter-rouge">protocol</code> keyword for composition always felt awkward and out of place to me. The community feedback on this proposal is positive so far, and Joe Groff has <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018791.html">started some bikeshedding</a> on an alternative form of infix syntax for composing constraints.</p>
<blockquote>
<p>A stated goal for Swift 3.0 is making breaking changes to prepare the way for features to be introduced in future features, especially those involving the enhancements to the generics system detailed in <a href="https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md"><em>Completing Generics</em></a>.</p>
<p>One such change described in <em>Completing Generics</em> is renaming <code class="language-plaintext highlighter-rouge">protocol<></code> to <code class="language-plaintext highlighter-rouge">Any<></code> in order to allow it to serve as a syntactic foundation for more generalized existential types. This is a straightforward change which will allow a later version of Swift to introduce better handling for existential types without making breaking changes, or changes whose functionality overlaps with that of existing features.</p>
</blockquote>
<p>Erica Sadun has three proposals under review this week.</p>
<ul>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0097-negative-attributes.md">SE-0097</a>: <em>Normalizing naming for “negative” attributes</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000167.html">under review</a>. <em>“This proposal normalizes naming for “negative” attributes by adopting a rule that replaces property names starting with <code class="language-plaintext highlighter-rouge">no</code> with adjectives starting with <code class="language-plaintext highlighter-rouge">non</code>.”</em> So far there’s limited and mixed feedback from the community. I’m rather neutral on this.</p>
</li>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0098-didset-capitalization.md">SE-0098</a>: <em>Lowercase <code class="language-plaintext highlighter-rouge">didSet</code> and <code class="language-plaintext highlighter-rouge">willSet</code> for more consistent keyword casing</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000168.html">under review</a>. There’s mixed feedback from the community on this one, mostly leaning <em>against</em> the change. It seems like Joe Groff’s <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160523/018779.html">concern</a> over potential language churn has shifted opinions: <em>“<code class="language-plaintext highlighter-rouge">didSet</code> and <code class="language-plaintext highlighter-rouge">willSet</code> are already contextual rather than formal keywords, and there’s a conceivable future where <code class="language-plaintext highlighter-rouge">didSet</code> and <code class="language-plaintext highlighter-rouge">willSet</code> are no longer keywords at all if we run with the ‘property behaviors’ feature again in the future. If we think that’s likely, I’m not sure this intermediate churn is really worth it.”</em></p>
</li>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0096-dynamictype.md">SE-0096</a>: <em>Converting <code class="language-plaintext highlighter-rouge">dynamicType</code> from a property to an operator</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000169.html">under review</a>. There’s positive support for this change from the community.</p>
</li>
</ul>
<blockquote>
<p>In Swift, <code class="language-plaintext highlighter-rouge">dynamicType</code> is a property. Because of that, it shows up as an “appropriate” code completion for all values regardless of whether it makes sense to do so or not. For example, Swift offers <code class="language-plaintext highlighter-rouge">4.dynamicType</code> and <code class="language-plaintext highlighter-rouge">myFunction().dynamicType</code>, etc. Unlike most properties, it does not express a logical attribute of a specific type. Instead, it can be applied to any expression. Since <code class="language-plaintext highlighter-rouge">dynamicType</code> behaves more like a operator (like <code class="language-plaintext highlighter-rouge">sizeof</code>), its user-facing calling syntax should follow suit.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Brian Gesiak <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160516/000662.html">shared</a> the new swift-corelibs-xctest <a href="https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10408">JIRA dashboard</a> that he created. 🙇</p>
<blockquote>
<p>If you’re like me, you might be curious how Core Libraries like swift-corelibs-xctest are doing with regards to the looming Swift 3.0 release. Well, wonder no more… […] The dashboard not only lists tasks that need to be resolved by Swift 3.0, but also open starter tasks for new contributors.</p>
</blockquote>
<p>Following Brian’s lead, <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160523/000664.html">Daniel Dunbar</a> announced a <a href="https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10409">dashboard</a> for SwiftPM. <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160523/000670.html">Brian</a> also created a <a href="https://bugs.swift.org/secure/Dashboard.jspa?selectPageId=10410">dashboard</a> for corelibs-foundation and Philippe Hausler <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160523/000671.html">added</a> a bunch of starter tasks. Each of these dashboards make it super easy to manage tasks and discover starter tasks. 👏</p>
<h3 id="finally">Finally</h3>
<p>And finally — “Yes, it’s true: with a little tuning, <a href="https://twitter.com/clattner_llvm/status/734992912581169152">C can be just as fast as Swift</a>.” 😂 (Great article from <a href="http://www.cocoawithlove.com/blog/2016/05/19/random-numbers.html">Matt Gallagher</a> this week.)</p>
Issue #23
https://swiftweeklybrief.com/issue-23
2016-05-19T00:00:00-07:00
2016-05-19T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue 23! This week Apple released iOS 9.3.2 and OS X 10.11.5. We’re only one month away from WWDC, and Realm just <a href="https://twitter.com/realm/status/733117749908623360">announced</a> that they will be hosting another <a href="http://www.meetup.com/swift-language/events/231196358/">WWDC Swift Panel</a> this year, if you’ll be here for the conference you should RSVP! It would be great to see you there. 😄</p>
<p>Chris Lattner also announced updates on the goals and status of Swift 3. See the details below in the <strong>Mailing lists</strong> section.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1554">SR-1554</a>: [Parser] <code class="language-plaintext highlighter-rouge">//*/</code> does not close multi-line comment</li>
<li><a href="https://bugs.swift.org/browse/SR-1453">SR-1453</a>: [SPM] Improve error messages when building invalid packages</li>
<li><a href="https://bugs.swift.org/browse/SR-1560">SR-1560</a>: [Compiler] Implement support for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>, Adding a Build Configuration Import Test</li>
<li><a href="https://bugs.swift.org/browse/SR-1561">SR-1561</a>: [Parser] implement support for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md">SE-0081</a>, Move <code class="language-plaintext highlighter-rouge">where</code> clause to end of declaration</li>
</ul>
<p>From Brian Gesiak:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1165">SR-1165</a>: Swift currently translates both <code class="language-plaintext highlighter-rouge">-[XCTest run]</code> and <code class="language-plaintext highlighter-rouge">-[XCTestRun runTest]</code> as <code class="language-plaintext highlighter-rouge">XCTest.run()</code>. Modify the apinotes for Apple XCTest such that Swift does not generate duplicate signatures for these two methods. This task will introduce you to Swift’s “apinotes” feature, as well as with building the Swift project and running its test suite. Prerequisite: basic knowledge of Swift syntax.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Bryan Chan from IBM submitted a number of pull requests this week to support Linux on <a href="https://en.wikipedia.org/wiki/IBM_System_z">IBM z systems</a>. You can find the various pull requests here: <a href="https://github.com/apple/swift/pull/2541">swift</a>, <a href="https://github.com/apple/swift-clang/pull/13">swift-clang</a>, <a href="https://github.com/apple/swift-llvm/pull/8">swift-llvm (1)</a>, <a href="https://github.com/apple/swift-llvm/pull/9">swift-llvm (2)</a>, <a href="https://github.com/apple/swift-lldb/pull/27">swift-lldb</a>.</p>
<p>Russ Bishop <a href="https://github.com/apple/swift/pull/2529">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0032-sequencetype-find.md">SE-0032</a>, adding a <code class="language-plaintext highlighter-rouge">first(where:)</code> method to <code class="language-plaintext highlighter-rouge">Sequence</code>.</p>
<p>Ingmar Stein submitted a <a href="https://github.com/apple/swift/pull/2538">pull request</a> that fixes an issue where C preprocessor macros with casts are not visible to Swift.</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift/pull/2518">continued work</a> on <a href="https://bugs.swift.org/browse/SR-710">SR-710</a>, which is tracking generating <code class="language-plaintext highlighter-rouge">XCTestCaseProvider</code> entries on Linux.</p>
<p>Russ Bishop opened a <a href="https://github.com/apple/swift/pull/2537">pull request</a> that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md">SE-0017</a>, changing <code class="language-plaintext highlighter-rouge">Unmanaged</code> to use <code class="language-plaintext highlighter-rouge">UnsafePointer</code>.</p>
<p><strong>@JPMartha</strong> submitted a <a href="https://github.com/apple/swift-package-manager/pull/270">pull request</a> to improve the <code class="language-plaintext highlighter-rouge">--fetch</code> behavior in Swift Package Manager. Looks like a big step forward for improving dependency resolution.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2565">fixed</a> an issue where subclasses did not inherit protocol conformance from superclasses (<a href="https://bugs.swift.org/browse/SR-1480">SR-1480</a>).</p>
<p>Nicola Salmoria opened a <a href="https://github.com/apple/swift/pull/2551">pull request</a> to add non-optional overloads of <code class="language-plaintext highlighter-rouge">XCTAssertEqual</code> and <code class="language-plaintext highlighter-rouge">XCTAssertNotEqual</code>.</p>
<p>Dan Liew submitted a <a href="https://github.com/apple/swift/pull/2527">pull request</a> to “teach the Swift front-end to generate code with ‘Sanitizer Coverage’ with a new command line flag <code class="language-plaintext highlighter-rouge">-sanitize-coverage=</code>. This flag is analogous to Clang’s <code class="language-plaintext highlighter-rouge">-fsanitize-coverage=</code>.”</p>
<p>David Farler and Slava Pestov have been <a href="https://twitter.com/jckarter/status/731532782241873920">working on</a> an out-of-process reflection infrastructure. From <a href="https://twitter.com/jckarter/status/731532948877385730">Joe Groff</a>: “Debuggers and memory tools can now look at a Swift binary or running process and explore its object graph.”</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>David Hart’s and Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md">SE-0092</a>: <em>Typealiases in protocols and protocol extensions</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000151.html">accepted</a>. The proposal was proactively approved by the core team without a formal review period because of its obviousness, and to optimize the process. Greg Titus
has already started the implementation work on this.</p>
<blockquote>
<p>The core team consider this as an obvious follow-on to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md">SE-0011</a>. […] If there are any serious concerns, please raise them and we are happy to reconsider and start a normal review cycle.</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>: <em>Adding a Build Configuration Import Test</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000159.html">accepted</a>.</p>
<blockquote>
<p>The community and core team are both very positive about adding this functionality. It is precedented by the <code class="language-plaintext highlighter-rouge">__has_include</code> feature in Clang, and may have applicability allowing “conditionally available” features for SwiftPM modules in the future. The core team spent a significant amount of time discussing the proper naming for this, and came to agree that “canImport” (as proposed) is the best name for this conditional.</p>
</blockquote>
<p>The proposal from David Hart, Robert Widmann, and Pyry Jahkola, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md">SE-0081</a>: <em>Move <code class="language-plaintext highlighter-rouge">where</code> clause to end of declaration</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000161.html">accepted</a>.</p>
<blockquote>
<p>The feedback on this proposal was strongly positive from the community and core team. Some concerns were raised (e.g. about possible interaction with the future “generalized existentials” feature) but further examination turned up that they were at issue regardless of whether this feature is accepted. The core team agrees that this syntactic structure allows a more natural and beautiful way to structure complex generic constraints, and that “where” clauses should be considered secondary to the primary signature of the declaration (e.g. <code class="language-plaintext highlighter-rouge">func</code>, <code class="language-plaintext highlighter-rouge">class</code>, etc) in question.</p>
</blockquote>
<h3 id="amended-proposals">Amended proposals</h3>
<p>An amendment for proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md">SE-0039</a>: <em>Modernizing Playground Literals</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000152.html">reviewed</a>. The pull request with the changes is <a href="https://github.com/apple/swift-evolution/pull/324">here</a>, and it looks like Erica Sadun has approved.</p>
<blockquote>
<p>The Swift core team would like to amend this proposal to spell out what’s happening with the literal protocols. The proposal was not explicit about the fact that the protocols were going to change, and in fact it turned out that changing them was not a good idea. We’ve already applied the effects of this amendment in trunk, but that is a decision that should be ratified by the community. Please do not allow the fact that it’s “already done” to discourage you from speaking up if you have strong feelings about this amendment. […] We view this as a minor amendment to the proposal.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md">SE-0041</a>: <em>Updating Protocol Naming Conventions for Conversions</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000160.html">rejected</a>.</p>
<blockquote>
<p>The feedback on the proposal was generally positive about the idea of renaming these protocols, but the specific names in the proposal are not well received, and there is no apparent confluence in the community on better names. The core team prefers discussion to continue — if/when there is a strong proposal for a better naming approach, we can reconsider renaming these.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Erica Sadun’s and Xiaodi Wu’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0050-floating-point-stride.md">SE-0050</a>: <em>Decoupling Floating Point Strides from Generic Implementations</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000153.html">under review</a>.</p>
<blockquote>
<p>Swift strides create progressions along “notionally continuous one-dimensional values” using a series of offset values. This proposal supplements Swift’s generic stride implementation with separate algorithms for floating point strides that avoid error accumulation.</p>
</blockquote>
<p>Anton Zhilin’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0077-operator-precedence.md">SE-0077</a>: <em>Improved operator declarations</em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000154.html">under review</a>.</p>
<blockquote>
<p>In the beginning, operators had nice precedence values: 90, 100, 110, 120, 130, 140, 150, 160.</p>
<p>As time went, new and new operators were introduced. Precedence could not be simply changed, as this would be a breaking change. Ranges got precedence 135, <code class="language-plaintext highlighter-rouge">as</code> got precedence 132. <code class="language-plaintext highlighter-rouge">??</code> had precedence greater than <code class="language-plaintext highlighter-rouge"><</code>, but less than <code class="language-plaintext highlighter-rouge">as</code>, so it had to be given precedence 131.</p>
<p>Now it is not possible to insert any custom operator between <code class="language-plaintext highlighter-rouge"><</code> and <code class="language-plaintext highlighter-rouge">??</code>.
It is an inevitable consequence of current design: it will be impossible to insert an operator between two existing ones at some point.</p>
</blockquote>
<p>Anton Zhilin’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0087-lazy-attribute.md">SE-0087</a>: <em>Rename <code class="language-plaintext highlighter-rouge">lazy</code> to <code class="language-plaintext highlighter-rouge">@lazy</code></em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000155.html">under review</a>. This proposal aims to make <code class="language-plaintext highlighter-rouge">lazy</code> a modifier attribute instead of a keyword.</p>
<p>Austin Zheng’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0089-rename-string-reflection-init.md">SE-0089</a>: <em>Renaming <code class="language-plaintext highlighter-rouge">String.init<T>(_: T)</code></em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000156.html">under review</a>.</p>
<blockquote>
<p>Swift’s <code class="language-plaintext highlighter-rouge">String</code> type ships with a large number of initializers that take one unlabeled argument. One of these initializers, defined as <code class="language-plaintext highlighter-rouge">init<T>(_: T)</code>, is used to create a string containing the textual representation of an object. It is very easy to write code which accidentally invokes this initializer by accident, when one of the other synonymous initializers was desired. Such code will compile without warnings and can be very difficult to detect.</p>
</blockquote>
<p>Joe Groff’s and Tanner Nelson’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0090-remove-dot-self.md">SE-0090</a>: <em>Remove <code class="language-plaintext highlighter-rouge">.self</code> and freely allow type references in expressions</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000157.html">under review</a>.</p>
<blockquote>
<p>Swift’s grammar currently requires that type references only appear as part of a constructor call <code class="language-plaintext highlighter-rouge">T(x)</code> or member access <code class="language-plaintext highlighter-rouge">T.x</code>. To get the metatype object for <code class="language-plaintext highlighter-rouge">T</code>, one must refer to the special member <code class="language-plaintext highlighter-rouge">T.self</code>. I propose allowing type references to appear freely in expressions and removing the <code class="language-plaintext highlighter-rouge">.self</code> member from the language.</p>
</blockquote>
<p>Tony Allevato’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0091-improving-operators-in-protocols.md">SE-0091</a>: <em>Improving operator requirements in protocols</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000158.html">under review</a>.</p>
<blockquote>
<p>When a type conforms to a protocol that declares an operator as a requirement, that operator must be implemented as a global function defined outside of the conforming type. This can lead both to user confusion and to poor type checker performance since the global namespace is overcrowded with a large number of operator overloads. This proposal mitigates both of those issues by proposing that operators in protocols be declared statically (to change and clarify where the conforming type implements it) and use generic global trampoline operators (to reduce the global overload set that the type checker must search).</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017701.html">announced</a> updates regarding the goals of Swift 3. Unfortunately, it looks like a major goal for Swift 3 — ABI stability — will <strong>not</strong> be completed. This means developers will have to keep bundling the Swift runtime with their apps and all Swift binaries will need to be re-compiled for future versions of Swift. The goal to complete generics was also missed. The good news, however, is that Swift 3 has made <em>source stability</em> a priority, meaning source-breaking changes should be minimal moving forward. Chris has updated the main <a href="https://github.com/apple/swift-evolution/blob/master/README.md">README</a> in the swift-evolution repository to reflect these changes. You can see the <a href="https://github.com/apple/swift-evolution/commit/06b69a6e51a71a462c268da60b51a18966dba31b">diff</a> of changes here.</p>
<blockquote>
<p>This release is shaping up to be a really phenomenal release that will redefine the feel of Swift and make a major leap towards maturing the Swift language and development experience. We have had a focus on getting to source stability, with the forward-looking goal of making Swift 4 as source compatible with Swift 3 as we can reasonably accomplish. It tackled API naming head on (which is one of the hardest problems in computer science <sup>[1]</sup>), made major improvements to the consistency and feel of the language, and has several nice across the board additions.</p>
<p>That said, it is also clear at this point that some of the loftier goals that we started out with aren’t going to fit into the release - including some of the most important generics features needed in order to lock down the ABI of the standard library. As such, the generics and ABI stability goals will roll into a future release of Swift, where I expect them to be the <em>highest</em> priority features to get done.</p>
<p>[…]</p>
<p><sup>[1]</sup> It is well known that the two hard problems in Computer Science are naming, cache invalidation, and off-by-one errors.</p>
</blockquote>
<p>Regarding the ABI, Greg Parker <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017875.html">shared</a> some fascinating insights on the history of Objective-C. I definitely recommend reading the full email.</p>
<blockquote>
<p>We apologize for the inconvenience.</p>
<p>The OS X and iOS architecture transitions demonstrate the two fundamental laws of ABI changes:</p>
<ol>
<li>Opportunities to break ABI compatibility are rare.</li>
<li>Any opportunity to break ABI compatibility will suffer from severe schedule pressure.</li>
</ol>
<p>The Objective-C ABIs have many problems that would have been improved with more time. […]</p>
<p>If we tried to rush Swift ABI stability out the door for Swift 3 we would certainly end up with deliberate or accidental flaws like the above. Being able to take the time to get it right is a rare luxury.</p>
</blockquote>
<p>Austin Zheng <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/017844.html">started a discussion</a> about a proposal to enhance existential types. He’s prepared a great skeleton proposal and is looking for feedback from the community. <em>“Be unsparing; whatever form this feature takes will profoundly affect how Swift developers program for years, so it needs to be done right.”</em></p>
<p>Austin Zheng also <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160516/018109.html">pitched an idea</a> on renaming <code class="language-plaintext highlighter-rouge">protocol<></code> to <code class="language-plaintext highlighter-rouge">Any<></code> for Swift 3 and <a href="https://github.com/apple/swift-evolution/pull/332">drafted</a> a proposal.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/730928843523903488">Swift 3 preview 1 has branched</a>. 😂 (Some <a href="http://www.nytimes.com/2016/03/22/world/europe/boaty-mcboatface-what-you-get-when-you-let-the-internet-decide.html">background here</a>.)</p>
Issue #22
https://swiftweeklybrief.com/issue-22
2016-05-12T00:00:00-07:00
2016-05-12T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week Ted Kremenek wrote an official <a href="https://swift.org/blog/swift-3-0-release-process/">blog post</a> on the Swift 3.0 release process. It’s going to be an exciting release and it’s still scheduled to ship later this year. Unfortunately, it won’t be ready by WWDC 2016, but I’m sure we’ll have a decent beta by then.</p>
<p>The main Swift <a href="https://github.com/apple/swift">repository</a> also surpassed <a href="https://github.com/apple/swift/stargazers">30,000 stars</a> this week! That’s nearly double the amount of <a href="https://github.com/showcases/programming-languages?s=stars">the next most popular</a> programming language developed on GitHub. ⭐️⭐️⭐️ Here’s to an <a href="https://twitter.com/clattner_llvm/status/730613965995139072">amazing community</a> — Swift certainly is <a href="https://speakerdeck.com/jessesquires/contributing-to-open-source-swift?slide=35">more than a programming language</a>. 😊</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<p>For recently accepted proposals:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1489">SR-1489</a>: Implement support for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md">SE-0060</a>, enforcing order of defaulted parameters.</li>
<li><a href="https://bugs.swift.org/browse/SR-1490">SR-1490</a>: Implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md">SE-0076</a> by changing some <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> taking methods to take <code class="language-plaintext highlighter-rouge">UnsafePointer</code> instead.</li>
<li><a href="https://bugs.swift.org/browse/SR-1491">SR-1491</a>: Implement support for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080</a>, failable Numeric Conversion Initializers</li>
</ul>
<p>From Danuel Duan:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1469">SR-1469</a>: Diagnostic for <code class="language-plaintext highlighter-rouge">init?</code> is reported at the end of the method despite an early return.</li>
</ul>
<p>From Brian Gesiak:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1421">SR-1421</a>: Document the <code class="language-plaintext highlighter-rouge">sourcekitd-test</code> tool, which is used to quickly experiment with SourceKit. This task will involve writing a small amount of C++. You’ll learn about LLVM’s command line interface library and its argument parser, as well as about Swift’s SourceKit.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Bhargav Gurlanka <a href="https://github.com/apple/swift-package-manager/pull/315">merged</a> adding a JSON dumper for dependencies in SPM.</p>
<p>Brian Croom opened a <a href="https://github.com/apple/swift-corelibs-xctest/pull/109">pull request</a> on corelibs-xctest to add the XCTest performance measurement APIs.</p>
<p>PJ Gray <a href="https://github.com/apple/swift-corelibs-foundation/pull/352">merged</a> adding support for ARMv6 on linux in corelibs-foundation.</p>
<p>Alex Hoppen <a href="">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md">SE-0036</a>: <em>Requiring Leading Dot Prefixes for <code class="language-plaintext highlighter-rouge">Enum</code> Instance Member Implementations</em>.</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/2429">merged</a> revisions to the documentation for core types and protocols.</p>
<p>Trent Nadeau opened a <a href="https://github.com/apple/swift/pull/2459">pull request</a> to use <code class="language-plaintext highlighter-rouge">@discardableResult</code> and warn by default, as part of the effort to complete <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md">SE-0047</a>.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/2452">implemented</a> closure reflection. (Note the pull request was closed, but the commits were merged manually.)</p>
<p>Russ Bishop <a href="https://github.com/apple/swift/pull/2461">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0008-lazy-flatmap-for-optionals.md">SE-008</a>: <em>Add a Lazy flatMap for Sequences of Optionals</em>.</p>
<p>Michael Ilseman <a href="https://github.com/apple/swift/pull/2434">merged</a> CoreGraphics API naming changes for the latest API naming guidelines.</p>
<p>Joe Pamer <a href="https://github.com/apple/swift/pull/2419">implemented</a> his proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md">SE-0072</a>: <em>Fully eliminate implicit bridging conversions from Swift</em>. (Note: it was <a href="https://github.com/apple/swift/pull/2440">reverted</a>, then the revert was <a href="https://github.com/apple/swift/pull/2441">reverted</a>. <a href="https://cdn.meme.am/instances/500x/58010858.jpg">Yo dawg, I heard you like reverts</a>. 😄)</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/2420">merged</a> changes to allow importing pointer-returning methods as throwing.</p>
<p>Jorge Bernal <a href="https://github.com/apple/swift/pull/2423">implemented</a> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md">SE-0070</a>: <em>Make Optional Requirements Objective-C-only</em>.</p>
<p>Congratulations to <a href="https://twitter.com/aciidb0mb3r/status/729696879034798082">Ankit Aggarwal</a> for becoming the <a href="https://github.com/apple/swift-package-manager/graphs/contributors">#2 contributor</a> on Swift package manager. 👏</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Joe Pamer’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md">SE-0072</a>: <em>Fully eliminate implicit bridging conversions from Swift</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000137.html">accepted</a> <strong>for Swift 3</strong>.</p>
<blockquote>
<p>The feedback on this proposal was positive - the benefits of simplifying the type system and eliminating surprising behavior from the compiler is universally appealing. However, both the core team and the community wanted a better sense of what the impact of the proposal would be in practice on real code. Joe Pamer did some analysis and found out that there isn’t a significant impact on the most concerning <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016644.html">use case</a>.</p>
</blockquote>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md">SE-0066</a>: <em>Standardize function type argument syntax to require parentheses</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000138.html">accepted</a> <strong>for Swift 3</strong>.</p>
<blockquote>
<p>There was a significant amount of feedback on the proposal, with a fairly common theme of “lukewarm acceptance.” A number of community members were sad to see this familiar syntactic shortcut go away, but acknowledge that it fits well with recent directions, e.g., the elimination of the implicit tuple splat behavior <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md">SE-0029</a>. The core team acknowledges that the ability to elide parentheses is not actively harmful to the language, but felt that it was better to have consistency around function types (always have parentheses) than provide a relatively small syntactic shortcut for higher-order functions. The core team did not feel that this proposal needed to include required parentheses within closures, which have their own fairly specific grammar.</p>
</blockquote>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md">SE-0060</a>: <em>Enforcing order of defaulted parameters</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000146.html">accepted</a> <strong>for Swift 3</strong>.</p>
<blockquote>
<p>The feedback on the proposal was generally positive (several people remarked that they didn’t know this was allowed). Some people pointed out that removal of this capability penalizes API design in cases where there is no inherent order to parameters, but this is also true of non-defaulted parameters. The core team prefers to encourage consistency at call sites.</p>
</blockquote>
<p>Janosch Hildebrand’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md">SE-0076</a>: <em>Add overrides taking an <code class="language-plaintext highlighter-rouge">UnsafePointer</code> source to non-destructive copying methods on <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000149.html">accepted</a> <strong>with revisions for Swift 3</strong>.</p>
<blockquote>
<p>The feedback on the proposal from the community and the core team universally agreed that there is a problem that needs to be solved here. However, instead of adding overloads of the methods as proposed, it would be better to change the existing methods to take <code class="language-plaintext highlighter-rouge">UnsafePointer<></code> instead of <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer<></code>. Given the existing promotion rules that exist in the compiler, it will achieve the same effect. As part of this, other similar functions in the standard library should be audited and fixed as well.</p>
</blockquote>
<p>Matthew Johnson’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080</a>: <em>Failable Numeric Conversion Initializers</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000150.html">accepted</a> <strong>with revisions for Swift 3</strong>.</p>
<blockquote>
<p>The feedback on the proposal from the community and the core team was universally positive, and the new initializers on the primitive integer and floating point types have been approved. However, swift-evolution isn’t the right mechanism to propose extensions to Foundation types, so the extensions that adds conversions from <code class="language-plaintext highlighter-rouge">NSNumber</code> and to Foundation types should be subset out of the proposal.</p>
</blockquote>
<h3 id="rejected-proposals">Rejected proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md">SE-0073</a>: <em>Marking closures as executing exactly once</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000147.html">rejected</a> for Swift 3. Though feedback from the community and core team was positive, the proposal was reject for two main reasons. Chris Lattner notes that he would like to this discussed for a future release, beyond Swift 3.</p>
<blockquote>
<ol>
<li>
<p>The surface level syntax of <code class="language-plaintext highlighter-rouge">@noescape</code> needs to be reconsidered. At the minimum, we need to rename <code class="language-plaintext highlighter-rouge">@noescape</code> to <code class="language-plaintext highlighter-rouge">@nonescaping</code> for consistency with our previously agreed attribute naming scheme. However, it is also work discussing whether <code class="language-plaintext highlighter-rouge">@nonescaping</code> should be the default: if so, the attribute should actually become <code class="language-plaintext highlighter-rouge">@escaping</code>, and the functionality proposed in SE-0073 would be named <code class="language-plaintext highlighter-rouge">@once</code>.</p>
</li>
<li>
<p>Separate from the surface level issues, the implementation underlying this work has some significant challenges that are doable but would require major engineering work. Specifically, the definite initialization pass needs to “codegen” booleans in some cases for conditional initialization/overwrite cases, and these state values would have to be added to closure capture lists. This would require enough engineering work that it seems unlikely that it would happen in the Swift 3 timeframe […]</p>
</li>
</ol>
</blockquote>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md">SE-0074</a>: <em>Implementation of Binary Search functions</em> was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000148.html">rejected</a> for Swift 3.</p>
<blockquote>
<p>The feedback on the proposal was generally positive about the concept of adding binary search functionality, but negative about the proposal as written, with feedback that it was adding too much complexity to the API.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Tony Parker’s and Philippe Hausler’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0086-drop-foundation-ns.md">SE-0086</a>: <em>Drop NS Prefix in Swift Foundation</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000139.html">under review</a>. <em>“As part of Swift 3 API Naming and the introduction of Swift Core Libraries, we are dropping the NS prefix from key Foundation types in Swift.”</em> Note that not <em>all</em> types are removing the prefix, only the ones specified in the proposal. Additionally, some types will be <em>hoisted</em>, or lifted up into a class container as a sub-type. For example, <code class="language-plaintext highlighter-rouge">NSCalendarUnit</code> will become <code class="language-plaintext highlighter-rouge">Calendar.Unit</code>. Surprisingly, there’s only mildly positive feedback on this so far with concerns from the community about <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/016944.html">reference versus value</a> semantics for types that will receive a value-type (<code class="language-plaintext highlighter-rouge">struct</code>) counterpart, as well as “inheriting” some <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017342.html">unnecessary Objective-C legacy</a>.</p>
<p>Matthew Johnson’s and Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md">SE-0041</a>: <em>Updating Protocol Naming Conventions for Conversions</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000140.html">under review</a>. <em>“We propose to expand and improve the naming conventions established by the API Guidelines and the standard library with regard to conversion related protocols. We believe common protocol naming patterns should be clear, consistent, and meaningful.”</em> Their proposed solution includes establishing three protocol suffixes — <code class="language-plaintext highlighter-rouge">Creatable</code>, <code class="language-plaintext highlighter-rouge">Convertible</code>, and <code class="language-plaintext highlighter-rouge">Representable</code> — and renaming the protocols in the stdlib. So far there’s positive support from the community for bringing consistency here, but some debate about the naming of the suffixes. Programmers bikeshedding on how to name things? I know it’s hard to believe. 😄</p>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0075-import-test.md">SE-0075</a>: <em>Adding a Build Configuration Import Test</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000141.html">under review</a>. Similar to using <code class="language-plaintext highlighter-rouge">#if os(iOS)</code>, Erica proposes adding a new configuration to test if modules are available. For example, <code class="language-plaintext highlighter-rouge">#if canImport(UIKit)</code> would determine whether or not UIKit is supported on the current platform. Only <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017118.html">David Hart</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017177.html">Xiaodi Wu</a> have responded to this, but their feedback was positive.</p>
<blockquote>
<p>Swift’s existing set of build configurations specify platform differences, not module commonalities. For example, UIKit enables you to write view code supported on both iOS and tvOS. SpriteKit allows common code to render on OS X, iOS, and tvOS that would require an alternate UI on Linux. Testing for Metal support or Media Player would guard code that will not function on the simulator. If the simulator adopted these modules at some future time, the code would naturally expand to provide compatible execution without source modification.</p>
</blockquote>
<p>A proposal from David Hart, Robert Widmann, and Pry Jahkola, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0081-move-where-expression.md">SE-0081</a>: <em>Move <code class="language-plaintext highlighter-rouge">where</code> clause to end of declaration</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000142.html">under review</a>. The proposal suggests moving the <code class="language-plaintext highlighter-rouge">where</code> clause that’s used to constrain generic type parameters to the end of the declaration syntax. The motivation here is that <code class="language-plaintext highlighter-rouge">where</code> clauses can get quite long, which negatively impacts readability. Erica Sadun has a <a href="http://ericasadun.com/2016/04/06/folding-generic-argument-lists/">great post</a> describing the issue. So far feedback from the community is positive, although <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017280.html">Joe Groff</a> raises a concern about how this will affect the type grammar. Here’s an example:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// OLD</span>
<span class="kd">func</span> <span class="n">foo</span><span class="o"><</span><span class="kt">T</span><span class="p">:</span> <span class="kt">MyProtocol</span> <span class="k">where</span> <span class="kt">T</span><span class="p">:</span> <span class="kt">Equatable</span><span class="o">></span><span class="p">(</span><span class="nv">val</span><span class="p">:</span> <span class="kt">T</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Bar</span>
<span class="c1">// NEW</span>
<span class="kd">func</span> <span class="n">foo</span><span class="o"><</span><span class="kt">T</span><span class="p">:</span> <span class="kt">MyProtocol</span><span class="o">></span><span class="p">(</span><span class="nv">val</span><span class="p">:</span> <span class="kt">T</span><span class="p">)</span> <span class="o">-></span> <span class="kt">Bar</span> <span class="k">where</span> <span class="kt">T</span><span class="p">:</span> <span class="kt">Equatable</span></code></pre></figure>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0083-remove-bridging-from-dynamic-casts.md">SE-0083</a>: <em>Remove bridging conversion behavior from dynamic casts</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000143.html">under review</a>. There’s little feedback here, but it is positive.</p>
<blockquote>
<p>Dynamic casts using <code class="language-plaintext highlighter-rouge">as?</code>, <code class="language-plaintext highlighter-rouge">as!</code>, and <code class="language-plaintext highlighter-rouge">is</code> are currently able to dynamically perform Cocoa bridging conversions, such as from <code class="language-plaintext highlighter-rouge">String</code> to <code class="language-plaintext highlighter-rouge">NSString</code> or from an <code class="language-plaintext highlighter-rouge">ErrorProtocol</code>-conforming type to <code class="language-plaintext highlighter-rouge">NSError</code>. This functionality should be removed to make dynamic cast behavior simpler, more efficient, and easier to understand.</p>
</blockquote>
<p>Grant Paul’s and Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0084-trailing-commas.md">SE-0084</a>: <em>Allow trailing commas in parameter lists and tuples</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000144.html">under review</a>. <em>“Swift permits trailing commas after the last element in array or dictionary literal. This proposal extends that to parameters and tuples.”</em> There’s mixed feedback from the community on this proposal. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017055.html">Tony Allevato</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017082.html">Chris Lattner</a> argue against these changes noting the structural differences between collections, parameters lists, and tuples. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017081.html">Rob Napier</a> argues the benefits of having a general rule dictating “trailing commas are allowed in comma-separated lists”.</p>
<p>Matt Wright’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0088-libdispatch-for-swift3.md">SE-0088</a>: <em>Modernize libdispatch for Swift 3 naming conventions</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000145.html">under review</a>. <em>“The existing libdispatch module imports the C API almost verbatim. To move towards a more natural Swift interface and away from the C API, this proposal outlines changes to the libdispatch module and the motivation behind them.”</em> I was surprised to see the mixed feedback from the community here, although it is more positive than negative. Concerns centered around the proposed naming (surprise! 😄) as well as general API churn. Dan Appel had an <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160509/017343.html">interesting idea</a> about introducing <code class="language-plaintext highlighter-rouge">LibDispatch</code> to retain the existing C APIs and <code class="language-plaintext highlighter-rouge">Dispatch</code> for the <em>Swifty</em> versions of the APIs.</p>
<p>Rick Ballard’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0085-package-manager-command-name.md">SE-0085</a>: <em>Package Manager Command Names</em>, is <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160509/000438.html">under review</a>. There’s overwhelmingly positive support for these changes.</p>
<blockquote>
<p>This is a proposal for changing the command names used for invoking the Swift package manager. Instead of hanging all functionality off of <code class="language-plaintext highlighter-rouge">swift build</code> and <code class="language-plaintext highlighter-rouge">swift test</code>, we will introduce a new <code class="language-plaintext highlighter-rouge">swift package</code> command with multiple subcommands. <code class="language-plaintext highlighter-rouge">swift build</code> and <code class="language-plaintext highlighter-rouge">swift test</code> will remain as top-level commands due to their frequency of use.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/730123662729170944">mangled name or cat walking on keyboard</a>? ⌨️ 🐈 😂</p>
Issue #21
https://swiftweeklybrief.com/issue-21
2016-05-05T00:00:00-07:00
2016-05-05T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #21! There hasn’t been much news this week other than <a href="https://developer.apple.com/library/mac/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html#//apple_ref/doc/uid/TP40001051-CH5-DontLinkElementID_14">Xcode 7.3.1</a> was released, so let’s get on to the weekly brief. It was another huge week for proposals and it feels like the core team is moving really fast ahead of WWDC 2016. 💪</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1395">SR-1395</a>: [Compiler] Implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md">SE-0070</a>, Make Optional Requirements Objective-C-only</li>
<li><a href="https://bugs.swift.org/browse/SR-1393">SR-1393</a>: [SwiftPM] Enforce Swift module import dependencies</li>
</ul>
<p>These tasks are from previous issues that are still open and unassigned. Don’t be shy and ask for help if you need it! 😊</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1340">SR-1340</a>: [Compiler] Implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md">SE-0068</a>, Expanding Swift <code class="language-plaintext highlighter-rouge">Self</code> to class members and value types. See the <em>Accepted proposals</em> section below for more details.</li>
<li><a href="https://bugs.swift.org/browse/SR-1327">SR-1327</a>: [Compiler] Using <code class="language-plaintext highlighter-rouge">dynamicType</code> on a force unwrapped <code class="language-plaintext highlighter-rouge">nil</code> value type doesn’t throw an exception.</li>
<li><a href="https://bugs.swift.org/browse/SR-1304">SR-1304</a>: [SwiftPM] Handle spaces in path when parsing flags from pkgconfig</li>
<li><a href="https://bugs.swift.org/browse/SR-1266">SR-1266</a>: Remove duplication between <code class="language-plaintext highlighter-rouge">swift/test</code> and <code class="language-plaintext highlighter-rouge">swift/validation-test</code> configuration files. This is a good introduction to the Swift build system, its test suite, and CMake.</li>
<li><a href="https://bugs.swift.org/browse/SR-1263">SR-1263</a>: Compiler wrongfully complains of illegal syntax when declaring multiple conformances for a protocol’s associated type.</li>
<li><a href="https://bugs.swift.org/browse/SR-1174">SR-1174</a>: [llbuild] Properly escape verbose command descriptions</li>
<li><a href="https://bugs.swift.org/browse/SR-580">SR-580</a>: [Compiler] Warning should be produced for “variable was never mutated”</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Austin Zheng <a href="https://github.com/apple/swift/commit/0567d5f888e9a2f4b4bbd4126c9a13d44c56d847">committed</a> a markdown-formatted version of Doug Gregor’s <em>Completing Generics Manifesto</em>. Really great to have this in the repo instead of buried in the mailing lists!</p>
<p>Guillaume Lessard’s <a href="https://github.com/apple/swift/pull/1454">fix</a> for Mike Ash’s weak property thread safety <a href="https://bugs.swift.org/browse/SR-192">bug</a> was finally merged. 🎉</p>
<p>Bouke Haarsma opened a <a href="https://github.com/apple/swift-package-manager/pull/292">pull request</a> on SwiftPM to use <code class="language-plaintext highlighter-rouge">NSFileHandle</code> instead of <code class="language-plaintext highlighter-rouge">fopen</code>, as part of <a href="https://bugs.swift.org/browse/SR-1005">SR-1005</a>. 👍</p>
<p>Max Howell <a href="https://github.com/apple/swift-package-manager/pull/296">implemented</a> <code class="language-plaintext highlighter-rouge">--update</code> in SwiftPM, to determine and apply updates.</p>
<p>Chris Willmore merged a <a href="https://github.com/apple/swift/pull/2322">pull request</a> with an initial implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054</a>: <em>Abolish <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> Type</em>, and made the corresponding <a href="https://github.com/apple/swift-corelibs-foundation/pull/343">changes</a> to corelibs-foundation. 👌</p>
<p>Brian Croom <a href="https://github.com/apple/swift-corelibs-xctest/pull/102">added</a> class-level <code class="language-plaintext highlighter-rouge">setUp</code> and <code class="language-plaintext highlighter-rouge">tearDown</code> methods on <code class="language-plaintext highlighter-rouge">XCTestCase</code>.</p>
<p>Brian Gesiak opened a <a href="https://github.com/apple/swift/pull/2364">pull request</a> that implements generating <code class="language-plaintext highlighter-rouge">XCTestCaseProvider</code> entries on Linux, <a href="https://bugs.swift.org/browse/SR-710">SR-710</a>. 😎</p>
<p><strong>@swiftix</strong> <a href="https://github.com/apple/swift/pull/2370">fixed</a> some Array-related performance regressions introduced by the new indexing model. 🙌</p>
<p>Daniel Duan <a href="https://github.com/apple/swift/pull/2354">implemented</a> support for limiting <code class="language-plaintext highlighter-rouge">inout</code> capture to <code class="language-plaintext highlighter-rouge">@noescape</code> contexts, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.md">SE-0035</a>.</p>
<p>Timothy J. Wood <a href="https://github.com/apple/swift/pull/2384">implemented</a> his accepted proposal (see below), <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md">SE-0061</a>: <em>Add Generic Result and Error Handling to <code class="language-plaintext highlighter-rouge">autoreleasepool()</code></em>.</p>
<p>Ankit Aggarwal opened a <a href="https://github.com/apple/swift-llbuild/pull/28">pull request</a> on swift-llbuild to support <code class="language-plaintext highlighter-rouge">-whole-module-optimization</code>. <em>“When enabled swift compiler produces one object file and dependency file for the entire module instead of for each of the sources.”</em></p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Stephen Canon’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md">SE-0067</a>: <em>Enhanced Floating Point Protocols</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000121.html">accepted</a> <strong>for Swift 3</strong>. 👏</p>
<blockquote>
<p>Overall, the feedback on the proposal was very positive, particularly for revision 2 of the proposal.</p>
<p>The most significant feedback was around the naming issues for the various protocol requirements that map onto operators (e.g. “isLessThanOrEqualTo”). The core team agrees that these are unfortunate - their naming is awkward and they will end up polluting code completion for instances of these numeric types. That said, we are accepting the proposal as written, because the rest of the proposal is great progress in the direction we want to go, accepting it will allow us to get experience living on it, and we can improve this issue with a follow-on proposal.</p>
<p>To address the naming issues, we’d like to explore Tony Allevato’s ideas in the “Improve operator requirements in protocols” thread on swift-evolution. If that doesn’t work out, we request that these members be reworked to be named static members in the protocol, which will address the code completion issue.</p>
<p>Thank you to Stephen Canon for driving the design and implementation of this, and to Max Moiseev (and several others) who have been contributing to the implementation. This is a fundamental step to moving Swift numerics forward!</p>
</blockquote>
<p>Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md">SE-0071</a>: <em>Allow (most) keywords in member references</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000122.html">accepted</a> <strong>for Swift 3</strong>. 🎉 <em>“The discussion on swift-evolution was minimal, but entirely positive. This proposal eliminates a syntactic problem that would otherwise be new to Swift 3, with no apparent downside. What’s not to love?”</em></p>
<p>Timothy J. Wood’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0061-autoreleasepool-signature.md">SE-0061</a>: <em>Add Generic Result and Error Handling to <code class="language-plaintext highlighter-rouge">autoreleasepool()</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000123.html">accepted</a> <strong>for Swift 3</strong>. 🙌 <em>“The feedback on the proposal was minimal, but all positive.”</em> Work is being tracked at <a href="https://bugs.swift.org/browse/SR-842">SR-842</a>.</p>
<p>Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md">SE-0070</a>: <em>Make Optional Requirements Objective-C-only</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000124.html">accepted</a> <strong>for Swift 3</strong>. 🙇 <em>“SE-0070 is the minimal solution for clarifying optional requirements without making their important use cases overtly awkward. The core team requests that the diagnostics generated by mistakes using optional requirements be revised to make it clear that it is an Objective-C only feature.”</em> (A starter task for this listed is above.)</p>
<p>Tony Parker’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md">SE-0069</a>: <em>Mutability and Foundation Value Types</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000132.html">accepted</a> <strong>for Swift 3</strong>. 😎 <em>“The feedback on the proposal has been overwhelmingly positive.”</em></p>
<p>Jacob Bandes-Storch’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0017-convert-unmanaged-to-use-unsafepointer.md">SE-0017</a>: <em>Change Unmanaged to use UnsafePointer</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000117.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000133.html">accepted</a> <strong>for Swift 3</strong>. 👍 Jacob proposed replacing the usage of <code class="language-plaintext highlighter-rouge">COpaquePointer</code> with <code class="language-plaintext highlighter-rouge">UnsafePointer<Void></code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer<Void></code> in the <code class="language-plaintext highlighter-rouge">Unmanaged</code> API to reduce bloated code where users must convert from <code class="language-plaintext highlighter-rouge">UnsafePointer</code> to <code class="language-plaintext highlighter-rouge">COpaquePointer</code> to <code class="language-plaintext highlighter-rouge">Unmanaged</code>.</p>
<p>Kevin Ballard’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0032-sequencetype-find.md">SE-0032</a>: <em>Add <code class="language-plaintext highlighter-rouge">find</code> method to <code class="language-plaintext highlighter-rouge">Sequence</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000118.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000134.html">accepted</a> <strong>for Swift 3</strong>. 🤓 Kevin proposed to add a new extension method to <code class="language-plaintext highlighter-rouge">Sequence</code> called <code class="language-plaintext highlighter-rouge">find()</code> that returns the found element. <em>“It’s often useful to find the first element of a sequence that passes some given predicate. […] For Sequences, there’s no easy way to do this besides a manual loop that doesn’t require filtering the entire sequence and producing an array.”</em></p>
<p>Patrick Pijnappel’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md">SE-0052</a>: <em>Change IteratorType post-nil guarantee</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000120.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000135.html">accepted</a> <strong>for Swift 3</strong>. 👌 Patrick proposed to change the behavior of <code class="language-plaintext highlighter-rouge">IteratorType.next()</code> to return <code class="language-plaintext highlighter-rouge">nil</code> indefinitely.</p>
<blockquote>
<p>The feedback on this proposal was generally positive from the community and core team. The most significant concern was about performance: strengthening the requirement on <code class="language-plaintext highlighter-rouge">IteratorType.next()</code> could make some implementations of iterators slower. On the other hand, it does make some clients faster (UTF8 decoding being one cited case that demonstrates a big win). The core team believes that the improvements to performance in the most common use-cases will more than balance the reductions in performance for other cases.</p>
</blockquote>
<p>Kevin Ballard’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0045-scan-takewhile-dropwhile.md">SE-0045</a>: <em>Add <code class="language-plaintext highlighter-rouge">scan</code>, <code class="language-plaintext highlighter-rouge">prefix(while:)</code>, <code class="language-plaintext highlighter-rouge">drop(while:)</code>, and <code class="language-plaintext highlighter-rouge">unfold</code> to the stdlib</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000119.html">reviewed</a> and a subset of the proposal was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000136.html">accepted</a> <strong>with modifications, for Swift 3</strong>. 😄 Kevin proposes adding 3 common (but currently missing from the stdlib) <code class="language-plaintext highlighter-rouge">Sequence</code> functions — <code class="language-plaintext highlighter-rouge">scan(_:combine:)</code>, <code class="language-plaintext highlighter-rouge">prefix(while:)</code>, and <code class="language-plaintext highlighter-rouge">drop(while:)</code>, with overrides as appropriate on <code class="language-plaintext highlighter-rouge">Collection</code>, <code class="language-plaintext highlighter-rouge">LazySequenceProtocol</code>, and <code class="language-plaintext highlighter-rouge">LazyCollectionProtocol</code>, as well as a global function <code class="language-plaintext highlighter-rouge">unfold(_:applying:)</code>.</p>
<blockquote>
<p><code class="language-plaintext highlighter-rouge">Sequence.prefix(while:)</code> & <code class="language-plaintext highlighter-rouge">Sequence.drop(while:)</code> — These are <em>accepted</em> as specified in revision 3 of the proposal.</p>
<p><code class="language-plaintext highlighter-rouge">Sequence.scan(_:combine:)</code> — This addition is <em>rejected</em> by the core team. While this operation is provided by other functional language libraries, its use case is narrow and not obviously as applicable for Swift programmers. Swift intentionally has a high bar for “general utility” when adding operations to the standard library: it isn’t enough to be useful in some cases — it must be broadly useful by lots of people. The core team felt like this was too narrow to be worth including.</p>
<p><code class="language-plaintext highlighter-rouge">unfold(_:applying:)</code> — This addition is <em>rejected</em> by the core team as written, but deserves more discussion in the community, and potentially could be the subject of a future proposal. The core team felt that the utility of this operation is high enough to be worth including in the standard library, but could not find an acceptable name for it. “unfold” is problematic, despite its precedence in other language, because Swift calls the corresponding operation “reduce” and not “fold”. No one could get excited about “unreduce”. “iterate” was also considered, but a noun is more appropriate than an verb in this case. Given the lack of a good name, the core team preferred to reject to let the community discuss it more.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0060-defaulted-parameter-order.md">SE-0060</a>: <em>Enforcing order of defaulted parameters</em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000125.html">review</a>. <em>“Swift generally follows in the Smalltalk/Objective-C tradition of compound method names with significant, order-sensitive argument labels, but an exception is made for parameters with default arguments. We should remove this exception.”</em></p>
<p>Félix Cloutier’s and Gwendal Roué’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0073-noescape-once.md">SE-0073</a>: <em>Marking closures as executing exactly once</em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000126.html">review</a>. <em>“This proposal introduces an optional <code class="language-plaintext highlighter-rouge">once</code> argument to the <code class="language-plaintext highlighter-rouge">@noescape</code> attribute. The <code class="language-plaintext highlighter-rouge">@noescape(once)</code> attribute enforces that the closure does not escape, and that it is run exactly once on any code path returning from the function.”</em></p>
<p>A proposal from Lorenzo Racca, Jeff Hajewski and Nate Cook, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0074-binary-search.md">SE-0074</a>: <em>Implementation of Binary Search functions</em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000127.html">review</a>. <em>“Swift does not offer any way to efficiently search sorted collections. This proposal seeks to add a few different functions that implement the binary search algorithm.”</em></p>
<p>Janosch Hildebrand’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0076-copying-to-unsafe-mutable-pointer-with-unsafe-pointer-source.md">SE-0076</a>: <em>Add overrides taking an <code class="language-plaintext highlighter-rouge">UnsafePointer</code> source to non-destructive copying methods on <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code></em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000128.html">review</a>. <em>“<code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> includes several methods to non-destructively copy elements from memory pointed to by another <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> instance. I propose adding overloads of these methods to <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> that allow an <code class="language-plaintext highlighter-rouge">UnsafePointer</code> source.”</em></p>
<p>Nate Cook’s and Sergey Bolshedvorsky’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0078-rotate-algorithm.md">SE-0078</a>: <em>Implement a rotate algorithm, equivalent to <code class="language-plaintext highlighter-rouge">std::rotate()</code> in C++</em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000129.html">review</a>. <em>“This proposal is to add rotation and in-place reversing methods to Swift’s standard library collections.”</em></p>
<p>Matthew Johnson’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0080-failable-numeric-initializers.md">SE-0080</a>: <em>Failable Numeric Conversion Initializers</em>, is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000130.html">review</a>.</p>
<blockquote>
<p>Swift numeric types all currently have a family of conversion initializers. In many use cases they leave a lot to be desired. Initializing an integer type with a floating point value will truncate any fractional portion of the number. Initializing with an out-of-range value traps.</p>
<p>This proposal is to add a new family of conversion initializers to all numeric types that either complete successfully without loss of information or throw an error.</p>
</blockquote>
<p>Daniel Dunbar’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0082-swiftpm-package-edit.md">SE-0082</a>: <em>Package Manager Editable Packages</em> is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-May/000131.html">review</a>. <em>“This is a proposal for changing the behavior for iterative development of a group of packages. In particular, we will change the default location to which package dependency sources are cloned, the package managers behavior around those sources, and add a new feature for allowing iterative development.”</em></p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>David Sweeris started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016286.html">discussion</a> on renaming “class” when referring to protocol conformance. Currently, you would constrain a protocol to only apply to reference types by doing <code class="language-plaintext highlighter-rouge">protocol P: class { }</code>. Dave Abrahams <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016410.html">points out</a> that this has always been an awkward special case that could be replaced with <code class="language-plaintext highlighter-rouge">AnyObject</code>. I would love to see this change! To me, <code class="language-plaintext highlighter-rouge">protocol P: AnyObject { }</code> is so much more clear and consistent with the language. Adrian Zubarev also <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015568.html">brought this up</a> last week.</p>
<p>Nicholas Maccharoli <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016437.html">proposed</a> the idea of introducing an <code class="language-plaintext highlighter-rouge">OrderedSet</code> type. It looks like <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016529.html">Austin Zheng</a> is going to draft a proposal.</p>
<p>Erica Sadun started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016516.html">thread</a> on adding <code class="language-plaintext highlighter-rouge">yes</code> and <code class="language-plaintext highlighter-rouge">no</code> to the stdlib as aliases for <code class="language-plaintext highlighter-rouge">true</code> and <code class="language-plaintext highlighter-rouge">false</code>. However, it looks like community is in favor of keeping a single way to express boolean values.</p>
<p>Sangjin Han <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160502/016381.html">started</a> a discussion on MSVC/Cygwin compatibility. I’m personally not very familiar with the technical details here, but it’s an interesting thread!</p>
<h3 id="finally">Finally</h3>
<p>And finally — the <a href="https://twitter.com/FlexMonkey/status/727036117082583040">error message of the day</a>! Bummers. 🤔 😂</p>
Issue #20
https://swiftweeklybrief.com/issue-20
2016-04-28T00:00:00-07:00
2016-04-28T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Were any of you lucky enough to get a ticket to WWDC 2016?! I’m excited to share that <a href="https://twitter.com/jesse_squires/status/723708439487107073">I’ll be attending</a> this year. If you got a ticket too, I’ll see you there! However, if you won’t be at WWDC, don’t worry. There are plenty of other great conferences. 😄 Swift Summit has announced its <a href="https://www.swiftsummit.com">2016 conference</a> in San Francisco. It will be held this year on November 7 and 8, and yours truly will be speaking. 🤓 Also, the <a href="https://twitter.com/llvmorg/status/725399768491413504">LLVM Developers’ Meeting</a> will be held on November 3 and 4 in San Jose, CA.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1340">SR-1340</a>: [Compiler] Implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md">SE-0068</a>, Expanding Swift <code class="language-plaintext highlighter-rouge">Self</code> to class members and value types. See the <em>Accepted proposals</em> section below for more details.</li>
<li><a href="https://bugs.swift.org/browse/SR-1327">SR-1327</a>: [Compiler] Using <code class="language-plaintext highlighter-rouge">dynamicType</code> on a force unwrapped <code class="language-plaintext highlighter-rouge">nil</code> value type doesn’t throw an exception.</li>
<li><a href="https://bugs.swift.org/browse/SR-1304">SR-1304</a>: [SwiftPM] Handle spaces in path when parsing flags from pkgconfig</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>A few more issues have been added to the still-open <a href="https://github.com/apple/swift/pulls?utf8=✓&q=milestone%3A%22Swift+2.2.x%22+">Swift 2.2.x milestone</a> on GitHub. My guess is that <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_7.3.1/Xcode_7.3.1_GM_Seed_Release_Notes.pdf">Xcode 7.3.1</a> will include these additional fixes.</p>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/2255">added</a> a fix-it for non-optional bindings initialized with <code class="language-plaintext highlighter-rouge">nil</code>.</p>
<p>Bouke Haarsma opened a <a href="https://github.com/apple/swift-package-manager/pull/284">pull request</a> with initial work for <a href="https://bugs.swift.org/browse/SR-1005">SR-1005</a>, porting SwiftPM to use corelibs-foundation and remove the <code class="language-plaintext highlighter-rouge">POSIX</code> module.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2304">enabled</a> the importing of Objective-C lightweight generic type parameters into Swift as generic classes.</p>
<p><strong>@codestergit</strong> opened a <a href="https://github.com/apple/swift/pull/1527">pull request</a> to improve <code class="language-plaintext highlighter-rouge">MutableCollectionType.sort</code>, <code class="language-plaintext highlighter-rouge">MutableCollectionType.sortInPlace</code> and other sort related functions to take a throwing closure.</p>
<p>Mike Griepentrog <a href="https://github.com/apple/swift-corelibs-foundation/pull/302">merged</a> a pull request with an initial implementation of <code class="language-plaintext highlighter-rouge">NSURLCredential</code>.</p>
<p>Javier Soto merged a <a href="https://github.com/apple/swift/pull/2269">pull request</a> that adds tests for <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> conformance to <code class="language-plaintext highlighter-rouge">Comparable</code>. 👏 (<a href="https://bugs.swift.org/browse/SR-1238">SR-1238</a>)</p>
<p>Dave Abrahams <a href="https://github.com/apple/swift/pull/2108">merged</a> the implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md">SE-0065</a>. 🙌 (More information below under <em>Accepted proposals</em>.) And Dmitri Gribenko <a href="https://github.com/apple/swift-package-manager/pull/283">merged</a> the necessary changes to Swift Package Manager.</p>
<p>David Grove opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/303">pull request</a> to implement basic usage of the <code class="language-plaintext highlighter-rouge">_ObjectiveCBridgeable</code> protocol on Linux. 🙇</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2326">fixed</a> a leak when a bridgeable value type is dynamically cast to a class type, and the cast fails.</p>
<p>Chris Bailey opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/338">pull request</a> to further integrate corelibs-libdispatch into corelibs-foundation. 😎</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2316">merged</a> a fix for <a href="https://bugs.swift.org/browse/SR-613">SR-613</a>, a mis-compile that caused an over-release of “self” when partially applying a protocol method to a generic or existential of a refined class-constrained protocol.</p>
<p>Dave Abrahams opened a preliminary <a href="https://github.com/apple/swift/pull/2002">pull request</a> for the new <code class="language-plaintext highlighter-rouge">Set</code> algebra APIs, ready to be merged once the Swift evolution review is complete.</p>
<p>Daniel Dunbar <a href="https://github.com/apple/swift-package-manager/pull/288">merged</a> changes to SwiftPM to improve the portability of generated Xcode projects.</p>
<p>Lukas Schmidt <a href="https://github.com/apple/swift-corelibs-foundation/pull/260">merged</a> a pull request with some minor refinements to <code class="language-plaintext highlighter-rouge">NSDictionary</code>, removing nested <code class="language-plaintext highlighter-rouge">if let</code> statements. It definitely makes this code more readable. 👌 Don’t forget, small wins like this are everywhere, just waiting to be discovered!</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>The proposal from Dmitri Gribenko, Dave Abrahams, and Maxim Moiseev, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md">SE-0065</a>: <em>A New Model for Collections and Indices</em> has <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000115.html">been accepted</a>! 🎉</p>
<blockquote>
<p>This proposal received a significant amount of positive feedback - many people appreciated the clarification to the model, and the fact that it allows for significantly better performance in some cases as well as much simpler model in many ways. The majority of the feedback and discussion was around the specific names used in various methods. The authors of the proposal incorporated that into the latest version of the proposal (v5) which is available at the URL above.</p>
<p>Thank you to Dmitri Gribenko, Dave Abrahams, Maxim Moiseev and many others for contributing to the proposal, discussing the ideas, as well as to everyone else involved in the massive (ongoing) implementation effort to land this change.</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md">SE-0068</a>: <em>Expanding Swift <code class="language-plaintext highlighter-rouge">Self</code> to class members and value types</em>, has <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000116.html">been accepted</a> — or, at least a <strong>subset of the proposal</strong> has been accepted.</p>
<blockquote>
<p>This proposal had light discussion in the community review process, but the core team heavily debated it. It includes two pieces:</p>
<ol>
<li>Expanding the existing support for Self to work in value types, and in the bodies of classes.</li>
<li>Replacing the <code class="language-plaintext highlighter-rouge">x.dynamicType</code> expression with <code class="language-plaintext highlighter-rouge">x.Self</code>, a purely syntactic change that eliminates the <code class="language-plaintext highlighter-rouge">dynamicType</code> keyword.</li>
</ol>
<p>The core team has accepted the first half for this proposal. This allows the use of “Self” as shorthand for referring to the containing type (in the case of structs, enums, and final class) or the dynamic type (in the case of non-final classes). Most of the discussion in the core team centered around whether people familiar with the former behavior would be surprised by the (more general) behavior when using it in a class, but they came to agree that this is actually a simple and general model, and a helpful point of consistency.</p>
<p>In contrast, there are still a number of concerns with re-branding <code class="language-plaintext highlighter-rouge">x.dynamicType</code> as <code class="language-plaintext highlighter-rouge">x.Self</code>. This may (or may not) be the right ultimate direction to go, but it should be split out of this proposal. There is another outstanding proposal that would eliminate the <code class="language-plaintext highlighter-rouge">Type.self</code> syntax as being necessary, and the core team would like to resolve that discussion before tackling <code class="language-plaintext highlighter-rouge">x.dynamicType</code>.</p>
<p>Thank you to Erica Sadun for proposing this! I filed <a href="https://bugs.swift.org/browse/SR-1340">SR-1340</a> to track implementation work for this, this would be a great starter project for someone interested in getting involved in the Swift compiler.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md">SE-0070</a>: <em>Make Optional Requirements Objective-C-only</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000109.html">under review</a>.</p>
<blockquote>
<p>Swift currently has support for “optional” requirements in Objective-C protocols, to match with the corresponding feature of Objective-C. We don’t want to make optional requirements a feature of Swift protocols, nor can we completely eliminate the notion of the language. Therefore, to prevent confusion about our direction, this proposal requires an explicit <code class="language-plaintext highlighter-rouge">@objc</code> attribute on each optional requirement to indicate that this is an Objective-C compatibility feature.</p>
</blockquote>
<p>Tony Parker’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md">SE-0069</a>: <em>Mutability and Foundation Value Types</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000110.html">under review</a>. There is overwhelmingly positive support for this proposal from the community.</p>
<blockquote>
<p>When certain Foundation types are imported into Swift, they do not fully take advantage of the features that Swift has to offer developers for controlling mutability of their objects.</p>
<p>This proposal describes a straightforward concept for providing this capability. It describes a set of new Foundation value types which wrap their corresponding reference types. This is a technique used by the standard library. This allows us to:</p>
<ol>
<li>Improve the developer experience,</li>
<li>Increase performance for small types like Date</li>
<li>Preserving the ability for developers to customize the behavior of most types.</li>
</ol>
</blockquote>
<p>Regarding the performance of these changes:</p>
<blockquote>
<p>In microbenchmarks designed to test access time for <code class="language-plaintext highlighter-rouge">Date.timeIntervalSinceReferenceDate</code>, the Swift <code class="language-plaintext highlighter-rouge">struct</code> consistently performed about 15% faster. […]</p>
<p>In microbenchmarks designed to test mutation for a new <code class="language-plaintext highlighter-rouge">Date.addTimeInterval</code> versus creating new <code class="language-plaintext highlighter-rouge">NSDate</code> objects with <code class="language-plaintext highlighter-rouge">dateByAddingTimeInterval</code>, the mutation approach was consistently about 40 times faster. […]</p>
</blockquote>
<p>The review period has <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000111.html">been extended</a> for Stephen Canon’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md">SE-0067</a>: <em>Enhanced Floating Point Protocols</em>. <em>“Steve opted to revise his original proposal in order to incorporate great feedback from the original review period. As such, we’re extending the review period in order to get adequate consideration of his new changes.”</em></p>
<p>Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md">SE-0071</a>: <em>Allow (most) keywords in member references</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000112.html">under review</a>. I recently ran into this issue trying to add a <code class="language-plaintext highlighter-rouge">case default</code> enum. So far, there’s positive feedback for this proposal. 🙌</p>
<blockquote>
<p>The <a href="https://swift.org/documentation/api-design-guidelines/">Swift API Design Guidelines</a> consider <code class="language-plaintext highlighter-rouge">enum</code> cases as values that use the lowerCamelCase naming conventions. This means that case names that previously did not conflict with keywords (such as <code class="language-plaintext highlighter-rouge">Default</code>, <code class="language-plaintext highlighter-rouge">Private</code>, <code class="language-plaintext highlighter-rouge">Repeat</code>) now cause conflicts, a problem that is particularly acute when the naming conventions are applied by the Clang importer (per
<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md">SE-0005</a>). To mitigate this issue, this proposal allows the use of most keywords after a “.”, similarly to how <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0001-keywords-as-argument-labels.md">SE-0001</a> allows keywords are argument labels.</p>
</blockquote>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md">SE-0066</a>: <em>Standardize function type argument syntax to require parentheses</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000113.html">under review</a>.</p>
<blockquote>
<p>Function types in Swift use parentheses around their parameter list (aligning with the function declaration syntax, as well as the syntax used to call a function). However, in the degenerate case of a single non-variadic, unlabeled argument with no attributes, Swift allows the parentheses to be omitted. While this saves some parentheses, it introduces some minor problems, is not consistent with other parts of the Swift grammar, reduces consistency within function types themselves, and offers no additional expressive capability.</p>
</blockquote>
<p>For example <code class="language-plaintext highlighter-rouge">(Int) -> Float</code> could be written as <code class="language-plaintext highlighter-rouge">Int -> Float</code> instead. This proposal would eliminate the latter. This is another great refinement to the language. These proposals that focus on consistency make me really happy. 😊</p>
<p>Joe Pamer’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0072-eliminate-implicit-bridging-conversions.md">SE-0072</a>: <em>Fully eliminate implicit bridging conversions from Swift</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000114.html">under review</a>. So far, there’s very little feedback from the community.</p>
<blockquote>
<p>In Swift 1.2, we attempted to remove all implicit bridging conversions from the language. Unfortunately, problems with how the v1.2 compiler imported various un-annotated Objective-C APIs caused us to scale back on our ambitions. In the interest of further simplifying our type system and our user model, we would like to complete this work and fully remove implicit bridging conversions from the language in Swift 3.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Tony Parker <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015503.html">introduced</a> his proposal on <em>Mutability and Foundation Value Types</em>. As mentioned above, this is currently under review.</p>
<blockquote>
<p>Dear swift-evolution denizens,</p>
<p>As you know from our announcement of Swift Open Source and our work on naming guidelines, one of our goals for Swift 3 is to “drop NS” for Foundation. We want to to make the cross-platform Foundation API that is available as part of swift-corelibs feel like it is not tied to just Darwin targets. We also want to reinforce the idea that new Foundation API must fit in with the language, standard library, and the rapidly evolving design patterns we see in the community.</p>
<p>You challenged us on one part of this plan: some Foundation API just doesn’t “feel Swifty”, and a large part of the reason why is that it often does not have the same value type behavior as other Swift types. We took this feedback seriously, and I would like to share with you the start of an important journey for some of the most commonly used APIs on all of our platforms: adopting value semantics for key Foundation types.</p>
</blockquote>
<p>John Holdsworth <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015500.html">revived</a> a previous <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001565.html">discussion</a> on adding multi-line string literals to Swift and even prepared a <a href="https://github.com/apple/swift/pull/2275">pull request</a> with an initial implementation. There seems to be a decent amount of interest from the community and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160418/015645.html">Chris Lattner</a> provided a lot of feedback on the idea.</p>
<p>Honza Dvorsky <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160425/000431.html">started a thread</a> about adding an option to SwiftPM to dump a package’s dependency tree. <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160425/000432.html">Daniel Dunbar</a> supports the idea. I think this would be pretty cool. 😎</p>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015920.html">pitched an idea</a> on requiring proactive overrides for default protocol implementations. She proposes requiring the <code class="language-plaintext highlighter-rouge">override</code> in cases where a class implements a protocol method that is already defined on a protocol extension. Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160425/015926.html">opposes</a> the idea.</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03#commitcomment-17265490">from reddit post to fix in less than 12 hours</a>, Joe Pamer pushes a <a href="https://github.com/apple/swift/commit/2cdd7d64e1e2add7bcfd5452d36e7f5fc6c86a03">fix</a> to “sober up” the <a href="https://spin.atomicobject.com/2016/04/26/swift-long-compile-time/">drunken</a> Swift compiler. 😂 (<a href="https://news.ycombinator.com/item?id=11573213">Hacker News</a>, <a href="https://www.reddit.com/r/programming/comments/4givdg/go_home_swift_compiler_youre_drunk/">reddit</a>)</p>
Issue #19
https://swiftweeklybrief.com/issue-19
2016-04-21T00:00:00-07:00
2016-04-21T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>As you must know by now, <a href="https://developer.apple.com/wwdc/">WWDC 2016</a> has been announced! What’s most surprising and exciting to me is the emphasis on Swift — it’s all over the WWDC pages on Apple’s site. I certainly did not expect <em>this strong</em> of a focus on Swift. Usually there are teasers about the upcoming OS and hardware releases. Of course, it’s no surprise that Swift 3.0 is coming so it makes me wonder, <em>what else</em> is planned for Swift that we don’t know about?</p>
<p>In other news, the <a href="https://twitter.com/clattner_llvm/status/722501792450228225">Xcode 7.3.1 GM seed</a> was released. It includes a bunch of bug fixes and <a href="https://github.com/apple/swift/releases/tag/swift-2.2.1-RELEASE">Swift 2.2.1</a>. However, the release notes didn’t specify the Swift version and the version number <a href="https://twitter.com/UINT_MIN/status/722821043979595777"><strong>did not</strong> get bumped</a> in Xcode. But don’t worry, the fixes are in there. 😄</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1266">SR-1266</a>: Remove duplication between <code class="language-plaintext highlighter-rouge">swift/test</code> and <code class="language-plaintext highlighter-rouge">swift/validation-test</code> configuration files. This is a good introduction to the Swift build system, its test suite, and CMake.</li>
<li><a href="https://bugs.swift.org/browse/SR-1263">SR-1263</a>: Compiler wrongfully complains of illegal syntax when declaring multiple conformances for a protocol’s associated type.</li>
<li><a href="https://bugs.swift.org/browse/SR-1238">SR-1238</a>: UnsafePointer and UnsafeMutablePointer should conform to Comparable</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Anna Zaks <a href="https://github.com/apple/swift/pull/2169">merged</a> some fixes and improvements to the <code class="language-plaintext highlighter-rouge">swift_demangle</code> API. 🤓</p>
<p>Alex Hoppen submitted a <a href="https://github.com/apple/swift/pull/2224">pull request</a> that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md">SE-0036</a>: <em>Requiring Leading Dot Prefixes for <code class="language-plaintext highlighter-rouge">enum</code> Instance Member Implementations</em>. (<a href="https://bugs.swift.org/browse/SR-1236">SR-1236</a>). 👍</p>
<p>Brian Gesiak opened a <a href="https://github.com/apple/swift/pull/1714">pull request</a> to begin adding testing support for Android.</p>
<p>Max Howell <a href="https://github.com/apple/swift-package-manager/pull/254">merged</a> changes that add a flag to make the build output location of SwiftPM configurable.</p>
<p>Daniel Eggert’s implementation of <code class="language-plaintext highlighter-rouge">NSHTTPURLResponse</code> has <a href="https://github.com/apple/swift-corelibs-foundation/pull/287">merged</a>. 🎉</p>
<p>Brian Gesiak opened a <a href="https://github.com/apple/swift-corelibs-xctest/pull/96">pull request</a> to expand the Linux/FreeBSD check to include Android. It’s so weird to see <code class="language-plaintext highlighter-rouge">#if os(Android)</code>. 😄</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2210">merged</a> changes that allow Objective-C generic extensions to perform <code class="language-plaintext highlighter-rouge">@objc</code> operations involving generics. <em>“This should allow an extension to use the generic class’s own API to some degree, as it would if defined on the non-generic form.”</em></p>
<p>John Holdsworth submitted a <a href="https://github.com/apple/swift/pull/2197">pull request</a> with an implementation of a swift-format tool to indent swift source code from the command line using the new libIDE API (<a href="https://bugs.swift.org/browse/SR-146">SR-146</a>). 👏 Unfortunately, it looks like it was closed due to some <a href="https://github.com/apple/swift/pull/2197#issuecomment-212106820">git rebasing</a> problems. 😅 It looks like John will open a fresh pull request soon.</p>
<p>Ted Kremenek opened a <a href="https://github.com/apple/swift/pull/2215">pull request</a> that implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md">SE-0039</a>: <em>Modernizing Playground Literals</em>. 😎</p>
<p>Mauricio Meirelles submitted a <a href="https://github.com/apple/swift-corelibs-foundation/pull/320">pull request</a> that begins implementing <code class="language-plaintext highlighter-rouge">NSMassFormatter</code>.</p>
<p>There were a ton of changes merged to corelibs-foundation to update the APIs for the <a href="https://swift.org/blog/swift-api-transformation/"><em>Great API Transformation</em></a>. <a href="https://media.giphy.com/media/cD8fdv2wxuy9G/giphy.gif">It’s happening</a>.</p>
<ul>
<li>Robert F. Dickerson <a href="https://github.com/apple/swift-corelibs-foundation/pull/325">updated</a> <code class="language-plaintext highlighter-rouge">NSDate</code>, <code class="language-plaintext highlighter-rouge">NSTimeZone</code>, and <code class="language-plaintext highlighter-rouge">NSDateFormatter</code>.</li>
<li>Pushkar N Kulkarni <a href="https://github.com/apple/swift-corelibs-foundation/pull/322">updated</a> <code class="language-plaintext highlighter-rouge">NSCache</code> and <a href="https://github.com/apple/swift-corelibs-foundation/pull/324">updated</a> <code class="language-plaintext highlighter-rouge">NSHTTPCookie</code>.</li>
<li><strong>@saiHemak</strong> <a href="https://github.com/apple/swift-corelibs-foundation/pull/336">updated</a> <code class="language-plaintext highlighter-rouge">NSCalendar</code>.</li>
<li>Bhaktavatsal Reddy <a href="https://github.com/apple/swift-corelibs-foundation/pull/323">updated</a> <code class="language-plaintext highlighter-rouge">NSData</code>.</li>
</ul>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>It was a big week for proposals! 🎉</p>
<p>Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md">SE-0057</a>: <em>Importing Objective-C Lightweight Generics</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000097.html">accepted</a> <strong>for Swift 3</strong>.</p>
<blockquote>
<p>This proposal only received light commentary from the community, but that feedback was universally positive. The core team agrees that this is will greatly improve the expressivity of imported Objective-C APIs into Swift. The implementation work is quite far along, and while there are still a couple engineering-level questions left, the design is solid, so we are comfortable accepting it at this point.</p>
</blockquote>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md">SE-0048</a>: <em>Generic Type Aliases</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000098.html">accepted</a> <strong>for Swift 3</strong>. <em>“The proposal received overwhelmingly positive feedback and has now been implemented for Swift 3.”</em> 😧</p>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md">SE-0049</a>: <em>Move <code class="language-plaintext highlighter-rouge">@noescape</code> and <code class="language-plaintext highlighter-rouge">@autoclosure</code> to be type attributes</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000099.html">accepted</a> <strong>for Swift 3</strong>. <em>“Feedback on the proposal was light but positive.”</em> The work for this was tracked at <a href="https://bugs.swift.org/browse/SR-1235">SR-1235</a> and it looks like Chris has finished most of the work. 👏</p>
<p>Erica Sadun’s and Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md">SE-0036</a>: <em>Requiring Leading Dot Prefixes for <code class="language-plaintext highlighter-rouge">enum</code> Instance Member Implementations</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000100.html">accepted</a> <strong>for Swift 3</strong>. <em>“We welcome an implementation of this proposal.”</em> As mentioned above, Alex Hoppen already submitted a <a href="https://github.com/apple/swift/pull/2224">pull request</a> for this. 🎉</p>
<p>David Hart’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md">SE-0062</a>: <em>Referencing Objective-C key-paths</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000101.html">accepted</a> <strong>for Swift 3</strong>. This work is being tracked at <a href="https://bugs.swift.org/browse/SR-1237">SR-1237</a>.</p>
<blockquote>
<p>The proposal is accepted, with one adjustment to the handling of collections: rather than support any SequenceType as a collection, the core team wants a narrower rule for only the primary Cocoa collection types (<code class="language-plaintext highlighter-rouge">NSArray</code>, <code class="language-plaintext highlighter-rouge">NSDictionary</code>, <code class="language-plaintext highlighter-rouge">NSSet</code>) and their Swift-bridged equivalents (<code class="language-plaintext highlighter-rouge">Array</code>, <code class="language-plaintext highlighter-rouge">Dictionary</code>, <code class="language-plaintext highlighter-rouge">Set</code>), due to implementation concerns. Feedback on this proposal was generally positive, and the proposal fits well with <code class="language-plaintext highlighter-rouge">#selector</code> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>).</p>
</blockquote>
<p>David Hart’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md">SE-0064</a>: <em>Referencing the Objective-C selector of property getters and setters</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000102.html">accepted</a> <strong>for Swift 3</strong>. <em>“Feedback was light but positive, with many considering this to effectively be an obviously missing piece of the <code class="language-plaintext highlighter-rouge">#selector</code> proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>.”</em> Work is being tracked at <a href="https://bugs.swift.org/browse/SR-1239">SR-1239</a>. Alex Hoppen is working on an implementation.</p>
<p>Max Howell’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md">SE-0063</a>: <em>SwiftPM System Module Search Paths</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000104.html">accepted</a> <strong>for Swift 3</strong>. <em>“Feedback was light but positive, which was not surprising since there had been email discussions of this topic for some time and there was general agreement about the need.”</em></p>
<p>Dave Abrahams’ proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md">SE-0059</a>: <em>Update API Naming Guidelines and Rewrite <code class="language-plaintext highlighter-rouge">Set</code> APIs Accordingly</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000105.html">accepted</a> <strong>for Swift 3</strong>.</p>
<blockquote>
<p>There was much debate, both before and during the review, over the “InPlace” suffix / “form” prefix, and at this point any answer will be objectionable to some. The core team has opted to accept the proposal as-is, keeping the “form” prefix to describe the mutating counterpart to an operation naturally described by a noun (e.g., “formUnion” for the mutating variant of “union”), for the reasons described in the proposal itself. Thanks all for the spirited discussion!</p>
</blockquote>
<h3 id="rejected-proposals">Rejected Proposals</h3>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md">SE-0056</a>: <em>Allow trailing closures in <code class="language-plaintext highlighter-rouge">guard</code> conditions</em> has been <strong>rejected</strong>. <em>“The core team felt that the benefits from this change were outweighed by the inconsistency it would introduce with <code class="language-plaintext highlighter-rouge">if</code> and <code class="language-plaintext highlighter-rouge">while</code>.”</em></p>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Stephen Canon’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0067-floating-point-protocols.md">SE-0067</a>: <em>Enhanced Floating Point Protocols</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000106.html">under review</a>. So far, feedback is light but positive.</p>
<blockquote>
<p>The current <code class="language-plaintext highlighter-rouge">FloatingPoint</code> protocol is quite limited, and provides only a small subset of the features expected of an IEEE 754 conforming type. This proposal expands the protocol to cover most of the expected basic operations, and adds a second protocol, <code class="language-plaintext highlighter-rouge">BinaryFloatingPoint</code>, that provides a number of useful tools for generic programming with the most commonly used types.</p>
</blockquote>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0068-universal-self.md">SE-0068</a>: <em>Expanding Swift <code class="language-plaintext highlighter-rouge">Self</code> to class members and value types</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000107.html">under review</a>. Currently, there’s a lot of mixed feedback.</p>
<blockquote>
<p>Within a class scope, <code class="language-plaintext highlighter-rouge">Self</code> means “the dynamic class of self”. This proposal extends that courtesy to value types and to the bodies of class members by renaming <code class="language-plaintext highlighter-rouge">dynamicType</code> to <code class="language-plaintext highlighter-rouge">Self</code>. This establishes a universal and consistent way to refer to the dynamic type of the current receiver.</p>
</blockquote>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Max Howell started a <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160418/000420.html">discussion</a> on allowing further module organization in SwiftPM. Currently the module layout rules prevent you from grouping related modules in subdirectories, Max discusses possible solutions to allow this. He also notes that package authors have a clear preference toward a root <code class="language-plaintext highlighter-rouge">Sources/</code> directory and suggests making this required, that is, using <code class="language-plaintext highlighter-rouge">src/</code> and other variants would be errors.</p>
<p>Nate Cook <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/015131.html">asked for feedback</a> on a draft proposal to expand the <code class="language-plaintext highlighter-rouge">min()</code> and <code class="language-plaintext highlighter-rouge">max()</code> sequence methods. <em>“This proposal would expand on the <code class="language-plaintext highlighter-rouge">min()</code> and <code class="language-plaintext highlighter-rouge">max()</code> sequence methods to add methods that return the corresponding index for a collection, efficiently find the minimum and maximum elements or indices at the same time, and provide extension points for sorted collections to provide all these results more efficiently.”</em></p>
<h3 id="finally">Finally</h3>
<p>And finally — if you needed help decoding that WWDC announcement, Erica Sadun <a href="https://twitter.com/ericasadun/status/722266416460640256">can help</a>. 😄</p>
Issue #18
https://swiftweeklybrief.com/issue-18
2016-04-14T00:00:00-07:00
2016-04-14T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>If you have not <a href="https://twitter.com/modocache/status/720139771771805697">heard it already</a>, the big news this week is that the <a href="https://github.com/apple/swift/pull/1442">port to Android</a> pull request from <a href="https://twitter.com/modocache">Brian Gesiak</a> and <a href="https://twitter.com/zhuowei">Zhuowei Zhang</a> has finally <a href="https://github.com/apple/swift/pull/1442#issuecomment-209215000">merged</a> after a month and a half of review and discussion. 🎉 👏 🙌 No matter what, this was going to be significant addition to Swift. However, as <a href="https://iosdevweekly.com/issues/245#start">Dave Verwer noted</a> in <em>iOS Dev Weekly</em> last week, it seems even more important given the <a href="http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swift/">recent rumors</a> that Google may be considering Swift for Android.</p>
<p>As mentioned last week, the <a href="https://github.com/apple/swift/pulls?q=milestone%3A%22Swift+2.2.x%22">Swift 2.2.x milestone</a> is still open and remains unchanged — all 33 issues closed. The Swift 2.2 <a href="https://github.com/apple/swift/tree/swift-2.2-branch">branch</a> is currently 363 commits ahead of master, but the most recent activity was 8 days ago. Maybe we’ll see an official release soon?</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1187">SR-1187</a>: [SPM] Add example test to Dealer example</li>
<li><a href="https://bugs.swift.org/browse/SR-1174">SR-1174</a>: [llbuild] Properly escape verbose command descriptions</li>
<li><a href="https://bugs.swift.org/browse/SR-580">SR-580</a>: [Compiler] Warning should be produced for “variable was never mutated”</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="community">Community</h3>
<p>In other exciting news, <a href="https://twitter.com/NatashaTheRobot/status/720234080860815360">@NatashaTheRobot</a> is organizing another <em>try! Swift</em> conference. This time it will be in <a href="http://www.tryswiftnyc.com">NYC</a>. The first one was great, so I highly recommend attending if you can. The current list of speakers looks great! 🤓</p>
<p>I just noticed this week that <a href="https://twitter.com/nnnnnnnn">Nate Cook</a> has updated <a href="http://swiftdoc.org">swiftdoc.org</a> to include not only the latest Swift 2.2 docs, but multiple <a href="http://swiftdoc.org/versions/">other versions</a> of the stdlib — including Swift 3.0 from swift/master and the new index model. This is such a great resource! 🙇 The entire site and other tools are on <a href="https://github.com/SwiftDocOrg">GitHub</a> if you want to contribute. I also noticed the updated copyright footer on the site, <em>“All content copyright © 2014–2016 <strong>Apple Inc.</strong> All rights reserved.”</em> 😧</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Harlan Haskins opened a <a href="https://github.com/apple/swift/pull/2092">pull request</a> that adds a fixit to hide the first parameter label in functions. This is part of the effort to implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md">SE-0046</a>: <em>Establish consistent label behavior across all parameters including first labels</em>.</p>
<p>Daniel Duan <a href="https://github.com/apple/swift/pull/2087">merged</a> some changes to clean up SILGen, eliminating SILGen for <code class="language-plaintext highlighter-rouge">var</code> parameters in functions, which are being removed in Swift 3.</p>
<p>Manav Gabhawala opened a <a href="https://github.com/apple/swift/pull/2124">pull request</a> that fixes an infinite recursion in the compiler when inheriting from a member of the same type.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/2086">merged</a> changes that allow subclasses of specific instantiations of Objective-C generic classes.</p>
<p>Michael Buckley opened a <a href="https://github.com/apple/swift/pull/2163">pull request</a> that implements his proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md">SE-0016</a>: <em>Add initializers to <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">UInt</code> to convert from <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code></em>. (<a href="https://bugs.swift.org/browse/SR-1115">SR-1115</a>)</p>
<p><strong>@goloveychuk</strong> <a href="https://github.com/apple/swift-package-manager/pull/243">merged</a> changes to swift-package-manager to fix an issue where SPM did not support Xcode project generation for system packages. (<a href="https://bugs.swift.org/browse/SR-1169">SR-1169</a>)</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift/pull/2081">merged</a> changes that unify the Linux and FreeBSD modulemaps with gyb to reduce code duplication.</p>
<p>Daniel Cohen Gindi opened and later closed a <a href="https://github.com/apple/swift/pull/2125">pull request</a> to allow <code class="language-plaintext highlighter-rouge">Strideable</code> to have a zero size. <em>“But moreover, Xcode itself expects it to allow 0 length stride. As Xcode automatically converts old for-loops to strides, it actually breaks code that may in some cases have zero-length strides.”</em> This is definitely something to watch out for if you are migrating to Swift 2.2 with Xcode’s migration tool. As <a href="https://github.com/apple/swift/pull/2125#issuecomment-208191381">noted</a> on the pull request, this particular patch was not the right one, but it has convinced Dave Abrahams that there needs to be a <code class="language-plaintext highlighter-rouge">stride</code> function that works for this case.</p>
<p>Michael Ilseman <a href="https://github.com/apple/swift/pull/2107">merged</a> a first draft of his proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md">SE-0044</a>: <em>Import as member</em>, for the CoreGraphics APIs.</p>
<p>Trent Nadeau <a href="https://github.com/apple/swift/pull/2103">merged</a> changes for part of <a href="https://bugs.swift.org/browse/SR-1052">SR-1052</a>, which is tracking the implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md">SE-0047</a>: <em>Defaulting non-Void functions so they warn on unused results</em>. His patch adds the <code class="language-plaintext highlighter-rouge">@discardableResult</code> attribute to imported C declarations without the Clang <code class="language-plaintext highlighter-rouge">warn_unused_result</code> attribute.</p>
<p>Manav Gabhawala opened a <a href="https://github.com/apple/swift/pull/2123">pull request</a> that fixes the <code class="language-plaintext highlighter-rouge">IterativeTypeChecker</code> and better manages circular protocol inheritance. <em>“Improves the diagnostics produced for circular protocol inheritance, further it improves the IterativeTypeChecker to use loops instead of recursion to help minimize the stack size and lastly improves the efficiency of detecting circular inheritance by making it a part of the main cycle when checking for inherited protocols.”</em></p>
<h3 id="deferred-proposals">Deferred proposals</h3>
<p>Russ Bishop’s and Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md">SE-0058</a>: <em>Allow Swift types to provide custom Objective-C representations</em> has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000095.html"><strong>deferred</strong></a> from Swift 3. Joe Groff explains that it is simply too early to commit to a public API for this. Interestingly, he mentions the idea of bridging with JVM in the future… 🤔 🤐</p>
<blockquote>
<p>We agree that it would be valuable to give library authors the ability to bridge their own types from Objective-C into Swift using the same mechanisms as Foundation. However, we lack the confidence and implementation experience to commit to <code class="language-plaintext highlighter-rouge">_ObjectiveCBridgeable</code> in its current form as public API. In its current form, as its name suggests, the protocol was designed to accommodate the specific needs of bridging Objective-C object types to Swift value types. In the future, we may want to bridge with other platforms, including C++ value types or other object systems such as COM, GObject, JVM, or CLR. It isn’t clear at this point whether these would be served by a generalization of the existing mechanism, or by bespoke bridging protocols tailored to each case. This is a valuable area to explore, but we feel that it is too early at this point to accept our current design as public API.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>David Hart’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md">SE-0062</a>: <em>Referencing Objective-C key-paths</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000091.html">under review</a>. <em>“In Objective-C and Swift, key-paths used by KVC and KVO are represented as string literals. This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression.”</em> David proposes adding a new <code class="language-plaintext highlighter-rouge">#keyPath</code> expression, similar to newly added <code class="language-plaintext highlighter-rouge">#selector</code> expression in Swift 2.2. It seems like a reasonable follow up on Doug Gregor’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>. Surprisingly, there is not much feedback on the lists yet, but it is positive.</p>
<p>David Hart’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md">SE-0064</a>: <em>Referencing the Objective-C selector of property getters and setters</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000092.html">under review</a>. This proposal is a great extension of Doug Gregor’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>, that will address its current deficiencies. Again, there is not much feedback for this proposal either, but the feedback so far is positive.</p>
<blockquote>
<p>“Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a> was accepted and implemented to provide a #selector expression to reference Objective-C method selectors. Unfortunately, it does not allow referencing the getter and setter methods of properties. This proposal seeks to provide a design to reference those methods for the Swift 3.0 timeframe.”</p>
<p>The <code class="language-plaintext highlighter-rouge">#selector</code> expression is very useful but does not yet cover all cases. Accessing property getter and setters requires to drop down to the string syntax and forgo type-safety. This proposal supports this special case without introducing new syntax, but by introducing new overloads to the <code class="language-plaintext highlighter-rouge">#selector</code> compiler expression.</p>
</blockquote>
<p>A proposal from Dmitri Gribenko, Dave Abrahams, and Maxim Moiseev, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md">SE-0065</a>: <em>A New Model for Collections and Indices</em> is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000094.html">under review</a>.</p>
<blockquote>
<p>We propose a new model for <code class="language-plaintext highlighter-rouge">Collection</code>s wherein responsibility for index traversal is moved from the index to the collection itself. For example, instead of writing <code class="language-plaintext highlighter-rouge">i.successor()</code>, one would write <code class="language-plaintext highlighter-rouge">c.successor(of: i)</code>. We also propose the following changes as a consequence of the new model:</p>
<ul>
<li>A collection’s Index can be any <code class="language-plaintext highlighter-rouge">Comparable</code> type.</li>
<li>The distinction between intervals and ranges disappears, leaving only ranges.</li>
<li>A closed range that includes the maximal value of its <code class="language-plaintext highlighter-rouge">Bound</code> type is now representable and does not trap.</li>
<li>Existing “private” in-place index traversal methods are now available publicly.</li>
</ul>
</blockquote>
<p>As expected with such a fundamental change, there’s a lot of discussion. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014741.html">Nate Cook</a> expresses some concern over APIs and naming, but ultimately gives it a +1000. There are a number of other +1’s on the lists, too. I think the community is in favor of the core idea, it’s just a matter of working out some of the details, and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014658.html">Becca Royal-Gordon</a> is doing just that.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014869.html">pitched an idea</a> to rename <code class="language-plaintext highlighter-rouge">x.dynamicType</code> to <code class="language-plaintext highlighter-rouge">x.Self</code>. So far, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014871.html">William Dillon</a>, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014872.html">Eugene Gubin</a>, and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014885.html">Ilya Belenkiy</a> are enthusiastic about the idea.</p>
<blockquote>
<p>It’s been pitched before, but I don’t think we’ve had a dedicated thread to this idea. Erica has proposed making <code class="language-plaintext highlighter-rouge">Self</code> generally available within methods in types to refer to the dynamic type of the current receiver. One could think of <code class="language-plaintext highlighter-rouge">Self</code> as a special associated type member that exists in every type for this purpose. This also happens to be what you get when ask for the <code class="language-plaintext highlighter-rouge">dynamicType</code> member of a value. We could unify these concepts and get rid of the clunky <code class="language-plaintext highlighter-rouge">dynamicType</code> keyword, replacing it with <code class="language-plaintext highlighter-rouge">x.Self</code>.</p>
<p>There’s another benefit to this syntax change. Looking to the future, one of the many features Doug pitched in his <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html">generics manifesto</a> was to generalize protocol existentials, lifting our current restrictions on protocols “with Self or associated types” and allowing them to be used as dynamic types in addition to static generic constraints. Once you do this, you often want to “open” the type of the existential, so that you can refer to its Self and associated types in the types of other values. I think a natural way would be to let you directly use Self and associated type members of existentials as types themselves</p>
</blockquote>
<p>Jacob Bandes-Storch started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014667.html">discussion</a> on adding arbitrary requirements in protocols, noting what Doug Gregor wrote in the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011666.html"><em>Completing Generics manifesto</em></a>. He asks what it would take to get this feature into Swift 3.</p>
<p>Along with the discussion over the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md">SE-0065</a> proposal, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014688.html">Joe Groff</a>, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014691.html">Stephen Canon</a>, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014693.html">Trent Nadeau</a>, and Dave Abrahams, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160411/014740.html">discuss</a> the grammatical merits of “indices” versus “indexes”. 😂 I guess sometimes grammar is <a href="https://en.wikipedia.org/wiki/Context-sensitive_grammar">context-sensitive</a>. 😉 (See what I did there?)</p>
<h3 id="finally">Finally</h3>
<p>And finally — if you work on the linker, you must be <a href="https://twitter.com/jckarter/status/719684649027391488">willing to relocate C++</a>. 😅</p>
Issue #17
https://swiftweeklybrief.com/issue-17
2016-04-07T00:00:00-07:00
2016-04-07T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #17! After all this time, the core team is still <a href="https://github.com/apple/swift/pull/2001#issuecomment-204765081">just as encouraging</a> to contributors as it was on day one. It’s really cool to see this. 😎 Meanwhile, the <a href="https://github.com/apple/swift/milestones/Swift%202.2.x">Swift 2.2.x milestone</a> accumulated more issues, and as of this writing all 33 issues are closed. Maybe we’ll see a patch release for 2.2 soon? Also, yesterday Apple released new betas for iOS 9.3.2, tvOS 9.2.1, watchOS 2.2.1, and OS X 10.11.5 — notably absent is Xcode.</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1145">SR-1145</a>: XCTestSuite doc comments describe behavior exclusive to Apple XCTest</li>
<li><a href="https://bugs.swift.org/browse/SR-1141">SR-1141</a>: [llbuild] Add support for understanding Swift parseable output</li>
<li><a href="https://bugs.swift.org/browse/SR-216">SR-216</a>: Increase test coverage on Linux</li>
<li><a href="https://bugs.swift.org/browse/SR-1111">SR-1111</a>: Non-optimized builds should avoid redundant <code class="language-plaintext highlighter-rouge">thick_to_objc_metatype</code> conversions</li>
</ul>
<p>Suggestions from <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/30">Brian Gesiak</a>:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1124">SR-1124</a>: Migrate legacy Swift stdlib tests to the StdlibUnittest framework. This would make those tests easier to read and maintain. Over the course of completing this task, newcomers to Swift development would become familiar with several tools used to test the compiler. There are 35 tests in total — feel free to claim individual tests by commenting on the task.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><strong>@swift-ci</strong> now knows how to “<a href="https://github.com/apple/swift/pull/2064#issuecomment-206137867">Please ASAN test</a>”. 😎</p>
<p>Harlan Haskins <a href="https://github.com/apple/swift/pull/2001">started work</a> on implementing proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md">SE-0046</a>: <em>Establish consistent label behavior across all parameters including first labels</em>. (<a href="https://bugs.swift.org/browse/SR-961">SR-961</a>) 👍 However, Manav Gabhawala <a href="https://github.com/apple/swift/pull/2047">did too</a>. 😳 It looks like everyone is collaborating on Manav’s pull request now. Consider this a friendly reminder to remember to (1) assign JIRA tickets and (2) to check what’s in-progress before starting work on a task. 😄</p>
<p>Anna Zaks merged a <a href="https://github.com/apple/swift/pull/2076">pull request</a> that adds experimental support for Thread Sanitizer (TSAN), and fixed a bunch of races it reported. Nice! 🎉</p>
<p>Kevin Lundberg submitted a <a href="https://github.com/apple/swift-corelibs-foundation/pull/127">pull request</a> to corelibs-foundation that adds block and boolean <code class="language-plaintext highlighter-rouge">NSPredicate</code>s, <code class="language-plaintext highlighter-rouge">NSCompoundPredicate</code>, and an implementation of <code class="language-plaintext highlighter-rouge">NSArray.filteredArrayUsingPredicate</code>.</p>
<p>Dave Abrahams opened a <a href="https://github.com/apple/swift/pull/2002">pull request</a> for the new <code class="language-plaintext highlighter-rouge">Set</code> (Algebra) API changes. 🤓</p>
<p>David Grove submitted a <a href="https://github.com/apple/swift/pull/1994">pull request</a> to enable the <code class="language-plaintext highlighter-rouge">_ObjectiveCBridgeable</code> protocol on Linux, and opened a corresponding <a href="https://github.com/apple/swift-corelibs-foundation/pull/303">pull request</a> on corelibs-foundation that implements basic usage of the <code class="language-plaintext highlighter-rouge">_ObjectiveCBridgeable</code> protocol on Linux. 🙌</p>
<p>Jesse Rusak <a href="https://github.com/apple/swift/pull/1732">merged</a> an implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md">SE-0037</a>: <em>Clarify interaction between comments & operators</em>, which resolves <a href="https://bugs.swift.org/browse/SR-186">SR-186</a> and <a href="https://bugs.swift.org/browse/SR-960">SR-960</a>.</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/219">merged</a> a pull request on swift-package-manager that adds the ability to auto-generate module map files for C libraries.</p>
<p>Harlan Haskins merged two pull requests to <a href="https://github.com/apple/swift-lldb/pull/8">swift-lldb</a> and <a href="https://github.com/apple/swift-corelibs-foundation/pull/305">corelibs-foundation</a> that implement changes specified by proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md">SE-0046</a>: <em>Establish consistent label behavior across all parameters including first labels</em>. 👏</p>
<p>Trent Nadeau submitted a <a href="https://github.com/apple/swift/pull/2044">pull request</a> that implements part of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md">SE-0047</a>: <em>Defaulting non-Void functions so they warn on unused results</em> (<a href="https://bugs.swift.org/browse/SR-1052">SR-1052</a>) — change the standard library to use <code class="language-plaintext highlighter-rouge">@discardableResult</code> on mutating methods that return values.</p>
<p>Ezekiel Pierson <a href="https://github.com/apple/swift/pull/2045">merged</a> a fix for <a href="https://bugs.swift.org/browse/SR-1022">SR-1022</a> which adds an “unused result” warning for <code class="language-plaintext highlighter-rouge">#selector</code>.</p>
<p>Nate Cook submitted a <a href="https://github.com/apple/swift/pull/2070">pull request</a> that fixes a bug in the <code class="language-plaintext highlighter-rouge">LazyFilterCollection</code> index moving functions where they did not trap on advancing past <code class="language-plaintext highlighter-rouge">endIndex</code> and in some cases did not terminate at all. 👍</p>
<p>Jordan Rose opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/304">pull request</a> on corelibs-foundation to update APIs for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md">SE-0055</a>: <em>Make unsafe pointer nullability explicit using Optional</em>.</p>
<h3 id="accepted-proposals">Accepted proposals</h3>
<p>Chris Willmore’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054</a>: <em>Abolish <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> type</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000084.html">accepted</a>, <strong>pending implementation</strong>.</p>
<blockquote>
<p>There is generally positive feedback on the proposal, as it keeps the good behaviors of the existing <code class="language-plaintext highlighter-rouge">T!</code> type syntax (including support for importing un-nullability-audited APIs, support for 2-phase initialization patterns, etc) while dramatically reducing the confusion and surprise that they introduce as they trickle through type inference. The core team sees significant value in having a simple and predictable model that can be explained concisely.</p>
<p>That said, this is the sort of proposal that can have a profound impact on the actual experience using unaudited APIs. The core team believes that the experience will be good, but we would like to get some experience moving a couple of existing projects (both low-level code that interacts with C, and an “App” project working with high level frameworks) to see what the impact is in practice. If something unexpected comes up, we will revisit this, and potentially reject it later. Chris Willmore is working on an implementation of this now, so we should know in the next week or two.</p>
</blockquote>
<p>Of course, another option would be to make Swift <a href="https://twitter.com/modocache/status/715703413112176640">9000x safer</a> with this one small <a href="https://github.com/modocache/swift/commit/e5ebd2e9d98eadb7bbddfcdbbf1a1064eb07a9f1">commit</a>. 😂</p>
<p>Jordan Rose’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md">SE-0055</a>: <em>Make unsafe pointer nullability explicit using Optional</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000086.html">accepted</a> <strong>for Swift 3</strong>.</p>
<blockquote>
<p>The community and core team overall agree that it is best to make the null pointer processing more consistent (by eliminating types that can be nil, but which are not Optional). While UnsafePointer is disliked by many in the community, it is a necessary part of working with C APIs (as one prominent example). Making them work consistently with other types makes the language simpler and more predictable. This approach also dovetails well with the Clang nullability attributes, which allow auditing of C pointers.</p>
</blockquote>
<h3 id="proposals-in-review">Proposals in review</h3>
<p>Russ Bishop’s and Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0058-objectivecbridgeable.md">SE-0058</a>: <em>Allow Swift types to provide custom Objective-C representations</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000090.html">under review</a>. This proposal would provide an <code class="language-plaintext highlighter-rouge">ObjectiveCBridgeable</code> protocol that allows a Swift type to control how it is represented in Objective-C by converting into and back from an entirely separate <code class="language-plaintext highlighter-rouge">@objc</code> type. So far, there are some questions from the community to clarify the proposal, but there’s support for the idea.</p>
<p>Erica Sadun’s and Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md">SE-0036</a>: <em>Requiring Leading Dot Prefixes for Enum Instance Member Implementations</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000088.html">under review</a>. This is another great refinement to the language that will make it more consistent.</p>
<blockquote>
<p>Enumeration cases are essentially static not instance type members. Unlike static members in structures and classes, enumeration cases can be mentioned in initializers and instance methods without referencing a fully qualified type. This makes little sense. In no other case can an instance implementation directly access a static member. This proposal introduces a rule that requires leading dots or fully qualified references (<code class="language-plaintext highlighter-rouge">EnumType.caseMember</code>) to provide a more consistent developer experience to clearly disambiguate static cases from instance members.</p>
</blockquote>
<p>Doug Gregor’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md">SE-0057</a>: <em>Importing Objective-C Lightweight Generics</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000085.html">under review</a>. <em>“Parameterized Objective-C classes lose their type parameters when they are imported into Swift, so uses of type parameters outside of bridged, typed collections (<code class="language-plaintext highlighter-rouge">NSArray</code>, <code class="language-plaintext highlighter-rouge">NSDictionary</code>, <code class="language-plaintext highlighter-rouge">NSSet</code>) don’t benefit in Swift. This proposal introduces a way to import the type parameters of Objective-C classes into Swift.”</em> There hasn’t been much feedback, but it looks like the community mostly agrees that this will enhance bridging between Swift and Objective-C.</p>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0056-trailing-closures-in-guard.md">SE-0056</a>: <em>Allow trailing closures in <code class="language-plaintext highlighter-rouge">guard</code> conditions</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000087.html">under review</a>. This proposes exactly what it says, but it’s easiest to explain with an example. The proposal would allow you to do the following, which currently is a syntax error:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="k">guard</span> <span class="k">let</span> <span class="nv">object</span> <span class="o">=</span> <span class="n">someSequence</span><span class="o">.</span><span class="n">findElement</span> <span class="p">{</span> <span class="nv">$0</span><span class="o">.</span><span class="nf">passesTest</span><span class="p">()</span> <span class="p">}</span> <span class="k">else</span> <span class="p">{</span>
<span class="k">return</span>
<span class="p">}</span></code></pre></figure>
<p>Dave Abrahams’ proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0059-updated-set-apis.md">SE-0059</a>: <em>Update API Naming Guidelines and Rewrite Set APIs Accordingly</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-April/000089.html">under review</a>. This proposal is mostly a followup from <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md">SE-0006</a>: <em>Apply API Guidelines to the Standard Library</em>, which left the <code class="language-plaintext highlighter-rouge">SetAlgebra</code> APIs unadjusted. This proposal establishes the necessary naming conventions and applies the changes to the <code class="language-plaintext highlighter-rouge">Set</code> APIs. Naming is always hard and not everyone will agree on what is “best”, but I think <em>we all can agree</em> that Dave and the team have put a tremendous amount of thought and effort into these API naming conventions and guidelines. 🙇</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>The discussion on <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Access Level</em> has reached <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/014008.html">a decision</a> regarding the new access level modifier names.</p>
<blockquote>
<p>The core team met to discuss this, and settled on the list above: <code class="language-plaintext highlighter-rouge">public</code>/<code class="language-plaintext highlighter-rouge">internal</code>/<code class="language-plaintext highlighter-rouge">fileprivate</code>/<code class="language-plaintext highlighter-rouge">private</code>. This preserves the benefit of the “fileprivate” concept that we have today in Swift, while aligning the “private” keyword with common expectations of people coming to Swift. This also makes “private” the “safe default” for cases where you don’t think about which one you want to use, and this schema will cause minimal churn for existing Swift code.</p>
</blockquote>
<p>Brian Gesiak started a <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160328/001594.html">discussion</a> about <a href="https://bugs.swift.org/browse/SR-710">SR-710</a> which tracks a major goal for Swift 3 — having SwiftPM and corelibs-xctest automatically generate a list of test methods to execute.</p>
<blockquote>
<p>Here’s the issue: currently, users of corelibs-xctest must manually list each test they wish to execute. This is tedious and error-prone. We need to do better by Swift 3!</p>
<p>Apple XCTest uses Objective-C reflection at runtime to compile a list of <code class="language-plaintext highlighter-rouge">NSInvocation</code> to execute as tests. We can’t use the same approach in Swift: as far as I know, there’s no reflection API that allows us to find instance methods defined on a class, and adding such an API is considered a stretch goal for Swift 3.</p>
</blockquote>
<p>Brian goes on to explore the different options available and solicit feedback from the core team.</p>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014132.html">pitched an idea</a> about adding a <code class="language-plaintext highlighter-rouge">Self</code> type name shortcut for static member access to allow using <code class="language-plaintext highlighter-rouge">Self</code> as a synonym for an instance’s type name. Consider the following:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">struct</span> <span class="kt">MyStruct</span> <span class="p">{</span>
<span class="kd">static</span> <span class="kd">func</span> <span class="nf">foo</span><span class="p">()</span> <span class="p">{</span> <span class="nf">print</span><span class="p">(</span><span class="s">"foo"</span><span class="p">)</span> <span class="p">}</span>
<span class="kd">func</span> <span class="nf">bar</span><span class="p">()</span> <span class="p">{</span>
<span class="kt">MyStruct</span><span class="o">.</span><span class="nf">foo</span><span class="p">()</span> <span class="c1">// works</span>
<span class="k">self</span><span class="o">.</span><span class="k">dynamicType</span><span class="o">.</span><span class="nf">foo</span><span class="p">()</span> <span class="c1">// works</span>
<span class="k">Self</span><span class="o">.</span><span class="nf">foo</span><span class="p">()</span> <span class="c1">// error</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p>Feedback on the idea has been positive and Erica has <a href="https://github.com/apple/swift-evolution/pull/248">drafted a proposal</a>.</p>
<p>Robert Widmann <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014309.html">pitched an idea</a> for moving <code class="language-plaintext highlighter-rouge">where</code> clauses <em>out</em> of parameter lists to make generic interfaces more readable, inspired by a <a href="https://twitter.com/ericasadun/status/717894196414132224">discussion on Twitter</a> with Erica Sadun and Joe Groff. It looks like the community is pretty supportive of the idea so far. I really hope we get that book, <a href="https://twitter.com/UINT_MIN/status/717918147555098627"><em>Saduns and Don’ts</em></a>. 😂</p>
<p>Dave Abrahams <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014134.html">started a thread</a>, “My personal beef with leading-dot syntax”. Dave notes a number of reasons why he dislikes the current leading-dot syntax, including that it’s a source of confusion and imposes unnecessary complexity. Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160404/014138.html">responded</a> with concerns on the impracticality of “making every unqualified reference context-dependent”, and there’s an interesting back-and-forth between the two of them. Personally, I really like the leading-dot syntax. 😄</p>
<h3 id="finally">Finally</h3>
<p>And finally — with all of the recent API transformations, guideline changes, and anticipation for Swift 3, you might be wondering <a href="https://twitter.com/harlanhaskins/status/717164997831307264">what’s idiomatic Swift look like</a>? <em>“You’re supposed to put radar numbers above everything.”</em> 😂</p>
Issue #16
https://swiftweeklybrief.com/issue-16
2016-03-31T00:00:00-07:00
2016-03-31T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #16! Last week’s exciting news on the release of Swift 2.2 has been followed up by an <a href="https://swift.org/blog/swift-2-2-new-features/">official blog post</a> detailing the new features. Check it out if you haven’t already.</p>
<p>Also of interest is that Apple started a new beta program for Safari, <a href="https://developer.apple.com/safari/technology-preview/">Safari Technology Preview</a>. This doesn’t have much to do with Swift, but to me it seems like perhaps Swift’s openness is starting to influence more teams within Apple. Maybe? The recent <a href="http://www.apple.com/pr/library/2016/03/21Apple-Advances-Health-Apps-with-CareKit.html">CareKit</a> announcement also supports this theory. Anyway, I’m still hoping for an open source Xcode. 😁</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1112">SR-1112</a>: Wrong suggestion by Fix-it for <code class="language-plaintext highlighter-rouge">if let</code> unused vars</li>
<li><a href="https://bugs.swift.org/browse/SR-1022">SR-1022</a>: Missing “unused result” warning for <code class="language-plaintext highlighter-rouge">#selector</code></li>
<li><a href="https://bugs.swift.org/browse/SR-1005">SR-1005</a>: SwiftPM port to Foundation</li>
<li><a href="https://bugs.swift.org/browse/SR-1111">SR-1111</a>: Non-optimized builds should avoid redundant <code class="language-plaintext highlighter-rouge">thick_to_objc_metatype</code> conversions</li>
<li><a href="https://bugs.swift.org/browse/SR-1115">SR-1115</a>: Adding initializers to <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">UInt</code> to convert from <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code> (SE-0016)</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>There’s a new <a href="https://github.com/apple/swift/pulls?utf8=✓&q=milestone%3A%22Swift+2.2.x%22+">Swift 2.2.x milestone</a> on GitHub with 19 issues closed and 2 issues open (as of this writing). I haven’t seen official announcements about a Swift 2.2.1 (or 2.2.x) release, but it looks like this patch release will be coming soon.</p>
<p><a href="https://github.com/yoonapps">Kyle Yoon</a> completed a corelibs-xctest starter task that <a href="https://github.com/apple/swift-corelibs-xctest/pull/85">added</a> <code class="language-plaintext highlighter-rouge">XCTestCase.expectationForNotification()</code>. This adds a convenient way to setup asynchronous tests for <code class="language-plaintext highlighter-rouge">NSNotification</code> on Linux. 👏</p>
<p>Mike Griepentrog opened a <a href="https://github.com/apple/swift-corelibs-foundation/pull/302">pull request</a> for an initial implementation of <code class="language-plaintext highlighter-rouge">NSURLCredential</code>.</p>
<p>Jordan Rose opened a <a href="https://github.com/apple/swift/pull/1878">pull request</a> for a work-in-progress for <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md">SE-0055</a>: <em>Make unsafe pointer nullability explicit using Optional</em>.</p>
<p>Manav Gabhawala merged a <a href="https://github.com/apple/swift/pull/1812">pull request</a> to clean up parsing of function parameter attributes, among other things. <em>“This pull request cleans up parsing of parameter attributes by parsing the <code class="language-plaintext highlighter-rouge">inout</code>, <code class="language-plaintext highlighter-rouge">let</code> and <code class="language-plaintext highlighter-rouge">var</code> tokens better. It cleans up the implementation to work better with <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0003-remove-var-parameters.md">SE-0003</a> by giving better fix-its and diagnostics for <code class="language-plaintext highlighter-rouge">var</code> as parameter attributes. It implements <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md">SE-0053</a> to disallow <code class="language-plaintext highlighter-rouge">let</code> as an attribute. It provides better fix-its for <code class="language-plaintext highlighter-rouge">inout</code> that are either duplicated or misplaced to better implement <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md">SE-0031</a>.”</em> 😎</p>
<p>Joe Groff opened a <a href="https://github.com/apple/swift/pull/1938">pull request</a> to fix crashes when calling C functions imported as protocol extension methods.</p>
<p>Pushkar Kulkarni <a href="https://github.com/apple/swift-corelibs-foundation/pull/301">fixed</a> a stack corruption issue in <code class="language-plaintext highlighter-rouge">CFRegularExpression</code>. 🤓</p>
<p>Nate Cook merged a <a href="https://github.com/apple/swift/pull/1924">pull request</a> that makes <code class="language-plaintext highlighter-rouge">Array</code>’s conformance to <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code> visible.</p>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/1816">added support</a> for importing Objective-C generics as generic classes in Swift.</p>
<p>Brian Gesiak opened a <a href="https://github.com/apple/swift-corelibs-xctest/pull/84">pull request</a> that adds <code class="language-plaintext highlighter-rouge">XCTestSuite</code> announcements to corelibs-xctest. <em>“This makes the swift-corelibs-xctest and Apple XCTest versions of <code class="language-plaintext highlighter-rouge">XCTestObservation</code> identical, bringing us closer to our Swift 3 goal of API parity.”</em> 🙌</p>
<p><strong>@tinysun212</strong> <a href="https://github.com/apple/swift/pull/1939">made the stdlib random functions portable</a> by removing <code class="language-plaintext highlighter-rouge">arc4random</code> and using C++ <code class="language-plaintext highlighter-rouge"><random></code> instead. This allowed Dmitri Gribenko to <a href="https://github.com/apple/swift/pull/1965">drop the dependency</a> on libbsd.</p>
<p>Chris Bailey <a href="https://github.com/apple/swift-corelibs-foundation/pull/286">implemented</a> a missing <code class="language-plaintext highlighter-rouge">NSString</code> initializer in corelibs-foundation:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">public</span> <span class="kd">convenience</span> <span class="nf">init</span><span class="p">(</span><span class="nv">format</span><span class="p">:</span> <span class="kt">String</span><span class="p">,</span> <span class="nv">locale</span><span class="p">:</span> <span class="kt">AnyObject</span><span class="p">?,</span> <span class="n">arguments</span> <span class="nv">argList</span><span class="p">:</span> <span class="kt">CVaListPointer</span><span class="p">)</span></code></pre></figure>
<p>Jordan Rose <a href="https://github.com/apple/swift/pull/1820">fixed rdar://24547884</a>, addressing an issue in the ClangImporter where inherited protocol conformances were not set up correctly. <em>“This is rdar://problem/24547884, which includes a reference to <a href="https://github.com/facebook/AsyncDisplayKit/issues/1109">facebook/AsyncDisplayKit#1109</a>. (As in, this should fix that issue as well. The test case in the Radar included a stripped-down client but the full AsyncDisplayKit.)”</em></p>
<p>Brian Gesiak opened a <a href="https://github.com/apple/swift/pull/1908">pull request</a> that refactors the Cygwin toolchain to address “a great deal of duplication” across the various toolchains.</p>
<h3 id="proposals">Proposals</h3>
<p>Nicholas Maccharoli’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md">SE-0053</a>: <em>Remove explicit use of <code class="language-plaintext highlighter-rouge">let</code> from Function Parameters</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000078.html">reviewed</a> and <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000082.html">accepted</a> for <strong>Swift 3</strong>. <em>“Everyone agrees that including this redundant syntax is pointless given that the <code class="language-plaintext highlighter-rouge">var</code>/<code class="language-plaintext highlighter-rouge">inout</code> syntax has been removed or moved, it probably should have been included with SE-0003.”</em> As noted above, Manav Gabhawala has a pull request opened to implement this. 👏</p>
<p>Michael Buckley’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md">SE-0016</a>: <em>Add initializers to <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">UInt</code> to convert from <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code></em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000083.html">accepted</a> for <strong>Swift 3</strong>. <em>“This rounds out a missing aspect of our unsafe pointer APIs. Where it was possible to convert <code class="language-plaintext highlighter-rouge">Int</code>/<code class="language-plaintext highlighter-rouge">UInt</code> to unsafe pointer, it wasn’t possible to convert back (without using unsafeBitcast). Adding these converting initializers fixes this…”</em> This worked is being tracked at <a href="https://bugs.swift.org/browse/SR-1115">SR-1115</a>.</p>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0048-generic-typealias.md">SE-0048</a>: <em>Generic Type Aliases</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000077.html">under review</a>. <em>“This proposal aims to add generic typealiases to Swift.”</em> Pretty straightforward! The proposal would allow things like <code class="language-plaintext highlighter-rouge">typealias Vec3<T> = (T, T, T)</code>. On the lists <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013425.html">there</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013340.html">are</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013360.html">a lot</a> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013369.html">of</a> +1’s. 😄</p>
<p>Jordan Rose’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0055-optional-unsafe-pointers.md">SE-0055</a>: <em>Make unsafe pointer nullability explicit using Optional</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000079.html">under review</a>. Overall, the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013408.html">feedback</a> on the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013499.html">mailing lists</a> is <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013427.html">positive</a>.</p>
<blockquote>
<p>In Objective-C, pointers (whether to objects or to a non-object type) can be marked as <code class="language-plaintext highlighter-rouge">nullable</code> or <code class="language-plaintext highlighter-rouge">nonnull</code>, depending on whether the pointer value can ever be null. In Swift, however, there is no such way to make this distinction for pointers to non-object types: an <code class="language-plaintext highlighter-rouge">UnsafePointer<Int></code> might be null, or it might never be. We already have a way to describe this: Optionals. This proposal makes <code class="language-plaintext highlighter-rouge">UnsafePointer<Int></code> represent a non-nullable pointer, and <code class="language-plaintext highlighter-rouge">UnsafePointer<Int>?</code> a nullable pointer.</p>
</blockquote>
<p>Chris Willmore’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054</a>: <em>Abolish <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> type</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000080.html">under review</a>. So far <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013465.html">feedback</a> is <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013523.html">mixed</a> but mostly <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013498.html">positive</a>.</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> (<code class="language-plaintext highlighter-rouge">IUO</code>) type is a valuable tool for importing Objective-C APIs where the nullability of a parameter or return type is unspecified. It also represents a convenient mechanism for working through definite initialization problems in initializers. However, <code class="language-plaintext highlighter-rouge">IUO</code>s are a transitional technology…</p>
<p>This proposal seeks to limit the adoption of <code class="language-plaintext highlighter-rouge">IUO</code>s to places where they are actually required, and put the Swift language on the path to removing implicitly unwrapped optionals from the system entirely when other technologies render them unnecessary.</p>
</blockquote>
<p>Chris Lattner’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0049-noescape-autoclosure-type-attrs.md">SE-0049</a>: <em>Move <code class="language-plaintext highlighter-rouge">@noescape</code> and <code class="language-plaintext highlighter-rouge">@autoclosure</code> to be type attributes</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000081.html">under review</a>. <em>“This proposal suggests moving the existing <code class="language-plaintext highlighter-rouge">@noescape</code> and <code class="language-plaintext highlighter-rouge">@autoclosure</code> attributes from being declaration attributes on a parameter to being type attributes. This improves consistency and reduces redundancy within the language…”</em></p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>The <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012604.html">bikeshedding</a> on proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Level Access</em> that began last week has continued. Ilya Belenkiy has <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013551.html">updated</a> the proposal with the feedback so far. It looks like the current set of keywords is: <code class="language-plaintext highlighter-rouge">public</code>, <code class="language-plaintext highlighter-rouge">moduleprivate</code>, <code class="language-plaintext highlighter-rouge">fileprivate</code>, and <code class="language-plaintext highlighter-rouge">private</code>. Look at that — the names are so clear that I don’t even have to explain them. 😄 However, there are concerns on the list about <code class="language-plaintext highlighter-rouge">moduleprivate</code>. I have to admit, I do like <code class="language-plaintext highlighter-rouge">internal</code> better. Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013854.html">suggests</a> yet another option: <code class="language-plaintext highlighter-rouge">public</code>, <code class="language-plaintext highlighter-rouge">internal</code>, <code class="language-plaintext highlighter-rouge">fileprivate</code>, <code class="language-plaintext highlighter-rouge">private</code>. This sounds perfect to me. 👍</p>
<p>Dave Abrahams posted <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013371.html">an update</a> on the naming guidelines for SetAlgebra for Swift 3. You can find a draft <a href="http://dabrahams.github.io/swift-naming/SetAlgebra-Math.html">here</a>.</p>
<p>Ankit Aggarwal started a <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160328/000372.html">thread</a> with a draft proposal for adding development packages as dependencies in SPM. It looks like <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160328/000373.html">Max Howell</a> supports the idea.</p>
<p>Philippe Hausler <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160321/000534.html">announced</a> that he’s pushed an initial implementation of <code class="language-plaintext highlighter-rouge">NSOperationQueue</code>, <code class="language-plaintext highlighter-rouge">NSOperation</code> and <code class="language-plaintext highlighter-rouge">NSBlockOperation</code>. <em>“It is worth noting that this implementation has a few behavioral differences between this implementation and the one implemented in Objective-C. Part of this difference is due to features like QoS not being cross platform portable or KVO not yet implementable in Swift. This is very much a work-in-progress; it needs unit tests and and a bit more polish, but hopefully it is good enough to get some work started in some other places.”</em> Great to see this progress!</p>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013789.html">pitched</a> an idea on enforcing the argument order for defaulted parameters. The feedback so far is mixed, but leaning slightly in favor of enforcing the argument order.</p>
<blockquote>
<p>Many people are surprised when they find out defaulted parameters can be reordered, unlike required arguments. This special case adds complexity to the language, and runs against our general trend of treating argument labels as a significant part of an API’s name, and preferring a single way of writing API calls. I think it’s worth revisiting this design choice—is the special case worth the complexity? How many people take advantage of default argument reordering?</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — I guess we know <a href="https://twitter.com/NeoNacho/status/713184917899714561">Kanye’s take</a> on implicitly unwrapped optional now. 😂</p>
Issue #15
https://swiftweeklybrief.com/issue-15
2016-03-24T00:00:00-07:00
2016-03-24T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Swift 2.2 has been <a href="https://swift.org/blog/swift-2-2-released/">released</a>! It includes contributions from 212 non-Apple contributors and 7 Swift evolution proposals. Be sure to read Ted Kremenek’s <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000071.html">announcement</a> on the mailing list for more details. The final version of <a href="https://developer.apple.com/library/mac/releasenotes/DeveloperTools/RN-Xcode/Chapters/xc7_release_notes.html#//apple_ref/doc/uid/TP40001051-CH5-DontLinkElementID_29">Xcode 7.3</a> was also released, which includes Swift 2.2 and other <a href="https://twitter.com/Catfish_Man/status/711972673367052288">improvements</a>. Hopefully you were able to upgrade <a href="https://twitter.com/ericasadun/status/712036220818350081">successfully</a>. 😅</p>
<p>Regarding new features, I agree with <a href="https://twitter.com/ayanonagon/status/712076521368739840">Ayaka</a> that having non-stringly-typed Objective-C selectors is so great. And of course, there were a number of interesting announcements at Apple’s <a href="http://www.apple.com/apple-events/march-2016/">special event</a> on Monday. <a href="https://twitter.com/stringcode/status/711963672243994625">This</a> was my favorite new product. 😄</p>
<p>Lastly, in case you <a href="https://twitter.com/swiftlybrief/status/711297027276038144">missed it</a>, there’s now an official mailing list for <em>Swift Weekly Brief</em>! <a href="/subscribe/">Subscribe now</a>. 💌</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1020">SR-1020</a>: Fix-it Delete “var” doesn’t delete space before parameter name</li>
<li><a href="https://bugs.swift.org/browse/SR-873">SR-873</a>: Python Benchmark Driver needs unit tests</li>
<li><a href="https://bugs.swift.org/browse/SR-804">SR-804</a>: Improve SwiftPM Testing Time</li>
</ul>
<p>Suggestions from <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/28">Brian Gesiak</a>:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-1046">SR-1046</a>: Make sure we use the same test runner executable for both the Swift and swift-corelibs-xctest builds.</li>
<li><a href="https://bugs.swift.org/browse/SR-1047">SR-1047</a>: Test the Python used in the swift-corelibs-xctest project as part of the XCTest test suite.</li>
<li><a href="https://bugs.swift.org/browse/SR-1048">SR-1048</a>: Build debug/release versions of swift-corelibs-xctest when building debug/release versions of Swift.</li>
</ul>
<p>This task from last week is still up for grabs:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-875">SR-875</a>: Improve regex support in the swift-corelibs-xctest test suite. This’ll make it easier to write tests for that project.</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>I noticed that <a href="https://github.com/swift-ci"><strong>@swift-ci</strong></a> expanded its repertoire recently. When <a href="https://swift.org/blog/swift-ci/">first announced</a>, the core team could trigger running the full test suite by commenting “<strong>@swift-ci</strong> Please test” on pull requests. Now, commenting “<strong>@swift-ci</strong> Please <a href="https://github.com/apple/swift/pull/1750#issuecomment-199074599">smoke test</a>” will only build the target projects to make sure they build successfully. <strong>@swift-ci</strong> can also merge with “<strong>@swift-ci</strong> Please <a href="https://github.com/apple/swift/pull/1764#issuecomment-200186354">test and merge</a>”. Even more, there’s “<strong>@swift-ci</strong> Please <a href="https://github.com/apple/swift/pull/1682#issuecomment-199569395">perf test</a>” which will run performance tests and then <a href="https://github.com/apple/swift/pull/1682#issuecomment-199628576">leave a comment</a> noting any regressions, improvements, and unchanged results for both <code class="language-plaintext highlighter-rouge">-O</code> and <code class="language-plaintext highlighter-rouge">-Onone</code> optimization levels. 😎 If only we could say, <a href="https://github.com/apple/swift/pull/1740#issuecomment-198777108">please fix</a>… 😂</p>
<p>Shawn Erickson submitted a <a href="https://github.com/apple/swift/pull/1731">pull request</a> to unify mutexes in the Swift runtime, resolving <a href="https://bugs.swift.org/browse/SR-946">SR-946</a>.</p>
<p>Daniel Eggert <a href="https://github.com/apple/swift-corelibs-foundation/pull/299">started work</a> on implementing <code class="language-plaintext highlighter-rouge">NSURLSession</code>. It’s implemented using <code class="language-plaintext highlighter-rouge">libcurl</code> and currently a work-in-progress. 👏</p>
<p>Jesse Rusak opened a <a href="https://github.com/apple/swift/pull/1732">pull request</a> that implements proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md">SE-0037</a>: <em>Clarify interaction between comments & operators</em>. This proposal was accepted as a bug, and resolves <a href="https://bugs.swift.org/browse/SR-186">SR-186</a> and <a href="https://bugs.swift.org/browse/SR-960">SR-960</a>.</p>
<p>Taylor Franklin <a href="https://github.com/apple/swift-corelibs-foundation/pull/288">implemented</a> the remaining <code class="language-plaintext highlighter-rouge">NSDateFormatter</code> attributes and added more tests, resolving <a href="https://bugs.swift.org/browse/SR-208">SR-208</a>.</p>
<p>Ian Partridge submitted a <a href="https://github.com/apple/swift-corelibs-foundation/pull/291">pull request</a> that implements <code class="language-plaintext highlighter-rouge">NSJSONSerialization.dataWithJSONObject(_:options:)</code>.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/commit/ebb8d7392c8f3da07bb299ed0d6a240c0eb07a49">fixed</a> leaking the error value when using <code class="language-plaintext highlighter-rouge">try?</code>, resolving <a href="https://bugs.swift.org/browse/SR-972">SR-972</a>.</p>
<p>David Grove of IBM opened a <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/61">pull request</a> to rework the corelibs-libdispatch overlay for Linux. It resolves <a href="https://bugs.swift.org/browse/SR-739">SR-739</a>, <a href="https://bugs.swift.org/browse/SR-740">SR-740</a>, <a href="https://bugs.swift.org/browse/SR-737">SR-737</a>. <em>“This commit fixes all of these issues by injecting a complete Swift overlay layer that wraps the native libdispatch objects and native APIs.”</em></p>
<p>Yan Li submitted a <a href="https://github.com/apple/swift-corelibs-foundation/pull/297">pull request</a> that implements the basic initializers for <code class="language-plaintext highlighter-rouge">NSAttributedString</code>.</p>
<p>Arnold Schwaighofer opened a <a href="https://github.com/apple/swift/pull/1797">pull request</a> to make <code class="language-plaintext highlighter-rouge">String</code>’s comparison and hash function faster on platforms that use Objective-C inter-op by using a stack allocated <code class="language-plaintext highlighter-rouge">_NSContiguousString</code>. The change provides a 1.2x to 2.2x speedup. 😎</p>
<p>Arsen Gasparyan <a href="https://github.com/apple/swift/pull/1761">merged</a> a patch that replaced <code class="language-plaintext highlighter-rouge">if true { }</code> with <code class="language-plaintext highlighter-rouge">do { }</code> in some test files. Odd. 🤔 My guess is that these tests predated the introduction of <code class="language-plaintext highlighter-rouge">do { }</code>? In any case, consider this your occasional reminder that there are always opportunities for small, easy wins like code cleanup. Get involved!</p>
<p>Another interesting thing I noticed was in Neil Kimmett’s <a href="https://github.com/apple/swift/pull/1323">pull request</a> to add <code class="language-plaintext highlighter-rouge">.zero</code> convenience static vars for <code class="language-plaintext highlighter-rouge">UIEdgeInsets</code> and <code class="language-plaintext highlighter-rouge">UIOffset</code>. This required internal discussion with the UIKit team to <a href="https://github.com/apple/swift/pull/1323#issuecomment-199417826">get approval</a> for the change. 😳</p>
<h3 id="proposals">Proposals</h3>
<p>Andrew Bennett’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.md">SE-0043</a>: <em>Declare variables in <code class="language-plaintext highlighter-rouge">case</code> labels with multiple patterns</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000073.html">accepted</a> <strong>for Swift 3</strong>. <em>“This is a simple and clean extension to the pattern matching model in Swift, positively received by both the community at large and the core team.”</em> Greg Titus has <a href="https://github.com/apple/swift/pull/1383">already implemented</a> the change on master! 👏</p>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md">SE-0042</a>: <em>Flattening the function type of unapplied method references</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000074.html">accepted</a> <strong>for Swift 3</strong>. <em>“The core team and most of the community agree that this proposal would increase the usability of the functional features in Swift, and eliminates a class of problems that occur with <code class="language-plaintext highlighter-rouge">inout</code> parameters.”</em> This work is being tracked at <a href="https://bugs.swift.org/browse/SR-1051">SR-1051</a>.</p>
<p>Adrian Kashivskyy’s and Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md">SE-0047</a>: <em>Defaulting non-Void functions so they warn on unused results</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000075.html">accepted</a> <em>with revision</em> <strong>for Swift 3</strong>. This work is being tracked at <a href="https://bugs.swift.org/browse/SR-1052">SR-1052</a>.</p>
<blockquote>
<p>The core team and much of the community agree that this proposal directly aligns with the spirit of the Swift language, making it so that the compiler will warn about obvious omissions in code that may be bugs. The <code class="language-plaintext highlighter-rouge">@discardableResult</code> attribute provides a good way for API authors to indicate that their functions and methods produce a non-essential result, and should not produce this warning. […]</p>
<p>While this seems like a great direction for the standard library and other pure-Swift code, its impact on imported C and Objective-C APIs is less clear. […] As such, the core team requests that this proposal be revised to indicate that the Clang importer will automatically add the <code class="language-plaintext highlighter-rouge">@discardableResult</code> attribute to all non-Void imported declarations…</p>
</blockquote>
<p>Michael Ilseman’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md">SE-0044</a>: <em>Import as member</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000076.html">accepted</a>, though the version of Swift is not specified. <em>“While there wasn’t a huge amount of feedback, all of the feedback received was positive. During the review period, the proposal was amended to support mapping getter/setter functions to subscripts (via the swift_name attribute) and to support importing instance members into an extension of an Objective-C protocol.”</em> Work for this is happening on the <a href="https://github.com/apple/swift/tree/import-as-member">import-as-member</a> branch.</p>
<p>Michael Buckley’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md">SE-0016</a>: <em>Add initializers to <code class="language-plaintext highlighter-rouge">Int</code> and <code class="language-plaintext highlighter-rouge">UInt</code> to convert from <code class="language-plaintext highlighter-rouge">UnsafePointer</code> and <code class="language-plaintext highlighter-rouge">UnsafeMutablePointer</code></em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000072.html">under review</a>. From the introduction: <em>“Just as users can create <code class="language-plaintext highlighter-rouge">Unsafe[Mutable]Pointers</code> from <code class="language-plaintext highlighter-rouge">Int</code>s and <code class="language-plaintext highlighter-rouge">UInt</code>s, they should be able to create <code class="language-plaintext highlighter-rouge">Int</code>s and <code class="language-plaintext highlighter-rouge">UInt</code>s from <code class="language-plaintext highlighter-rouge">Unsafe[Mutable]Pointers</code>. This will allow users to call C functions with <code class="language-plaintext highlighter-rouge">intptr_t</code> and <code class="language-plaintext highlighter-rouge">uintptr_t</code> parameters, and will allow users to perform more advanced pointer arithmetic than is allowed by UnsafePointers.”</em> It seems like a rather straightforward API change that will improve inter-op with C. There isn’t much feedback on the mailing lists, but so far it’s positive.</p>
<p>Chris Willmore has prepared a proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0054-abolish-iuo.md">SE-0054</a>: <em>Abolish <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> type</em>, after <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012752.html">discussions</a> on the mailing lists. There was mixed feedback during the drafting process and the status of the proposal is now <strong>awaiting review</strong>.</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code> (<code class="language-plaintext highlighter-rouge">IUO</code>) type is a valuable tool for importing Objective-C APIs where the nullability of a parameter or return type is unspecified. It also represents a convenient mechanism for working through definite initialization problems in initializers. However, <code class="language-plaintext highlighter-rouge">IUO</code>s are a transitional technology…</p>
<p>This proposal seeks to limit the adoption of <code class="language-plaintext highlighter-rouge">IUO</code>s to places where they are actually required, and put the Swift language on the path to removing implicitly unwrapped optionals from the system entirely when other technologies render them unnecessary.</p>
</blockquote>
<p>Nicholas Maccharoli has prepared a proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0053-remove-let-from-function-parameters.md#remove-explicit-use-of-let-from-function-parameters">SE-0053</a>: <em>Remove explicit use of <code class="language-plaintext highlighter-rouge">let</code> from Function Parameters</em>, after <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012851.html">discussions</a> on the mailing lists. <em>“Since function parameters are immutable by default, allowing function parameters to be explicitly labeled as <code class="language-plaintext highlighter-rouge">let</code> is a bit of a syntactic redundancy that would best be removed.”</em> Feedback on the lists is positive. I’m surprised Erica Sadun didn’t think of this first. 😉</p>
<p>Patrick Pijnappel not only prepared a proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0052-iterator-post-nil-guarantee.md">SE-0052</a>: <em>Change <code class="language-plaintext highlighter-rouge">IteratorType</code> post-nil guarantee</em>, but already submitted a <a href="https://github.com/apple/swift/pull/1702">pull request</a> for the change. 👏 <em>“Currently, the documentation for <code class="language-plaintext highlighter-rouge">IteratorType.next()</code> has the precondition that when calling <code class="language-plaintext highlighter-rouge">next()</code>, no preceding call to <code class="language-plaintext highlighter-rouge">next()</code> should have returned <code class="language-plaintext highlighter-rouge">nil</code>, and in fact encourages implementations to raise a <code class="language-plaintext highlighter-rouge">preconditionFailure()</code> for violations of this requirement. However, all current 27 <code class="language-plaintext highlighter-rouge">IteratorType</code> implementations in the standard library return <code class="language-plaintext highlighter-rouge">nil</code> indefinitely.”</em> His proposed solution is to bring the guarantee in line with the common expectation, and require iterators to return <code class="language-plaintext highlighter-rouge">nil</code> indefinitely.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Timothy Wood <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/013054.html">started a discussion</a> about updating the signature of the <code class="language-plaintext highlighter-rouge">ObjectiveC.autoreleasepool</code> function to add <code class="language-plaintext highlighter-rouge">rethrows</code> (<a href="https://bugs.swift.org/browse/SR-842">SR-842</a>), and <a href="https://github.com/apple/swift-evolution/pull/221">drafted</a> a proposal. <em>“The <code class="language-plaintext highlighter-rouge">autoreleasepool</code> function in the standard library does not currently support a return value or error handling, making it difficult and error-prone to pass results or errors from the body to the calling context.”</em></p>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012604.html">started a thread</a> to revive discussions on proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Access Level</em>.</p>
<blockquote>
<p>To summarize the place we’d like to end up:</p>
<ul>
<li>“public” -> symbol visible outside the current module.</li>
<li>“internal” -> symbol visible within the current module.</li>
<li>unknown -> symbol visible within the current file.</li>
<li>“private” -> symbol visible within the current declaration (class, extension, etc).</li>
</ul>
<p>The rationale here is that this aligns Swift with common art seen in other languages, and that many people using private today don’t <em>want</em> visibility out of their current declaration. It also encourages “extension oriented programming”, at least it will when some of the other restrictions on extensions are lifted. We discussed dropping the third one entirely, but think it <em>is</em> a useful and important level of access control, and when/if we ever get the ability to write unit tests inside of the file that defines the functionality, they will be a nicer solution to <code class="language-plaintext highlighter-rouge">@testable</code>.</p>
<p>The thing we need to know is what the spelling should be for the third one…</p>
</blockquote>
<p>As you can imagine, an explicit request for bikeshedding has resulted in a tremendous thread. It looks like the consensus so far is for <code class="language-plaintext highlighter-rouge">private</code>, <code class="language-plaintext highlighter-rouge">private(module)</code>, <code class="language-plaintext highlighter-rouge">private(file)</code> — which <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012609.html">James Berry</a> suggested. I think this is great. 👍 Shawn Erickson <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012635.html">pointed out</a> that this puts the current <code class="language-plaintext highlighter-rouge">private(set)</code> in an awkward position, but it’s <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012639.html">always been weird</a> anyway.</p>
<h3 id="finally">Finally</h3>
<p>And finally — from now on, we shall refer to “compiler bugs” as <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160321/013095.html">not-yet-implemented features</a>. 😄 Feel free to assign any tasks to Dave Abrahams. 😉</p>
Issue #14
https://swiftweeklybrief.com/issue-14
2016-03-17T00:00:00-07:00
2016-03-17T00:00:00-07:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #14 of the weekly brief! Just like <a href="https://iosdevweekly.com/issues/241#start">Dave Verwer</a>, I’ve been anticipating the final release of Xcode 7.3 — as well as iOS 9.3, OS X 10.11.4, and watchOS 2.2. Xcode 7.3 will include the final version of Swift 2.2. Perhaps the core team will “<a href="http://www.macrumors.com/2016/03/10/apple-invites-march-21-event/">loop us in</a>” next Monday. 😉</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<p>Suggested by <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/pull/26">Ehsan Jahromi</a>:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-306">SR-306</a> — Add stable sort algorithm</li>
<li><a href="https://bugs.swift.org/browse/SR-587">SR-587</a> — Move <code class="language-plaintext highlighter-rouge">Array(count:repeatedValue:)</code> to <code class="language-plaintext highlighter-rouge">RangeReplaceableCollection</code></li>
</ul>
<p>Suggested by <a href="https://twitter.com/danielboedewadt">Daniel Eggert</a>:</p>
<ul>
<li>Implement <a href="https://github.com/apple/swift-corelibs-foundation/blob/e35f9732ccda2a5f293dbaf70d9a42a8d7aadc86/Foundation/NSURLCredential.swift">NSURLCredential</a></li>
<li>Implement <a href="https://github.com/apple/swift-corelibs-foundation/blob/e35f9732ccda2a5f293dbaf70d9a42a8d7aadc86/Foundation/NSURLCache.swift">NSCachedURLResponse</a></li>
<li>Implement <a href="https://github.com/apple/swift-corelibs-foundation/blob/3579f1f306182e4de48a35dfd9067eff22cee27a/Foundation/NSURLProtectionSpace.swift">NSURLProtectionSpace</a></li>
</ul>
<p>Plus, a couple from Brian Gesiak from <a href="/issue-13/">last issue</a> are still up for grabs:</p>
<ul>
<li><a href="https://bugs.swift.org/browse/SR-906">SR-906</a> — Allow XCTestCase.continueAfterFailure to be set</li>
<li><a href="https://bugs.swift.org/browse/SR-875">SR-875</a> — Make swift-corelibs-xctest Functional tests regex matching more like FileCheck</li>
</ul>
<p class="text-muted">Submit a task by sending a <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> or opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a>.</p>
<h3 id="repositories">Repositories</h3>
<p>Another repository appeared this week, <a href="https://github.com/apple/cups">apple/cups</a>, the <em>Official <a href="http://www.cups.org">CUPS</a> Sources</em>. If you aren’t familiar, CUPS is the standards-based, open source printing system developed by Apple for OS X and other UNIX-like operating systems. This code has been around for <strong>over a decade</strong> (<a href="https://en.wikipedia.org/wiki/CUPS">since 1999</a>), so it’s actually pretty incredible to see it being modernized and moved to GitHub! <em>“By popular request, CUPS is now hosted on Github. All bugs have been migrated to the Github issue tracker and the git repository has been updated to contain the missing release tags and branches since 1.7.0. In the coming weeks we will be moving the CUPS.org web site over to Github hosting as well.”</em> I wonder if we’ll see more of Apple’s open source projects move to GitHub? I sure hope so. 😎</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Daniel Eggert from <a href="https://www.objc.io">objc.io</a> submitted a <a href="https://github.com/apple/swift-corelibs-foundation/pull/287">pull request</a> to implement <code class="language-plaintext highlighter-rouge">NSHTTPURLResponse</code> in corelibs-foundation. 👏</p>
<p>Max Howell <a href="https://github.com/apple/swift-package-manager/pull/171">ported</a> Swift Package Manager to Swift 3.</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/1670">patched</a> <code class="language-plaintext highlighter-rouge">.flatten</code> for collections for the new indexing model.</p>
<p>John Regner submitted a <a href="https://github.com/apple/swift/pull/1686">pull request</a> to move code formatting logic from SourceKit to libIDE as part of <a href="https://bugs.swift.org/browse/SR-146">SR-146</a> which aims to create a <code class="language-plaintext highlighter-rouge">swift-format</code> tool.</p>
<p>John Holdsworth <a href="https://github.com/apple/swift/pull/1641">fixed</a> the majority of Xcode 7.3b5 “Quick Help” crashes in SourceKit. 😎 I’ve never heard of SourceKit crashing. 😉</p>
<p><strong>@practicalswift</strong> <a href="https://github.com/apple/swift/pull/1625">added</a> <a href="https://github.com/apple/swift/pull/1643">a few</a> <a href="https://github.com/apple/swift/pull/1650">more</a> test cases for compiler crashes.</p>
<p>Janek Spaderna <a href="https://github.com/apple/swift/pull/1554">fixed</a> a crash in AST/sema when referencing an enum case in a where-clause. This now produces the correct error message instead of crashing. It looks like this was originally <a href="https://github.com/apple/swift/pull/1554#issuecomment-192969283">discovered</a> by <strong>@practicalswift</strong>.</p>
<h3 id="proposals">Proposals</h3>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md">SE-0039</a>: <em>Modernizing Playground Literals</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000060.html">accepted</a> for <strong>Swift 3</strong>. <em>“The community and core team uniformly agree that this proposal increases uniformity in the swift language.”</em> Chris Lattner filed <a href="https://bugs.swift.org/browse/SR-917">SR-917</a> to track this work. <em>“Implementing this would be a great starter task for someone interested in getting involved in the compiler.”</em> 👍</p>
<p>Jesse Rusak’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0037-clarify-comments-and-operators.md">SE-0037</a>: <em>Clarify interaction between comments and operators</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000066.html">accepted</a>. <em>“There was little community discussion, but the core team and the community participants both agree that this clarifies a corner case in the language.”</em> Work for this is being tracked at <a href="https://bugs.swift.org/browse/SR-960">SR-960</a>.</p>
<p>Jake Carter and Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md">SE-0046</a>: <em>Establish consistent label behavior across all parameters including first labels</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000067.html">accepted</a> for <strong>Swift 3</strong>. <em>“There was uniformly strongly positive reception to this proposal from both the community and core team. This increases the predictability and consistency of the language, and removes a common source of confusion.”</em> 🎉 This work is being tracked in <a href="https://bugs.swift.org/browse/SR-961">SR-961</a>.</p>
<p>Ilya Belenkiy’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Access Level</em>, was sent back for further <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000063.html">revision</a>, but it sounds like the core team is really interested in this idea. While they believe this fits well with Swift’s development methodology, they are concerned about confusion between <code class="language-plaintext highlighter-rouge">local</code> and <code class="language-plaintext highlighter-rouge">private</code>.</p>
<blockquote>
<p>The requested revision involves the proposed keyword, <code class="language-plaintext highlighter-rouge">local</code>. The core team feels that the most appropriate keyword for the proposed functionality is the existing <code class="language-plaintext highlighter-rouge">private</code> keyword. Other languages that have private access specifiers more closely align with the proposed locally-scoped behavior, so such a change would reduce friction for developers moving between the language and more naturally align when what the core team felt the keyword private implies.</p>
<p>Specifically, the core team is requesting a revised version of the proposal that changes the semantics of the existing <code class="language-plaintext highlighter-rouge">private</code> keyword to match those of the proposed <code class="language-plaintext highlighter-rouge">local</code> keyword, and introduce a new name for the existing private semantics that more strongly implies file-private access. Because this is a significant expansion in the scope of the change, the core team feels that we should have a second public review.</p>
</blockquote>
<p>Michael Ilseman’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0044-import-as-member.md">SE-0044</a>: <em>Import as member</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000065.html">under review</a>. <em>“This proposal seeks to provide a mechanism for C API authors to specify the capability of importing functions and variables as members on imported Swift types. It also seeks to provide an automatic inference option for APIs that follow a consistent, disciplined naming convention.”</em></p>
<p>Joe Groff’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0042-flatten-method-types.md">SE-0042</a>: <em>Flattening the function type of unapplied method references</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000068.html">under review</a>. <em>“We should change the type of an unapplied method reference to produce a flattened function value, instead of a curried one. This will make unapplied methods more readily useful with real Swift libraries, and make them supportable for mutating methods.”</em> Currently you can do things like pass the global <code class="language-plaintext highlighter-rouge">+</code> operator to <code class="language-plaintext highlighter-rouge">reduce</code>, for example: <code class="language-plaintext highlighter-rouge">arrayOfInts.reduce(0, combine: +)</code>. However, you cannot do the same with a binary method like <code class="language-plaintext highlighter-rouge">Set.Union</code>, for example: <code class="language-plaintext highlighter-rouge">arrayOfSets.reduce([], combine: Set.union)</code>. This proposal would allow the latter.</p>
<p>Andrew Bennett’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0043-declare-variables-in-case-labels-with-multiple-patterns.md">SE-0043</a>: <em>Declare variables in <code class="language-plaintext highlighter-rouge">case</code> labels with multiple patterns</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000069.html">under review</a>. <em>“In Swift 2, it is possible to match multiple patterns in cases. However cases cannot contain multiple patterns if the case declares variables. This change reduces repetitive code, and therefore reduces mistakes. It’s consistent with multi-pattern matching when variables aren’t defined.”</em></p>
<p>Adrian Kashivskyy and Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0047-nonvoid-warn.md">SE-0047</a>: <em>Defaulting non-Void functions so they warn on unused results</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000070.html">under review</a>. <em>“In Swift’s current incarnation, annotating methods and functions with <code class="language-plaintext highlighter-rouge">@warn_unused_result</code> informs the compiler that a non-void return type should be consumed. It is an affirmative declaration. In its absence, ignored results do not raise warnings or errors. […] Unused results are more likely to indicate programmer error than confusion between mutating and non-mutating function pairs. This proposal makes ‘warn on unused result’ the default behavior for Swift methods and functions.”</em></p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Max Howell <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160314/000335.html">posted</a> that he would like to resurrect the proposal for a protocol for third-party testing frameworks in SPM.</p>
<p>Daniel Eggert <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160314/000484.html">started a discussion</a> about implementing <code class="language-plaintext highlighter-rouge">NSURLSession</code> by wrapping <code class="language-plaintext highlighter-rouge">libcurl</code>. Philippe Hausler <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20160314/000485.html">replied</a> with some interesting notes on corelibs-foundation and porting these APIs to Linux.</p>
<p>The <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012642.html">discussion</a> of David Hart’s <a href="https://github.com/apple/swift-evolution/pull/210">draft proposal</a>, <em>Referencing Objective-C key-paths</em>, continued. This would remove yet another case of <em>stringly-typed</em> code for KVC/KVO. <em>“This proposal seeks to improve the safety and resilience to modification of code using key-paths by introducing a compiler-checked expression.”</em> Community feedback is positive.</p>
<p>Yuta Koshizawa <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012528.html">proposed</a> making <code class="language-plaintext highlighter-rouge">throws</code> syntactic sugar for <code class="language-plaintext highlighter-rouge">Result<T></code>, to <em>“to unify throws and Result into one feature to keep the language simple.”</em> Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012545.html">responded thoughtfully</a> with more details about the core team’s decision on Swift’s <a href="https://github.com/apple/swift/blob/master/docs/ErrorHandling.rst">error handling model</a> and the reasoning behind it.</p>
<blockquote>
<p>We extensively discussed adding a Result type internally, but ultimately couldn’t justify it. The only real use case we could see in the wild was for threading errors through CPS-inversion-style abstractions like async promises, something we hope to provide proper language support for. More generally, expressing effects as monadic values is a pretty awful abstraction; aside from polluting the Internet with an endless deluge of unhelpful tutorials, they also don’t compose cleanly, they impose nesting where is desired — you have to pick between <code class="language-plaintext highlighter-rouge">Result<Async<T>></code> and <code class="language-plaintext highlighter-rouge">Async<Result<T>></code>, or build <code class="language-plaintext highlighter-rouge">ResultT<AsyncT<Identity>><T></code> out of monad transformers — and they don’t do the natural thing when used with other higher-order abstractions — if you’re mapping a <code class="language-plaintext highlighter-rouge">throws</code> function over a collection, you probably want to propagate that error like <code class="language-plaintext highlighter-rouge">rethrows</code> does, not end up with a collection of <code class="language-plaintext highlighter-rouge">Result<T></code>. I’d rather see us adopt an extensible algebraic effects system, something like <a href="http://www.eff-lang.org">http://www.eff-lang.org</a>, which provides a framework for <code class="language-plaintext highlighter-rouge">throws</code>, <code class="language-plaintext highlighter-rouge">async</code> and other control flow effects to be cleanly composed and abstracted over. I see <code class="language-plaintext highlighter-rouge">throws</code> as the first seed of that.</p>
</blockquote>
<p>But there’s always Antitypical’s <a href="https://github.com/antitypical/Result">Result</a> library if you still aren’t satisfied.</p>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012546.html">resumed</a> a previous discussion on compiler directives and Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160314/012557.html">drafted</a> a new proposal for this, <em>Expanding Build Configuration Tests for Simulator and Device targets</em>. <em>“This proposal adds <code class="language-plaintext highlighter-rouge">#if target(simulator)</code> and <code class="language-plaintext highlighter-rouge">#if target(device)</code> to distinguish whether application code is compiled to run in a simulated environment or on a device.”</em></p>
<h3 id="finally">Finally</h3>
<p>And finally — still not sure about protocol-oriented programming? Try side-effect-oriented programming, but be sure to use value types. <a href="https://twitter.com/jckarter/status/707999869831491584">Once it’s copied, it’s not your problem anymore.</a> 😂</p>
Issue #13
https://swiftweeklybrief.com/issue-13
2016-03-10T00:00:00-08:00
2016-03-10T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #13 of the weekly brief! This week Apple released beta 6 of iOS 9.3, watchOS 2.2, and OS X 10.11.4, with no new beta for Xcode 7.3 — the final release should be getting close!</p>
<!--excerpt-->
<h3 id="starter-tasks">Starter tasks</h3>
<p>What’s this new section of the weekly brief?! Last week Brian Gesiak <a href="https://twitter.com/modocache/status/704461870627844096">suggested</a> including a list of introductory tasks to help beginners or new comers get involved. It’s an awesome idea, and should be super helpful for the community. However, finding good tasks can be rather involved and I already have trouble finding free time 😁 — so I’m asking for your help! 😄 If you come across a good starter task, let me know by opening <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">an issue</a> or <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">pull request</a> — or tweet <a href="https://twitter.com/jesse_squires">to me</a> or <a href="https://twitter.com/swiftlybrief">@swiftlybrief</a>. Each week, I’ll list any submitted tasks here.</p>
<p>For this week, Brian has kindly offered a few <a href="https://twitter.com/modocache/status/707819290175651841">suggestions</a>:</p>
<ol>
<li><a href="https://bugs.swift.org/browse/SR-907">SR-907</a>: Add convenience XCTestExpectation constructors</li>
<li><a href="https://bugs.swift.org/browse/SR-906">SR-906</a>: Allow XCTestCase.continueAfterFailure to be set</li>
<li><a href="https://bugs.swift.org/browse/SR-875">SR-875</a>: Make swift-corelibs-xctest Functional tests regex matching more like FileCheck</li>
</ol>
<p>If you are unsure or intimidated about contributing, I know a guy that gave <a href="https://speakerdeck.com/jessesquires/contributing-to-open-source-swift">a talk</a> about this recently that might help motivate you! 😉</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Anna Zaks <a href="https://github.com/apple/swift/pull/1434">added</a> basic address sanitizer (ASan) support. This allows catching and diagnosing memory corruption errors, which are possible
when using unsafe pointers. <em>“This patch introduces a new driver/frontend option <code class="language-plaintext highlighter-rouge">-sanitize=address</code> to enable ASan function instrumentation.”</em> 😎 <a href="https://twitter.com/jckarter/status/704513575801335808">Live dangerously</a>. (I missed this from last week!)</p>
<p>Eugene Gubin <a href="https://github.com/apple/swift-corelibs-foundation/pull/276">submitted a fix</a> to correct the wrong behavior of <code class="language-plaintext highlighter-rouge">NSArray.indexOfObject(_: ...)</code> in corelibs-foundation.</p>
<p>Max Howell <a href="https://github.com/apple/swift-package-manager/pull/174">merged</a> Xcode project generation for Swift package manager. This is the start of <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010679.html">the plans</a> for Xcode integration in SPM. 👏</p>
<p>Dmitri Gribenko <a href="https://github.com/apple/swift/pull/1545">started work</a> on the new collection indexing model for Swift 3.</p>
<p>Ankit Aggarwal <a href="https://github.com/apple/swift-package-manager/pull/168">merged</a> changes to SPM that add <code class="language-plaintext highlighter-rouge">-h</code> and <code class="language-plaintext highlighter-rouge">--help</code> to <code class="language-plaintext highlighter-rouge">swift test</code>, and allow passing arguments to <code class="language-plaintext highlighter-rouge">-XCTest</code> directly. These changes were proposed in <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md">SE-0019</a>, <em>Package Manager Testing</em>.</p>
<p>Shawn Erickson also <a href="https://github.com/apple/swift/pull/1559">contributed</a> to the Swift 3 indexing model work-in-progress, building out the <code class="language-plaintext highlighter-rouge">Collection.next(i: Index) -> Index</code> APIs. 🙇</p>
<p>Brian Croom <a href="https://github.com/apple/swift-corelibs-xctest/pull/64">submitted a pull request</a> to corelibs-xctest that allows selecting a particular test or test case to run from the command line. <a href="https://github.com/apple/swift-corelibs-xctest/pull/64#issuecomment-192963006">Very cool</a>. 😎</p>
<p>Greg Titus <a href="https://github.com/apple/swift/pull/1557">started</a> <a href="https://github.com/apple/swift/pull/1610">work</a> on <code class="language-plaintext highlighter-rouge">typealias</code> versus <code class="language-plaintext highlighter-rouge">associatedtype</code> in protocols for Swift 3. These changes remove the Swift 2.2 use of <code class="language-plaintext highlighter-rouge">typealias</code> and make <code class="language-plaintext highlighter-rouge">associatedtype</code> required for generic constraints in protocols, and allow using <code class="language-plaintext highlighter-rouge">typealias</code> as an actual type alias.</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift-corelibs-xctest/commit/df734dee53bc501da19948cbb8c266a093fa076e">committed</a> adding the asynchronous testing API (<code class="language-plaintext highlighter-rouge">XCTestCase.waitForExpectationsWithTimeout()</code>) to corelibs-xctest. This means asynchronous testing is now available on Linux! 👏</p>
<p>Jason Molenda <a href="https://github.com/apple/swift/pull/1589">merged</a> changes that allow Swift to be build for iphoneos-armv7s (used in Apple A6 and later 32-bit devices).</p>
<p>Ankit Aggarwal opened a <a href="https://github.com/apple/swift-package-manager/pull/183">pull request</a> for a basic implementation of <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md">SE-0038</a>, allow SPM to be used to create and build C libraries! 🎉 For clients, it looks like all you need to do is include your C sources and a <code class="language-plaintext highlighter-rouge">.modulemap</code>. 😎</p>
<p>Maxim Moiseev migrated <a href="https://github.com/apple/swift-corelibs-foundation/pull/281">corelibs-foundation</a> and <a href="https://github.com/apple/swift-corelibs-xctest/pull/60">corelibs-xctest</a> to Swift 3, per the Swift 3 API guidelines changes.</p>
<h3 id="proposals">Proposals</h3>
<p>Erica Sadun continued her rigorous effort in refining Swift, this time with proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0046-first-label.md">SE-0046</a>: <em>Establish consistent label behavior across all parameters including first labels</em>. It was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012209.html">initially suggested</a> by Joe Groff, and Erica <a href="https://twitter.com/jckarter/status/707691862836924416">took it from there</a>.</p>
<blockquote>
<p>“We propose to normalize the first parameter declaration in methods and functions. […] This will create a simple, consistent approach to parameter declaration throughout the Swift programming language and bring method and function declarations in-sync with initializers, which already use this standard.”</p>
</blockquote>
<p>For example, supposed you have <code class="language-plaintext highlighter-rouge">func foo(x: Int, y: Int)</code>. Before this change, calling the function would look like this: <code class="language-plaintext highlighter-rouge">foo(2, y: 3)</code>. After this change, it becomes <code class="language-plaintext highlighter-rouge">foo(x: 2, y: 3)</code>, which is currently how initializers behave. You could opt-out of this new behavior by declaring <code class="language-plaintext highlighter-rouge">func foo(_ x: Int, y: Int)</code> instead. 👏 Support for this is <strong>overwhelmingly</strong> positive and I couldn’t agree more! 🎉 I often find myself writing <code class="language-plaintext highlighter-rouge">func foo(x x: Int, y: Int)</code> and I hate it.</p>
<p>There was exciting news on swift-evolution last Thursday — after issue #12 was already out — the “big 3” proposals were all finally accepted <em>with modifications</em>. 😎 The summaries in the announcement emails provide a great overview, so follow the links below! Erica Sadun also has a <a href="http://ericasadun.com/2016/03/03/swift-evolution-acceptances-the-big-three/">great article</a> on this.</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md">SE-0023</a>: <em>API Design Guidelines</em>, <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000053.html">accepted</a>. The most notable modification here is for <a href="https://swift.org/documentation/api-design-guidelines/#argument-labels">argument labels</a>.</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md">SE-0006</a>: <em>Apply API Guidelines to the Standard Library</em>, <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000054.html">accepted</a>. The work for this is happening on the <a href="https://github.com/apple/swift/tree/swift-3-api-guidelines">swift-3-api-guidelines</a> branch.</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md">SE-0005</a>: <em>Better Translation of Objective-C APIs Into Swift</em>, <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000055.html">accepted</a>. Here’s an example:</li>
</ul>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Objective-C</span>
<span class="o">-</span> <span class="p">(</span><span class="n">void</span><span class="p">)</span><span class="nv">exchangeSubviewAtIndex</span><span class="p">:(</span><span class="kt">NSInteger</span><span class="p">)</span><span class="n">index1</span>
<span class="nv">withSubviewAtIndex</span><span class="p">:(</span><span class="kt">NSInteger</span><span class="p">)</span><span class="n">index2</span><span class="p">;</span>
<span class="c1">// Swift</span>
<span class="kd">func</span> <span class="nf">exchangeSubview</span><span class="p">(</span><span class="n">at</span> <span class="nv">index1</span><span class="p">:</span> <span class="kt">Int</span><span class="p">,</span> <span class="n">withSubviewAt</span> <span class="nv">index2</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span></code></pre></figure>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md">SE-0026</a>: <em>Abstract classes and methods</em> has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000056.html">deferred</a> from Swift 3, but will be revisited in the future. While the core team acknowledges that Swift’s protocols (currently) fall short in providing all features of abstract classes, they simply do not have the bandwidth to participate in the design of such an important feature. After Swift 3 goals are met, if protocol deficiencies/limitations still exist, the team wants to reconsider this proposal. Personally, I would like to see advancements in protocols (stored properties, default implementations, etc.) instead of the introduction of abstract classes.</p>
<p>Jeff Kelley’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md">SE-0033</a>: <em>Import Objective-C Constants as Swift Types</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/011996.html">accepted</a>! This proposal aims to import groups of constants (typically strings) as enums. <em>“There was clear consensus in both the review feedback I received and within the core team that this was a simple, obvious enhancement to the importing logic.”</em></p>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md">SE-0039</a>: <em>Modernizing Playground Literals</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000058.html">under review</a>. This is a rather straight-forward — and very nice — syntax refinement for playground literals. I’m sure it will be accepted. 😄</p>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0040-attributecolons.md">SE-0040</a>: <em>Replacing Equal Signs with Colons For Attribute Arguments</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-March/000059.html">accepted</a> <strong>for Swift 3</strong>! <em>“The community and core team uniformly agree that this proposal increases uniformity in the swift language.”</em> It’s really great to see these refinements! And once again, Daniel Duan has <em>already submitted</em> a <a href="https://github.com/apple/swift/pull/1537">pull request</a> to implement this! 😎</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Russ Bishop <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011032.html">started a thread</a> on bridging and inter-op with Objective-C and <a href="https://github.com/apple/swift-evolution/pull/198">drafted</a> a new proposal, <em>Allow Swift types to provide custom Objective-C representations</em>. He suggests exposing the private protocol <code class="language-plaintext highlighter-rouge">_ObjectiveCBridgeable</code> as a public protocol <code class="language-plaintext highlighter-rouge">ObjectiveCBridgeable</code> to allow you to opt-in to controlling how types bridge from Swift to Objective-C by converting them into and back from an entirely separate <code class="language-plaintext highlighter-rouge">@objc</code> type. <em>“This frees library authors to create truly native Swift APIs while still supporting Objective-C.”</em> Feedback on the mailing lists is <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012168.html">positive</a> so far. From <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/011998.html">Doug Gregor</a>: <em>“I think this is definitely worthy of a proposal”</em>.</p>
<p>Erica Sadun <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011939.html">started</a> an interesting discussion on adopting a new common error type outside the bounds of <code class="language-plaintext highlighter-rouge">NSError</code>. <em>“Swift’s redesigned error mechanism differs significantly from <code class="language-plaintext highlighter-rouge">NSError</code> in that its primary consumer are API calls, via the try-catch mechanism and not end-users. I would not like Swift to be tied down to an archaic construct for the sake of consistency.”</em> <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011944.html">David Owens</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011966.html">Kevin Ballard</a> provided some good feedback.</p>
<p>There’s been an on-going discussion about <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011631.html">removing failable initializers</a> and replacing them with <em>throwable</em> initializers, started by James Campbell. Overall, the community does not support this idea. Early on, Becca Royal-Gordon <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011783.html">pointed out</a> the unnecessary complexity and overhead of this approach. This week, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012107.html">Austin Zheng</a> provided a well-articulated and very practical argument against this, <em>“If the argument is that taking away <code class="language-plaintext highlighter-rouge">init?</code> is going to force Swift users to embrace the One True Path of Error Handling, I don’t think that’s going to happen. The more likely outcome is that people are going to wrap throwable initializers in factory methods returning optionals, and throw away whatever error returns.”</em> I think failable initializers have the potential to be misused/abused/overused, and agree that throwable initializers would not provide any value. You can <em>almost always</em> design your APIs such that you don’t need <code class="language-plaintext highlighter-rouge">init?</code>.</p>
<p>Dmitri Gribenko <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012037.html">posted</a> a request for comment on a new collections model. <em>“What does everyone think about requiring indices to conform to <code class="language-plaintext highlighter-rouge">Hashable</code>, in addition to the existing requirements for <code class="language-plaintext highlighter-rouge">Equatable</code> and <code class="language-plaintext highlighter-rouge">Comparable</code>? I don’t think this should limit any viable collection designs, and yet might be useful, for example, to store indices in a set.”</em> It’s an interesting idea, though Pyry Jahkola <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012054.html">pointed out</a> that clients could simply enforce this on their own.</p>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012099.html">started a thread</a> on universal equatability, hashability, and comparability. He outlines how and why Swift could provide universal behavior for <code class="language-plaintext highlighter-rouge">==</code>, <code class="language-plaintext highlighter-rouge">hashValue</code>, and/or <code class="language-plaintext highlighter-rouge"><</code>. Feedback is mixed with concerns over correctness of default/generated definitions. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012116.html">Austin Zheng</a> argued against this idea, while <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160307/012197.html">William Dillon</a> gave it a +1.</p>
<h3 id="finally">Finally</h3>
<p>And finally — Slava <em>finally</em> <a href="https://twitter.com/slava_pestov/status/707103183441494017">caught something</a> useful in a <a href="https://github.com/apple/swift/commit/aacdf62e8b059788b4994063c7fc2f76b2aa60de">code review</a>. 😂</p>
Issue #12
https://swiftweeklybrief.com/issue-12
2016-03-03T00:00:00-08:00
2016-03-03T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #12 of the weekly brief! More huge news this week as the Core Team is now <a href="https://swift.org/blog/swift-commit-access/">expanding commit access</a> to non-Apple contributors! Congratulations to the following contributors for getting commit access! 🎉 😎 👏</p>
<ul>
<li><a href="https://twitter.com/modocache/status/704344682071916544">Brian Gesiak</a></li>
<li><a href="https://twitter.com/gregtitus/status/704359205688315905">Greg Titus</a></li>
<li><a href="https://github.com/dduan">Daniel Duan</a></li>
<li><a href="https://github.com/kballard">Kevin Ballard</a></li>
<li><a href="https://twitter.com/KostiaKoval/status/705316504250806272">Kostiantyn Koval</a></li>
</ul>
<p>If I missed anyone, please <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/compare">submit a pull request</a> to update the list! 😄 This week also brought us <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_7.3_beta_5/Xcode_7.3_beta_5_Release_Notes.pdf">Xcode 7.3 beta 5</a>. We should be getting close to the final release.</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>The other big news from the past week was Brian Gesiak’s <a href="https://github.com/apple/swift/pull/1442">port to Android</a> pull request. <a href="https://github.com/apple/swift/pull/1442#issuecomment-188997429">This is really awesome to see.</a> 🙇 <span class="text-muted"><strong>Note:</strong> +1’s are very much appreciated, but can be burdensome for contributors. If you’d like to comment, please <a href="https://twitter.com/modocache">send a tweet</a> to Brian instead.</span> 😄</p>
<p>A new repository, <a href="https://github.com/apple/swift-compiler-rt">swift-compiler-rt</a>, appeared this week. <em>“This directory and its subdirectories contain source code for the compiler support routines.”</em></p>
<p>Harlan Haskins has <a href="https://github.com/apple/swift/pull/1417">opened a pull request</a> that adds a code coverage comparison visualization tool. 🤓</p>
<p>C.W. Betts submitted a <a href="https://github.com/apple/swift-corelibs-foundation/pull/251">pull request</a> to implement <code class="language-plaintext highlighter-rouge">NSUserDefaults</code> in corelibs-foundation.</p>
<p>Patrick Pijnappel <a href="https://github.com/apple/swift/pull/1477">rewrote</a> <code class="language-plaintext highlighter-rouge">UTF8._isValidUTF8()</code> to improve performance and reduce code size. Depending on the sequence, there’s a 15-45% speed-up. <a href="https://github.com/apple/swift/pull/1477#issuecomment-189788033">This is brilliant</a>! 😎</p>
<p>Nadav Rotem <a href="https://github.com/apple/swift/commit/493f4e3747ce2f7faf238b809a17018593dc1bb9">disabled the in-lining</a> of <code class="language-plaintext highlighter-rouge">measureExtendedGraphemeCluster</code>. <em>“This change reduced the size of the Swift standard library by about 45k (2% of the .text size).”</em></p>
<p>Guillaume Lessard submitted a <a href="https://github.com/apple/swift/pull/1454">pull request</a> to fix <a href="https://bugs.swift.org/browse/SR-192">SR-192</a>, <em>“Weak properties are not thread safe when reading”</em>, reported by <a href="https://twitter.com/mikeash">Mike Ash</a>.</p>
<p>Honza Dvorsky opened a <a href="https://github.com/apple/swift-package-manager/pull/159">pull request</a> (previous discussion <a href="https://github.com/apple/swift-package-manager/pull/156">here</a>) to generate <code class="language-plaintext highlighter-rouge">XCTestCaseProvider</code> entries on Linux (<a href="https://bugs.swift.org/browse/SR-710">SR-710</a>).</p>
<p>Ankit Aggarwal submitted a <a href="https://github.com/apple/swift-package-manager/pull/149">pull request</a> to add support for empty source packages (<a href="https://bugs.swift.org/browse/SR-793">SR-793</a>).</p>
<p>Daniel Duan opened a <a href="https://github.com/apple/swift/pull/1501">pull request</a> to implement proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md">SE-0034</a>, which replaces the line directive <code class="language-plaintext highlighter-rouge">#line</code> with <code class="language-plaintext highlighter-rouge">#setline</code>.</p>
<p><strong>@tinysun212</strong> has <a href="https://github.com/apple/swift/pull/1516">started work</a> on a port to Windows (<a href="https://bugs.swift.org/browse/SR-34">SR-34</a>) and integration with Visual Studio.</p>
<h3 id="proposals">Proposals</h3>
<p>Erica Sadun’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md">SE-0034</a>: <em>Disambiguating Line Control Statements from Debugging Identifiers</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000050.html">accepted</a>. <em>“The community and core team both widely agree that this is a straight-forward fix to an uncommonly used feature.”</em></p>
<p>Daniel Dunbar’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md">SE-0038</a>: <em>Package Manager C Language Target Support</em>, has been <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160222/000288.html">accepted</a>! I’m really excited about this. I think having C language support in SPM will have a huge impact on the community. <em>“We didn’t get a lot of commentary on this proposal, but there appears to be general support for this proposal. […] While we now have a specification for how this feature should work, we do not yet have a schedule for when we will be able to implement it. If you are interested in contributing an implementation for this proposal, please coordinate with us on the swift-build-dev mailing list.”</em></p>
<p>David Scrève’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0026-abstract-classes-and-methods.md">SE-0026</a>: <em>Abstract classes and methods</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000048.html">under review</a>. I’m personally not a fan of this idea. I think that the problems that abstract classes and methods attempt to solve can be better solved with protocols, and design patterns that avoid the need for inheritance in the first place. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011163.html">David Owens II</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011168.html">Austin Zheng</a> offer their views against and in favor, respectively. Overall feedback on the mailing lists is mixed.</p>
<p>Ilya Belenkiy’s proposal, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">SE-0025</a>: <em>Scoped Access Level</em>, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000049.html">under review</a>. It aims to introduce a new access level modifier, <code class="language-plaintext highlighter-rouge">local</code>, which would make the specified members private to their class/struct. Support for this is mixed and I can understand both sides. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011201.html">Stephen Celis</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011405.html">Becca Royal-Gordon</a> have written great responses against this. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011210.html">Nate Cook</a> provided his thoughts on why he thinks this is a good change. And <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/011314.html">Joe Groff</a> suggested that this might be solvable with stored properties in extensions instead.</p>
<p>Erica Sadun drafted two proposals for refinements to Strides. So far there is mixed but mostly positive support for each of these.</p>
<ul>
<li>Conventionalizing <code class="language-plaintext highlighter-rouge">stride</code> semantics (<a href="https://github.com/apple/swift-evolution/pull/184">here</a>). <em>“Swift offers two stride functions, <code class="language-plaintext highlighter-rouge">stride(to:, by:)</code> and <code class="language-plaintext highlighter-rouge">stride(through:, by:)</code>. This proposal introduces a third style and renames the existing to and through styles.”</em></li>
<li>Decoupling Floating Point Strides from Generic Implementations (<a href="https://github.com/apple/swift-evolution/pull/185">here</a>). <em>“<code class="language-plaintext highlighter-rouge">Strideable</code> is genericized across both integer and floating point types. A single implementation causes floating point strides to accumulate errors through repeatedly adding <code class="language-plaintext highlighter-rouge">by</code> intervals. Floating point types deserve their own floating point-aware implementation that minimizes errors.”</em></li>
</ul>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Dmitri Gribenko <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011552.html">posted</a> a request for comment on proposed changes to collection indices.</p>
<blockquote>
<p>We would like to propose a major change to how collection indices
work. The standard library team has discussed this idea internally
and we wrote a prototype. Now we think it is a viable direction to
consider, and we are bringing it for wider public discussion.</p>
<p>We are proposing a new model for collections, where indices can only be
advanced forward or backward by the corresponding collection instance.
Indices become opaque tokens representing collection positions, that can
be produced and consumed by collection APIs. This allows us to reduce
the amount of data stored in indices to the bare minimum.</p>
<p>Compared to the current state, the new scheme simplifies implementation
of non-trivial indices, and fixes concurrency issues in <code class="language-plaintext highlighter-rouge">Set</code> and
<code class="language-plaintext highlighter-rouge">Dictionary</code> indices. It also allows us to eliminate reference-counted
stored properties from most indices, including non-trivial ones, like
<code class="language-plaintext highlighter-rouge">Set.Index</code> and <code class="language-plaintext highlighter-rouge">Dictionary.Index</code>, creating more optimizable code.</p>
</blockquote>
<p>Chris Lattner made a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160229/011493.html">brief pitch</a> on simplifying class initialization complexity, asking if anyone from the community could drive this project as the core team does not have time.</p>
<blockquote>
<p>If anyone is interested in picking up this as a project to scope, design, and drive, that would be great. :-)</p>
<p>Class initialization in Swift support a wide array of knobs and concepts, including things like designated initializers, required initializers, convenience initializers, etc. These are all required by various common patterns in Cocoa and other OO systems, but has an unfortunate side effect: all of the complexity is foisted on you at once.</p>
<p>Wouldn’t it be great if you could freely define a new class and not have to know about required and convenience initializers? It seems that we should only have to enforce these requirements if you a) further derive from this class within your module, or b) mark the class publicly-derivable-from.</p>
</blockquote>
<p>Erica Sadun has <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160222/000289.html">started a discussion</a> on disambiguating Swift Package Manager naming conflicts (draft proposal <a href="https://github.com/apple/swift-evolution/pull/182/">here</a>). She suggests using reverse domain names to fully quality packages, for example <code class="language-plaintext highlighter-rouge">import org.sadun.SwiftString</code>. Max Howell’s <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160222/000290.html">initial response</a> was positive. 😎</p>
<h3 id="finally">Finally</h3>
<p>And finally — if you didn’t know, the <a href="http://www.tryswiftconf.com/en">try! Swift conference</a> is happening this week in Tokyo. Huge thanks to <a href="https://twitter.com/NatashaTheRobot">@NatashaTheRobot</a> and the organizers for putting together such a great event. 🙌 Lots of familiar faces from the community are here, and it has been awesome. You can follow the fun on Twitter at <a href="https://twitter.com/search?q=%23tryswiftconf">#tryswiftconf</a>. I even got to <a href="https://twitter.com/jesse_squires/status/705034656987484160">meet Ash Furrow</a>. 😂</p>
Issue #11
https://swiftweeklybrief.com/issue-11
2016-02-25T00:00:00-08:00
2016-02-25T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #11 of the weekly brief! There was big news this week with IBM’s announcement on <a href="http://www.ibm.com/cloud-computing/bluemix/swift/">bringing Swift to the cloud</a> with a new open web framework called <a href="https://github.com/ibm-swift/kitura">Kitura</a> and the <a href="https://swiftpkgs.ng.bluemix.net">IBM Swift Package Catalog</a>. The test framework for Kitura server is <a href="https://twitter.com/modocache/status/701807962302586880">even using corelibs-xctest</a>. 😎 Apple’s <a href="http://www.apple.com/business/mobile-enterprise-apps/">partnership</a> with IBM is definitely starting to benefit the community! 🎉</p>
<!--excerpt-->
<h3 id="xcode">Xcode</h3>
<p>Apple released <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_7.3_beta_4/Xcode_7.3_beta_4_Release_Notes.pdf">Xcode 7.3 beta 4</a> this week with <em>significant</em> changes! The following proposals are included in the release:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md">SE-0020</a>: <em>Swift Language Version Build Configuration</em>, by David Farler</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>: <em>Referencing the Objective-C selector of a method</em>, by Doug Gregor</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md">SE-0011</a>: <em>Replace <code class="language-plaintext highlighter-rouge">typealias</code> keyword with <code class="language-plaintext highlighter-rouge">associatedtype</code> for associated type declarations</em>, by Loïc Lecrenier</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md">SE-0021</a>: <em>Naming Functions with Argument Labels</em>, by Doug Gregor</li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md">SE-0028</a>: <em>Modernizing Swift’s Debugging Identifiers</em>, by Erica Sadun</li>
</ul>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/1297">merged</a> his property behaviors prototype into <code class="language-plaintext highlighter-rouge">master</code>. (Note that the pull request was closed.) It is currently hidden behind a frontend flag, <code class="language-plaintext highlighter-rouge">-enable-experimental-property-behaviors</code>. Joe also <a href="https://github.com/apple/swift/pull/1385">worked on</a> handling initial value requirements in property behaviors. <em>“This lets us implement <code class="language-plaintext highlighter-rouge">lazy</code> as a property behavior.”</em> 🎉</p>
<p>Joshua Garnham <a href="https://github.com/apple/swift/pull/1197">fixed a bug</a> in the parser where a fix-it would suggest moving an <code class="language-plaintext highlighter-rouge">@noescape</code> attribute declaration to the function attribute position, rather than the parameter. (<a href="https://bugs.swift.org/browse/SR-215">SR-215</a>)</p>
<p>Greg Titus opened a <a href="https://github.com/apple/swift/pull/1383">pull request</a> to support multiple patterns in <code class="language-plaintext highlighter-rouge">switch</code> cases that contain variables. <em>“There was a thread on swift-evolution back on Jan 23rd about adding this, and the response from the team was that it was something desirable but that you just hadn’t had time to do it so far.”</em> 😎 This change will enable things like this:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">enum</span> <span class="kt">Foo</span> <span class="p">{</span>
<span class="k">case</span> <span class="kt">A</span><span class="p">(</span><span class="kt">String</span><span class="p">,</span> <span class="kt">Int</span><span class="p">)</span>
<span class="k">case</span> <span class="kt">B</span><span class="p">(</span><span class="kt">Int</span><span class="p">,</span> <span class="kt">String</span><span class="p">,</span> <span class="kt">String</span><span class="p">)</span>
<span class="k">case</span> <span class="kt">C</span><span class="p">(</span><span class="kt">Int</span><span class="p">)</span>
<span class="p">}</span>
<span class="kd">func</span> <span class="nf">thingy</span><span class="p">(</span><span class="nv">arg</span><span class="p">:</span> <span class="kt">Foo</span><span class="p">)</span> <span class="o">-></span> <span class="kt">String</span> <span class="p">{</span>
<span class="k">var</span> <span class="nv">r</span><span class="p">:</span> <span class="kt">String</span>
<span class="k">switch</span><span class="p">(</span><span class="n">arg</span><span class="p">)</span> <span class="p">{</span>
<span class="k">case</span> <span class="o">.</span><span class="kt">A</span><span class="p">(</span><span class="k">let</span> <span class="nv">s</span><span class="p">,</span> <span class="k">let</span> <span class="nv">i</span><span class="p">),</span> <span class="o">.</span><span class="kt">B</span><span class="p">(</span><span class="k">let</span> <span class="nv">i</span><span class="p">,</span> <span class="n">_</span><span class="p">,</span> <span class="k">let</span> <span class="nv">s</span><span class="p">):</span>
<span class="n">r</span> <span class="o">=</span> <span class="s">"</span><span class="se">\(</span><span class="n">s</span><span class="se">)\(</span><span class="n">i</span><span class="se">)</span><span class="s">"</span>
<span class="k">case</span> <span class="o">.</span><span class="kt">C</span><span class="p">:</span>
<span class="n">r</span> <span class="o">=</span> <span class="s">"c"</span>
<span class="p">}</span>
<span class="k">return</span> <span class="n">r</span>
<span class="p">}</span></code></pre></figure>
<p>Brian Gesiak <a href="https://github.com/apple/swift-llbuild/pull/8">documented</a> the <code class="language-plaintext highlighter-rouge">swift-compiler</code> tool in swift-llbuild. 🙇</p>
<p>Mishal Shah <a href="https://github.com/apple/swift/pull/1360">added</a> a pull request template to support GitHub’s <a href="https://github.com/blog/2111-issue-and-pull-request-templates">new feature</a>.</p>
<p>Eric Holscher setup <a href="http://apple-swift.readthedocs.org/en/latest/index.html">Swift 2.2 documentation</a> on <a href="https://readthedocs.org">ReadTheDocs.org</a>, and <a href="https://github.com/apple/swift/pull/44">added a link</a> in the <code class="language-plaintext highlighter-rouge">README</code>. Now you don’t have to build it yourself. 👏 I feel like this was the purpose of the <a href="http://apple.github.io/swift-internals/">Swift Internals</a> site, yet it still has not been updated to include these. 🤔</p>
<p><strong>@codestergit</strong> <a href="https://github.com/apple/swift-corelibs-foundation/pull/88">implemented</a> <code class="language-plaintext highlighter-rouge">NSCountedSet</code> in corelibs-foundation.</p>
<p>The previously mentioned <a href="https://github.com/apple/swift/pull/1108">port to cygwin</a> has now been merged!</p>
<h3 id="proposals">Proposals</h3>
<p>A number of proposals have been <strong>rejected</strong> this week. Personally, I think the rationales for each rejection are very reasonable and practical. I think it’s important to note a few things here. Rejections are not <em>negative</em>. Each time we finish a swift-evolution review — regardless of the outcome — it means we are that much closer to shaping and refining <strong>our</strong> language. Thus, if <em>your</em> proposal gets rejected, you should not feel discouraged — nor should you stop participating! Finally, don’t shoot <a href="https://twitter.com/dgregor79/status/702014672065531904">the messenger</a>! 😄</p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md">SE-0024</a>, <em>Optional Value Setter <code class="language-plaintext highlighter-rouge">??=</code></em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000043.html">rejected</a>. In short, <em>“…the use cases are not strong enough to motivate inclusion of this operator.”</em></p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0027-string-from-code-units.md">SE-0027</a>, <em>Expose code unit initializers on String</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000044.html">rejected</a>. <em>“The core team feels that we have not fully explored the design space here. […] The String type itself is undergoing a significant re-evaluation, so the core team feels that improvements to String should be delayed until the newer design is better understood.”</em></p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0010-add-staticstring-unicodescalarview.md">SE-0010</a>, <em>Add StaticString.UnicodeScalarView</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000045.html">rejected</a>. <em>“The core team felt that it would be inconsistent just to add this narrow set of APIs for Unicode scalars. […] If <code class="language-plaintext highlighter-rouge">StaticString</code> is to gain Unicode support, it should be done comprehensively, not piecemeal. Moreover, with the aforementioned String re-evaluation underway, it is possible that <code class="language-plaintext highlighter-rouge">StaticString</code> itself might change considerably or even be obsoleted.”</em></p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">SE-0030</a>, <em>Property Behaviors</em>, was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000047.html">rejected</a> in its current form and now has a status of <strong>under revision</strong>. <em>“The core team believes that property behaviors are a worthwhile feature for Swift, but it’s clear from the discussion that we as a community have not yet converged on a design we are willing to commit to. It is therefore too early to accept a proposal for this feature.”</em> While it may be disappointing that this proposal is not quite ready, it is great to know that the core team is really listening to and collaborating with the community. 😊</p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.md">SE-0035</a>, <em>Limiting <code class="language-plaintext highlighter-rouge">inout</code> capture to <code class="language-plaintext highlighter-rouge">@noescape</code> contexts</em> by Joe Groff, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000046.html">accepted</a>! <em>“This proposal has been very positively accepted by the community at large as well as the core team, and folks widely agree that it eliminates a common source of surprise, making Swift more predictable.”</em> Work for this is being tracked at <a href="https://bugs.swift.org/browse/SR-807">SR-807</a>.</p>
<p>Proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0033-import-objc-constants.md">SE-0033</a>, <em>Import Objective-C Constants as Swift Types</em> by Jeff Kelley, is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000042.html">under review</a>. Overall, support for this on the <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/006904.html">mailing lists</a> was positive.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>The mailing lists <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/010842.html">went down</a> for a couple of hours on Monday (Feb. 22). Be sure to resend any messages that might have gotten lost.</p>
<p>Max Howell started threads (<a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000272.html">swift-build-dev</a>, <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010679.html">swift-evolution</a>) to announce plans for Xcode integration with the Swift Package Manager. 🎉 This work is going to happen on GitHub, and begin presently.</p>
<blockquote>
<p>One of our goals for the Swift Package Manager is excellent and delightful integration with Xcode.
To this end we are going to start work on initial integration by making SwiftPM able to generate Xcode project files. This is not the long-term design we want for the Xcode integration, but it is a concrete step we can take now which will allow Xcode users to adopt Swift packages and use them in their products. […] We would like to emphasize again that proper and tight integration with Xcode is our long-term goal, but in the near-term we consider this a good intermediary solution — making real Swift package use possible.</p>
<p>Our design for this feature is as follows:</p>
<ul>
<li>Generate a single xcodeproj from the command line for a Package.swift</li>
<li>The xcodeproj will contain targets for all packages and their modules</li>
<li>Require the user to add this xcodeproj to their main project and link the dependency by hand.</li>
</ul>
<p>[…] We are aware of the frustrating aspects of other systems that generate Xcode projects and will be looking at ways to mitigate the problems that come with this solution.</p>
</blockquote>
<p>Kevin Ballard <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010693.html">shared an idea</a> for adding <code class="language-plaintext highlighter-rouge">#if os(Darwin)</code> as shorthand for any Apple platform. There’s mostly support for this, but more importantly it has raised other considerations, such as how to handle different Linux distros. At the very least, it has been acknowledged that current state of <code class="language-plaintext highlighter-rouge">#if os(...)</code> is lacking.</p>
<p>Joe Groff <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160222/010843.html">pitched an idea</a> on <em>flattening the function type of unapplied instance methods</em>. It’s a bit dense and difficult to summarize, so I’ll just refer you to his initial message. 😁</p>
<h3 id="finally">Finally</h3>
<p>And finally — <a href="https://twitter.com/jckarter/status/702185887296163840">the headline writes itself</a>. <em>“Three Decades Later, Apple Flipping a New Bird at IBM”</em>. 😂</p>
Issue #10
https://swiftweeklybrief.com/issue-10
2016-02-18T00:00:00-08:00
2016-02-18T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to issue #10 of the weekly brief! This week Eddy Cue and Craig Federighi appeared on <a href="http://daringfireball.net/thetalkshow/2016/02/12/ep-146">The Talk Show</a> with John Gruber. There wasn’t much talk about Swift, but they did discuss plenty of interesting things. I highly recommend listening, especially if you are an iOS developer! 📱</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Joe Groff <a href="https://github.com/apple/swift/pull/1297">began work</a> on the initial parsing and synthesis for properties with behaviors for proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">SE-0030</a>. 👏</p>
<p>Janek Spaderna <a href="https://github.com/apple/swift/pull/1302">fixed a bug</a> in the AST that prevented you from accessing associated types through class-constrained generic parameters. <a href="https://bugs.swift.org/browse/SR-726">SR-726</a> has more details.</p>
<p>William Dillon submitted a <a href="https://github.com/apple/swift-clang/pull/8">pull request</a> that enables <code class="language-plaintext highlighter-rouge">CF_ENUM</code> and <code class="language-plaintext highlighter-rouge">CF_OPTIONS</code> on non-Darwin targets.</p>
<p>Max Howell <a href="https://github.com/apple/swift-package-manager/commit/a25ba1c21a449cae4b683a4d463fc021c2f97576">merged</a> the SPM <code class="language-plaintext highlighter-rouge">testing</code> branch into <code class="language-plaintext highlighter-rouge">master</code>, completing proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md">SE-0019</a>. 🙌</p>
<p>Brian Gesiak submitted a <a href="https://github.com/apple/swift/pull/1316">pull request</a> to allow corelibs-xctest to be built and tested on Linux and OS X. Finally testing the tests! 😄</p>
<p>Manav Gabhawala <a href="https://github.com/apple/swift-corelibs-foundation/pull/137">implemented</a> the <code class="language-plaintext highlighter-rouge">dataWithJSONObject(_: options:)</code> API in corelibs-foundation.</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/1327">improved</a> the stdLib documentation for Swift 2.2. 🎉 This should be no surprise coming from the creator of <a href="http://swiftdoc.org">swiftdoc.org</a>.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/1330">fixed rdar://24575507</a>. This bug prevented a type from satisfying a protocol with initializers if an <code class="language-plaintext highlighter-rouge">init()</code> was defined in a protocol extension instead of a concrete class or struct.</p>
<p>Two weeks ago, I linked to William Dillon’s <a href="https://github.com/apple/swift/pull/1157">pull request</a> for gold linker. After <a href="https://github.com/apple/swift/pull/1157#issuecomment-185801246">a lot of discussion</a>, this week it was finally merged!</p>
<h3 id="proposals">Proposals</h3>
<p>The review of Joe Groff’s proposal on property behaviors (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">SE-0030</a>) has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000038.html">extended for another week</a>.</p>
<p>Daniel Dunbar’s proposal, <em>Package Manager C Language Target Support</em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0038-swiftpm-c-language-targets.md">SE-0038</a>), is now under <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160215/000261.html">review</a>. There isn’t much feedback yet, but this would be a great addition!</p>
<p>Zachary Waldowski’s proposal, <em>Expose code unit initializers on String</em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0027-string-from-code-units.md">SE-0027</a>), is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000036.html">review</a>. The proposal suggests exposing private <code class="language-plaintext highlighter-rouge">String</code> APIs as public to improve working with byte representations and unicode.</p>
<p>James Campbell’s proposal, <em>Optional Value Setter <code class="language-plaintext highlighter-rouge">??=</code></em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0024-optional-value-setter.md">SE-0024</a>), is also under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000037.html">review</a>. He suggests adding a new operator, <code class="language-plaintext highlighter-rouge">??=</code>. <em>“If the optional is set via this operator then the new value is only set if there isn’t an already existing value.”</em> Support for this was mixed. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002633.html">Greg Titus</a> didn’t see the value in an extra operator. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002630.html">Ash Furrow</a> noted that he enjoyed having this operator in Ruby. I could go either way here.</p>
<p>Erica Sadun has been on a roll with proposals. 🙇 She contributed a number of small proposals for some really great syntax refinements. Each of these really help bring an overall consistency to Swift.</p>
<ul>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0031-adjusting-inout-declarations.md">SE-0031</a> <em>Adjusting <code class="language-plaintext highlighter-rouge">inout</code> Declarations for Type Decoration</em>, co-authored by Joe Groff. This has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000041.html">accepted</a> for Swift 3. Furthermore, Daniel Duan has already submitted a <a href="https://github.com/apple/swift/pull/1333">pull request</a> to implement this! 👏 The main reasons for accepting this include: <em>“(1) The community and core team both widely agree that it makes sense to move the inout keyword into the type position. (2) This reinforces commonality between the declaration and type syntax. (3) This reduces complexity in the Swift 3 language.”</em></p>
</li>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0036-enum-dot.md">SE-0036</a> <em>Requiring Leading Dot Prefixes for Enum Instance Member Implementations</em>, co-authored by Chris Lattner. Currently, within an <code class="language-plaintext highlighter-rouge">enum</code> type you can refer to each case with or without the dot prefix (<code class="language-plaintext highlighter-rouge">.</code>). For example, <code class="language-plaintext highlighter-rouge">.first</code> versus <code class="language-plaintext highlighter-rouge">first</code>. This proposal aims to <em>always</em> require the <code class="language-plaintext highlighter-rouge">.</code> for a consistent experience.</p>
</li>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0034-disambiguating-line.md">SE-0034</a>, <em>Disambiguating Line Control Statements from Debugging Identifiers</em>. This is now under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000040.html">review</a>. From the introduction: <em>“The proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md">SE-0028</a> overloads the use of <code class="language-plaintext highlighter-rouge">#line</code> to mean both an identifier that maps to a calling site’s line number within a file and acts as part of a line control statement. This proposal nominates <code class="language-plaintext highlighter-rouge">#setline</code> to replace <code class="language-plaintext highlighter-rouge">#line</code> for file and line syntactic source control”</em>.</p>
</li>
<li>
<p><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0039-playgroundliterals.md">SE-0039</a> <em>Modernizing Playground Literals</em>. This proposes the following syntax change to playground literals:</p>
</li>
</ul>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Current</span>
<span class="p">[</span><span class="err">#</span><span class="kt">Color</span><span class="p">(</span><span class="nv">colorLiteralRed</span><span class="p">:</span> <span class="n">r</span><span class="p">,</span> <span class="nv">green</span><span class="p">:</span> <span class="n">g</span><span class="p">,</span> <span class="nv">blue</span><span class="p">:</span> <span class="n">b</span><span class="p">,</span> <span class="nv">alpha</span><span class="p">:</span> <span class="n">a</span><span class="p">)</span><span class="err">#</span><span class="p">]</span>
<span class="c1">// Proposed</span>
<span class="cp">#colorliteral(red: r, green: g, blue: b, alpha: a)</span></code></pre></figure>
<ul>
<li>The <a href="https://github.com/apple/swift-evolution/pull/159">final proposal</a> is <em>Replacing Equal Signs with Colons For Attribute Arguments</em>. The current syntax is definitely awkward in the larger picture of Swift. It’s easiest to illustrate this with an example:</li>
</ul>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Current</span>
<span class="kd">@available</span><span class="p">(</span><span class="o">*</span><span class="p">,</span> <span class="n">unavailable</span><span class="p">,</span> <span class="n">renamed</span><span class="o">=</span><span class="s">"MyRenamedProtocol"</span><span class="p">)</span>
<span class="c1">// Proposed, using : instead of =</span>
<span class="kd">@available</span><span class="p">(</span><span class="o">*</span><span class="p">,</span> <span class="n">unavailable</span><span class="p">,</span> <span class="nv">renamed</span><span class="p">:</span> <span class="s">"MyRenamedProtocol"</span><span class="p">)</span></code></pre></figure>
<p>Joe Groff’s proposal, <em>Limiting <code class="language-plaintext highlighter-rouge">inout</code> capture to <code class="language-plaintext highlighter-rouge">@noescape</code> contexts</em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0035-limit-inout-capture.md">SE-0035</a>), is under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000039.html">review</a>. From the introduction: <em>“Swift’s behavior when closures capture <code class="language-plaintext highlighter-rouge">inout</code> parameters and escape their enclosing context is a common source of confusion. We should disallow implicit capture of <code class="language-plaintext highlighter-rouge">inout</code> parameters except in <code class="language-plaintext highlighter-rouge">@noescape</code> closures.”</em> This undesired behavior predates the addition of <code class="language-plaintext highlighter-rouge">@noescape</code>. Dave Abrahams (the original author of the current semantics), Chris Lattner, and Jordan Rose all gave this a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008105.html">+1</a>.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Chris Eidhof <a href="https://twitter.com/chriseidhof/status/700305519328755712">noted</a> some subtleties when using the new <code class="language-plaintext highlighter-rouge">associatedtype</code> in Swift 2.2. Good to know! (Not on the mailing lists, but Twitter is close enough, right? 😁)</p>
<p>Evan Maloney <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009972.html">started a discussion</a> around introducing a simplified notation to avoid “the weak/strong dance” with closure capture lists. Feedback was pretty mixed, with the most compelling argument against this being that clients should be required to explicitly check for <code class="language-plaintext highlighter-rouge">nil</code>.</p>
<p>Dave Abrahams <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009684.html">announced</a> that the “InPlace” suffix will be removed from APIs in the standard library, namely SetAlgebra and <code class="language-plaintext highlighter-rouge">Set</code>. This is the result the continuing refinement of implementation of the <a href="https://swift.org/blog/swift-api-transformation/">API Guidelines</a>. (Also, this full thread is huuuge.)</p>
<p>Speaking of guidelines, Dave also <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160215/010472.html">announced</a> that they have been <a href="http://apple.github.io/swift-internals/api-design-guidelines/">updated</a> to incorporate feedback from the review. 🎉</p>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009624.html">pitched an idea</a> for overridable members in extensions. <em>“Today, methods introduced in an extension of a class cannot override or be overridden unless the method is (implicitly or explicitly) marked <code class="language-plaintext highlighter-rouge">@objc</code>. This proposal lifts the blanket restriction while still enforcing safety.”</em> So far, there’s positive support for this.</p>
<h3 id="finally">Finally</h3>
<p>And finally — compiler crashes are fixed <a href="https://github.com/apple/swift/commit/c83be882be0dee308fbc5993445bb966eee96734">pretty swiftly these days</a>. 😎</p>
Issue #9
https://swiftweeklybrief.com/issue-9
2016-02-11T00:00:00-08:00
2016-02-11T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Welcome to Issue #9 of the weekly brief! Because issues are zero-indexed, this means we’ve reached our 10th issue milestone. 🎉 Thanks for reading each week! 😄 Things seem to have slightly slowed down this week. Even the Xcode 7.3 beta 3 <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_7.3_beta_3/Xcode_7.3_beta_3_Release_Notes.pdf">release notes</a> were mostly uneventful. It feels like we’re getting closer to the final Xcode 7.3 and Swift 2.2 releases.</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>John Holdsworth merged a <a href="https://github.com/apple/swift/pull/1193">pull request</a> that fixes a missing Xcode “Quick Help” menu for enum values as switch case patterns. 👏</p>
<p>Dmitri Gribenko <a href="https://github.com/apple/swift/pull/1215">started work</a> on enabling iOS host tests.</p>
<p>David Grove from IBM Research <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/43">merged</a> an initial integration of Swift overlay into libdispatch build, and <a href="https://github.com/apple/swift/pull/1212">made changes</a> to allow building corelibs-libdispatch and corelibs-foundation together.</p>
<p>Brian Gesiak asked for Apple CI to cover corelibs-xctest, and <a href="https://twitter.com/modocache/status/697062595396816896">now it does</a>! 😎</p>
<p>The <a href="https://github.com/apple/swift/tree/master/benchmark">Swift Benchmark Suite</a> is now <a href="https://swift.org/blog/swift-benchmark-suite/">open source</a>! <em>“The suite contains source code for benchmarks, libraries, and utilities designed to help track Swift performance and catch performance regressions before they are committed.”</em></p>
<p>Nadav Rotem <a href="https://github.com/apple/swift/commit/422764545c720f696bf7061513eac30941d39cf4">improved</a> the metadata hashing function in the Swift runtime. 🤓</p>
<h3 id="proposals">Proposals</h3>
<p>Daniel Dunbar has prepared a <a href="https://github.com/apple/swift-evolution/pull/146">new proposal</a>, <em>“Package Manager C Language Target Support”</em>. (<a href="https://github.com/ddunbar/swift-evolution/blob/swiftpm-c-language-targets/proposals/NNNN-swiftpm-c-language-targets.md">Here</a>)</p>
<blockquote>
<p>This is a proposal for adding initial package manager support for the C, C++, Objective-C, and Objective-C++ languages. […] We would like Swift packages to be able to include C targets which can be exposed to Swift directly as part of a single package. This gives developers a simple mechanism for “falling back” to C…</p>
</blockquote>
<p>The mailing list thread <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20151228/000127.html">started here</a> back in January, but it looks like Daniel is just now submitting the pull request. Overall, support for this seems positive, though a lower priority for the SPM team. If accepted, the Swift Package Manager could potentially replace <a href="https://cocoapods.org">CocoaPods</a> — but I doubt this will happen soon. 😁 Also related, Ricardo Olivieri from IBM started a <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160125/000253.html">similar thread</a> regarding external dependencies and SPM.</p>
<p>Joe Groff’s <em>“Property Behaviors”</em> proposal (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0030-property-behavior-decls.md">SE-0030</a>) is now under <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000034.html">review</a>. This was <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html">introduced</a> awhile back on the mailing list, and I think the community was overwhelmingly excited about this. I’m sure it will be accepted.</p>
<p>Chris Lattner’s proposal, <em>“Remove implicit tuple splat behavior from function applications”</em> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0029-remove-implicit-tuple-splat.md">SE-0029</a>), has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000033.html">accepted</a> for Swift 3. Currently, instead of calling a function in the typical way, you can actually pass an N-tuple for the arguments instead. This little-known feature is being removed from Swift 3, as it is purely syntactic sugar.</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// some function</span>
<span class="kd">func</span> <span class="nf">foo</span><span class="p">(</span><span class="nv">a</span><span class="p">:</span> <span class="kt">Int</span><span class="p">,</span> <span class="nv">b</span><span class="p">:</span> <span class="kt">Int</span><span class="p">)</span> <span class="p">{</span> <span class="p">}</span>
<span class="c1">// normal call</span>
<span class="nf">foo</span><span class="p">(</span><span class="mi">42</span><span class="p">,</span> <span class="nv">b</span><span class="p">:</span> <span class="mi">17</span><span class="p">)</span>
<span class="c1">// using "tuple splat"</span>
<span class="k">let</span> <span class="nv">x</span> <span class="o">=</span> <span class="p">(</span><span class="mi">1</span><span class="p">,</span> <span class="nv">b</span><span class="p">:</span> <span class="mi">2</span><span class="p">)</span>
<span class="nf">foo</span><span class="p">(</span><span class="n">x</span><span class="p">)</span></code></pre></figure>
<p>Much of the feedback on this was “I’ve never used this”, so I doubt it will be missed. However, Becca Royal-Gordon has already started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009596.html">discussion</a> about a replacement.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Félix Cloutier started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009403.html">a discussion</a> about garbage collection. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009405.html">Joe Groff</a> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html">Chris Lattner</a> elaborated on the benefits and tradeoffs of reference counting versus generational mark-and-sweep. Joe <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009512.html">also noted</a> some historical, painful lessons learned with trying mark-and-sweep, while Austen Zheng <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009556.html">reminded</a> us of Android’s woes in this area.</p>
<p>Jordan Rose <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009451.html">asked for feedback</a> on library evolution support in Swift (“resilience”). This is not quite a proposal and will not go through the formal Swift Evolution proposal process, but feedback is encouraged! You can find the full document <a href="http://jrose-apple.github.io/swift-library-evolution/">here</a>.</p>
<p>After a ton of feedback from the community, Dave Abrahams revised his ideas from his <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008838.html">initial thread</a> on <em>“when to use argument labels (a new approach)”</em> and <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009206.html">started a new thread</a> to continue the discussion. If you have not been following along, the idea is exactly what the title describes. For example, which of the following is more appropriate: <code class="language-plaintext highlighter-rouge">a.moveFrom(b, to: c)</code> or <code class="language-plaintext highlighter-rouge">a.move(from: b, to: c)</code>? Of course, the full discussion is much more nuanced. One major goal of the API guidelines will be to help answer questions like this.</p>
Issue #8
https://swiftweeklybrief.com/issue-8
2016-02-04T00:00:00-08:00
2016-02-04T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week an <a href="https://swift.org/blog/swift-ci/">official blog post</a> on Swift.org announced the new continuous integration setup that I mentioned last week. There is now a <a href="https://swift.org/continuous-integration/">dedicated page</a> on the main site and you can check the status <a href="https://ci.swift.org">here</a>. It seems to be nicely <a href="https://twitter.com/modocache/status/693069527807041536">integrated</a> with GitHub, and <a href="https://github.com/apple/swift/pull/1151#issuecomment-178211302">mostly works</a>. 😄</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Erik Eckstein <a href="https://github.com/apple/swift/commit/aaaf36e83521f153ba4b0720795efe4980d9b124">committed</a> some <a href="https://twitter.com/jckarter/status/693190676666675200">impressive</a> whole module optimization performance improvements. 😎</p>
<p>David Farler <a href="https://github.com/apple/swift/commit/e87be804c9d8111012555263aa86021ab1735ccf">added support</a> for writing code block comments in any language.</p>
<p>William Dillon followed up on some <a href="https://github.com/apple/swift/pull/608">previous Linux/ARMv7</a> work, this time <a href="https://github.com/apple/swift/pull/1157">submitting a pull request</a> that adds support for gold linker. This change aims to solve issues on ARMv6/v7 and aarch64 platforms.</p>
<p>Harlan Haskins <a href="https://github.com/apple/swift/pull/1122">merged a pull request</a> that adds backtrace reporting on <code class="language-plaintext highlighter-rouge">fatalError</code>. 👏</p>
<p>C.W. Betts <a href="https://github.com/apple/swift-corelibs-foundation/pull/251">implemented</a> <code class="language-plaintext highlighter-rouge">NSUserDefaults</code> in corelibs-foundation.</p>
<p>Slava Pestov <a href="https://github.com/apple/swift/pull/1182">started</a> on adding support for resiliently adding protocol requirements with default implementations.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/pull/1185">implemented</a> code completion improvements for <code class="language-plaintext highlighter-rouge">#selector</code>.</p>
<h3 id="proposals">Proposals</h3>
<p>Joe Groff and Erica Sadun <a href="https://github.com/apple/swift-evolution/pull/128/files">submitted a proposal</a>, <em>“Adjusting <code class="language-plaintext highlighter-rouge">inout</code> Declarations for Type Decoration”</em>. They suggest moving the <code class="language-plaintext highlighter-rouge">inout</code> keyword from the label side to the type side in a function declaration to clarify that this decorates types and avoid confusion with similarly named argument labels.</p>
<p>Nate Cook <a href="https://github.com/apple/swift-evolution/pull/125">has proposed</a> to <em>“Add sequence-based initializers and merge methods to Dictionary”</em>.</p>
<blockquote>
<p>The <code class="language-plaintext highlighter-rouge">Dictionary</code> type should allow initialization from a sequence of <code class="language-plaintext highlighter-rouge">(Key, Value)</code> tuples and offer methods that merge a sequence of <code class="language-plaintext highlighter-rouge">(Key, Value)</code> tuples with an existing dictionary.</p>
</blockquote>
<p>The proposal, <em>“Modernizing Swift’s Debugging Identifiers”</em>, (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md">SE-0028</a>) has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-February/000030.html">accepted</a>! 👏</p>
<p>The review for proposals <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md">SE-0005</a>, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md">SE-0006</a>, <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md">SE-0023</a> has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000029.html">extended</a> until February 5. If you have opinions on the <a href="https://swift.org/blog/swift-api-transformation/">great Swift API transformation</a>, speak now!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Justin Kolb started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/007984.html">a thread</a> for proposing support for contiguous variables.</p>
<blockquote>
<p>To better support interfacing with lower level systems, like graphics
libraries for example, it would be helpful to support the concept of
contiguous variables.</p>
</blockquote>
<p>Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-lldb-dev/Week-of-Mon-20160201/000043.html">announced</a> that the Swift 2.2 branch is now under restrictive change control, meaning any changes going in to <code class="language-plaintext highlighter-rouge">swift-2.2-branch</code> will require specific approval from the release manager.</p>
<p>Gwendal Roué started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160125/008167.html">a thread</a> about guaranteed closure execution.</p>
<p>As expected, the <a href="https://lists.swift.org/pipermail/swift-evolution/">swift-evolution</a> mailing list has been super busy with the discussion of the three proposals mentioned above (SE-0005, SE-0006, SE-0023). There is definitely too much to try to summarize or link to here. If you have a minute to read through the archives, you should!</p>
<p>Related to this review, Dave Abrahams started an <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/008838.html">exploratory thread</a>, <em>“When to use argument labels (a new approach)”</em>.</p>
<p>Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160201/009015.html">revealed</a> that at one point the Swift team briefly discussed using <code class="language-plaintext highlighter-rouge">‽</code> (the <a href="https://en.wikipedia.org/wiki/Interrobang">interrobang</a>) as the sugar for <code class="language-plaintext highlighter-rouge">ImplicitlyUnwrappedOptional</code>. 🤓</p>
<h3 id="finally">Finally</h3>
<p>And finally — has Bjarne ever <a href="https://github.com/apple/swift/pull/1183#commitcomment-15864521">made the mistake</a> of forgetting the <code class="language-plaintext highlighter-rouge">~</code> for C++ destructors? Jacob Bandes-Storch <a href="https://twitter.com/dgregor79/status/694988732718448642">saved the day</a> with this massive <a href="https://github.com/apple/swift/pull/1183/files">pull request</a>. 😂</p>
Issue #7
https://swiftweeklybrief.com/issue-7
2016-01-28T00:00:00-08:00
2016-01-28T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>This week brought us <a href="https://twitter.com/SwiftLang/status/691805674079195136">Xcode 7.3 beta2</a> — the first official Xcode release that bundles Swift 2.2 <em>and</em> includes contributions from the Swift.org open source community! I never thought I would see <a href="http://adcdownload.apple.com/Developer_Tools/Xcode_7.3_beta_2/Xcode_7.3_beta_2_Reease_Notes.pdf">release notes</a> like this. It really is incredible to see community-driven changes in the <em>What’s New</em> sections with links to GitHub. Clearly, the next big step for Apple should be open sourcing Xcode. 😉</p>
<!--excerpt-->
<h3 id="repositories">Repositories</h3>
<p>Did you <a href="https://twitter.com/modocache/status/690342486917668864">notice</a> the new <a href="https://github.com/apple/swift-integration-tests">swift-integration-tests</a> repository on GitHub? According to the <a href="https://github.com/apple/swift-integration-tests/commit/db437d2fa1951a9190b2c4adafffc701965ea8c4">history</a> it looks like this repo has been around since the initial open source announcement, but until now has been private. As you might guess, it includes tests. More specifically, <em>“Automated tests for validating the generated Swift snapshots behave correctly”</em>.</p>
<p>Slightly related, you may also have <a href="https://twitter.com/simjp/status/692135037270134784">noticed</a> that there’s <a href="https://github.com/swift-ci">a new CI bot</a> in town. (<a href="http://cdn.meme.am/instances/60114268.jpg">Seems legit</a>)</p>
<p>But wait, there’s more!</p>
<p><strong>Another</strong> new repository appeared over the past week, <a href="https://github.com/apple/swift-internals">swift-internals</a>. It contains <a href="http://apple.github.io/swift-internals/">this site</a>. According to the welcome page, the site <em>“hosts internal documentation for the Swift compiler and standard library, as well as the development version of the Swift API Guidelines.”</em>. 😦 Unfortunately, it only contains the API guidelines at the moment. Documentation for the Swift compiler sounds like it would be great for contributors. Also, does this mean <a href="https://twitter.com/nnnnnnnn">Nate Cook</a> can shutdown <a href="http://swiftdoc.org">SwiftDoc.org</a>? 😄</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Doug Gregor <a href="https://github.com/apple/swift/commit/ecfde0e71c61184989fde0f93f8d6b7f5375b99a">started</a> and <a href="https://github.com/apple/swift/commit/c9c1d1390c621dc3932c0a77c8a191e6411b71f2">finished</a> implementing proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md">SE-0021</a>, <em>“Naming Functions with Argument Labels”</em>.</p>
<p>Doug Gregor also implemented <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">SE-0022</a>, <em>“Referencing the Objective-C selector of a method”</em>. (Yes, it was <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000026.html">accepted</a>.) No more <em>stringly-typed</em> Objective-C selectors! I enjoyed the <a href="https://twitter.com/dgregor79/status/692480515534934017">live</a> <a href="https://twitter.com/dgregor79/status/692598054025715712">tweeting</a> experience. 😂 You can check out the commits here: <a href="https://github.com/apple/swift/commit/dccf3155f1fe5400df0c9b51f21a3b8f7fa09b9c">dccf315</a>, <a href="https://github.com/apple/swift/commit/7c0e087cd514c926d9eaa3082679edff626effc8">7c0e087</a>, <a href="https://github.com/apple/swift/commit/89834f8d5fcce652401ecaeec4addace48cb2fae">89834f8</a>, <a href="https://github.com/apple/swift/commit/f7407f6a4d2c9b20ef1d2aab6dbaff5f9419aa88">f7407f6</a>.</p>
<p>Greg Titus <a href="https://github.com/apple/swift/pull/1042">improved</a> quality of diagnoses messages, and has generally <a href="https://github.com/apple/swift/pull/1069">been</a> <a href="https://github.com/apple/swift/pull/1089">on a roll</a> with pull requests. 👏</p>
<p>Brian Gesiak submitted a <a href="https://github.com/apple/swift-corelibs-xctest/pull/43">pull request</a> that implements the asynchronous testing API in corelibs-xctest. It mirrors the Objective-C XCTest API, adding the familiar methods <code class="language-plaintext highlighter-rouge">expectationWithDescription()</code> and <code class="language-plaintext highlighter-rouge">waitForExpectationsWithTimeout()</code>.</p>
<p>Nate Cook <a href="https://github.com/apple/swift/pull/1063">added</a> an in-place merge sort to the standard library. From the description: <em>“This sort algorithm is both stable and offers a significant speed increase (1.5x-10x or more) in many common sorting scenarios.”</em> 😎</p>
<p>William Dillon <a href="https://github.com/apple/swift/pull/901">added support</a> for ARMv6 (original Raspberry Pi) and fixed some ARMv7 bugs.</p>
<p><strong>@tinysun212</strong> started a <a href="https://github.com/apple/swift/pull/1108">port to cygwin</a>.</p>
<p>Brian Croom submitted a <a href="https://github.com/apple/swift-corelibs-xctest/pull/40">pull request</a> to corelibs-xctest to discuss compatibility between Darwin XCTest and corelibs-xctest.</p>
<h3 id="proposals">Proposals</h3>
<p>Erica Sadun has <a href="https://github.com/apple/swift-evolution/pull/116/">proposed</a> to <em>“Eliminate Swift’s Screaming Snake Case Identifiers”</em> and thus say goodbye to another vestige of C. (<a href="https://github.com/erica/swift-evolution/blob/master/proposals/00xx-modernizing-debug-identifiers.md">Proposal here</a>)</p>
<blockquote>
<p>This proposal aims to eliminate Swift’s screaming snake case like <code class="language-plaintext highlighter-rouge">__FILE__</code> and <code class="language-plaintext highlighter-rouge">__FUNCTION__</code> and replacing instances with a common octothorpe-prefixed lower camel case <code class="language-plaintext highlighter-rouge">#sourceLocation</code> representation.</p>
</blockquote>
<p>The proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0013-remove-partial-application-super.md">SE-0013</a>, <em>“Remove Partial Application of Non-Final Super Methods”</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000022.html">rejected</a>.</p>
<p>The following three proposals are now under review. These proposals are related and thus the reviews are running concurrently:</p>
<ul>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0023-api-guidelines.md">SE-0023</a>, <em>API Design Guidelines</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md">SE-0006</a>, <em>Apply API Guidelines to the Standard Library</em></li>
<li><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0005-objective-c-name-translation.md">SE-0005</a>, <em>Better Translation of Objective-C APIs Into Swift</em></li>
</ul>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Nicole Jacque <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160125/000934.html">notes</a> that there is a new snapshot naming format. From now on, development version snapshots will begin with <code class="language-plaintext highlighter-rouge">swift-DEVELOPMENT-SNAPSHOT</code> to clearly distinguish between release snapshots.</p>
<p>Dmitri Gribenko <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160125/000943.html">investigated and greatly reduced</a> <code class="language-plaintext highlighter-rouge">StdlibUnittest</code> build time. <code class="language-plaintext highlighter-rouge">StdlibUnittest</code> is an internal library that is used to write tests for the stdlib, parts of the runtime, and the compiler.</p>
<blockquote>
<p>But there is an issue: today, StdlibUnittest takes a long time to build. […]</p>
<p>These time measurements show that the build time of the combined module is
greater than the sum of the build times of the pieces, and much more so when
the optimization is turned on. We can make a conjecture that the optimizer is
not scaling well with the module size.</p>
</blockquote>
<h3 id="finally">Finally</h3>
<p>And finally — if you feel like Swift is changing too fast or if you are simply interested in trying something new, may I suggest <a href="https://github.com/samshadwell/TrumpScript">TrumpScript</a>? 😂 Let’s make programming great again.™</p>
Issue #6
https://swiftweeklybrief.com/issue-6
2016-01-21T00:00:00-08:00
2016-01-21T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>It has been over a month since the initial Swift open source announcement and I still keep discovering new things. I’m still just as excited to watch Swift grow and evolve. Welcome to issue #6 of the weekly brief!</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/antonblanchard">Anton Blanchard</a> has his <a href="https://github.com/apple/swift/pull/979">pull request</a> merged which adds PowerPC64le Linux support. <a href="https://github.com/apple/swift/pull/979#issuecomment-171833623">Impressive</a> and <a href="https://github.com/apple/swift/pull/979#issuecomment-171876376">very cool</a>, indeed. 😎</p>
<p><strong>@lplarson</strong> submitted a <a href="https://github.com/apple/swift/pull/997">pull request</a> to support code coverage analysis. Glad to see this. It would be great to get automatic reports on pull requests, too.</p>
<p>Chris Lattner continued his <a href="https://twitter.com/clattner_llvm/status/674254974629502976">late night hobby</a> — <a href="https://github.com/apple/swift/commit/20263bf46658dccafced86955fbf33ad72853c6d">fixing</a> <a href="https://github.com/apple/swift/commit/ce94e0af538f9f7e47dc1979e4db60549ffb9010">more</a> <a href="https://github.com/apple/swift/commit/9c9ddf9e6cba3ea199bcfd59e039c404b68bb1ac">radars</a>.</p>
<p>The curious case of the <code class="language-plaintext highlighter-rouge">associatedtype</code> (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md">proposal here</a>): Greg Titus <a href="https://github.com/apple/swift/pull/964">implemented</a> <code class="language-plaintext highlighter-rouge">associatedtype</code>. 👏 Then <strong>@eeckstein</strong> <a href="https://github.com/apple/swift/commit/ce7b2bcf094a17fec1a3f3cfa713995f3ced1ef3">reverted</a> the change due to failing tests. Doug Gregor then <a href="https://github.com/apple/swift/commit/38c1de69e4b4c27ac1916d1e6fe601beb5d3a5f4">reverted the revert</a> with fixed tests. (<a href="http://cdn.meme.am/instances/500x/58010858.jpg">Yo dawg, I heard you like reverts</a>) Long story short, <code class="language-plaintext highlighter-rouge">associatedtype</code> is now implemented for Swift 2.2. 😎</p>
<p>Greg Titus also <a href="https://github.com/apple/swift/pull/976">updated</a> the stdlib for <code class="language-plaintext highlighter-rouge">associatedtype</code>. And <a href="https://github.com/lhoward">Luke Howard</a> merged a <a href="https://github.com/apple/swift-corelibs-foundation/pull/230">pull request</a> to update corelibs-foundation. 🎉</p>
<p>Stephen Celis <a href="https://github.com/apple/swift-corelibs-foundation/pull/234">cleaned up</a> <code class="language-plaintext highlighter-rouge">NSDateFormatter</code>. This is not necessarily a notable change, but what’s interesting to me is that <code class="language-plaintext highlighter-rouge">NSDateFormatter</code> was originally implemented with Objective-C style (now referred to as <em>“old school”</em> style) ivars and public getters/setters. This is precisely the kind of boilerplate that Swift aims to reduce. 😂 Another alarming thing is that the non-public properties were marked as <code class="language-plaintext highlighter-rouge">internal</code> rather than <code class="language-plaintext highlighter-rouge">private</code>, meaning the entire Foundation module had readwrite access and could bypass the public getters/setters. 🤔 Odd. Here’s an example:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="c1">// Before this commit</span>
<span class="kd">internal</span> <span class="k">var</span> <span class="nv">_dateStyle</span><span class="p">:</span> <span class="kt">NSDateFormatterStyle</span> <span class="o">=</span> <span class="o">.</span><span class="kt">NoStyle</span>
<span class="kd">public</span> <span class="k">var</span> <span class="nv">dateStyle</span><span class="p">:</span> <span class="kt">NSDateFormatterStyle</span> <span class="p">{</span>
<span class="k">get</span> <span class="p">{</span>
<span class="k">return</span> <span class="n">_dateStyle</span>
<span class="p">}</span>
<span class="k">set</span> <span class="p">{</span>
<span class="nf">_reset</span><span class="p">()</span>
<span class="n">_dateStyle</span> <span class="o">=</span> <span class="n">newValue</span>
<span class="p">}</span>
<span class="p">}</span>
<span class="c1">// After this commit</span>
<span class="kd">public</span> <span class="k">var</span> <span class="nv">dateStyle</span><span class="p">:</span> <span class="kt">NSDateFormatterStyle</span> <span class="o">=</span> <span class="o">.</span><span class="kt">NoStyle</span> <span class="p">{</span>
<span class="k">willSet</span> <span class="p">{</span>
<span class="nf">_reset</span><span class="p">()</span>
<span class="p">}</span>
<span class="p">}</span></code></pre></figure>
<p>Also remember that Swift’s <code class="language-plaintext highlighter-rouge">willSet</code>/<code class="language-plaintext highlighter-rouge">didSet</code> property observers were available since 1.0, which makes this even more bizarre. However, it’s most likely that this was automatically <a href="https://twitter.com/jckarter/status/689157377149415424">generated from an Objective-C interface</a>. In that case, I’m sure there are plenty of areas that could use improvements. Keep digging!</p>
<p>Ted Kremenek <a href="https://github.com/apple/swift/pull/1007">fixed two regressions</a> from Swift 2.1 related to parameter parsing.</p>
<h3 id="proposals">Proposals</h3>
<p>The main <a href="https://github.com/apple/swift-evolution#development-minor-version--swift-22">README on swift-evolution</a> has been updated to track already implemented and accepted proposals for Swift 2.2. This is a great way to see high-level progress at a glance. Of course, I’ll keep you up-to-date too. 😉</p>
<p>Jacob Bandes-Storch has prepared <a href="https://github.com/jtbandes/swift-evolution/blob/977a9923fd551491623b6bfd398d5859488fe1ae/proposals/0000-derived-collection-of-enum-cases.md">a proposal</a>, <em>“Derived Collection of Enum Cases”</em>. This proposal would provide a much needed reflection API for <code class="language-plaintext highlighter-rouge">enum</code>. Jacob suggests adding an <code class="language-plaintext highlighter-rouge">Array</code> property on <code class="language-plaintext highlighter-rouge">enum</code> types, <code class="language-plaintext highlighter-rouge">.cases</code>, which returns an array of all cases in the <code class="language-plaintext highlighter-rouge">enum</code>. Currently, we have to write this manually.</p>
<p>Doug Gregor’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">proposal</a> from last week’s issue, <em>“Referencing the Objective-C selector of a method”</em>, is <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000020.html">under review</a>.</p>
<p><a href="https://github.com/SlaunchaMan">Jeff Kelley</a> submitted <a href="https://github.com/apple/swift-evolution/pull/110/files">a proposal</a>, <em>“Import Objective-C constants as Swift enums”</em>. The goal here is to expose groups of Objective-C string constants to Swift as an <code class="language-plaintext highlighter-rouge">enum</code> instead. This would apply to other types as well, such as groups of integer constants. 👍</p>
<p>Doug Gregor’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0021-generalized-naming.md">proposal</a>, <em>“Naming Functions with Argument Labels”</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000021.html">accepted</a> for Swift 2.2 and 3.0.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Last week, I missed that John Lin started <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160111/000777.html">working on a Chinese translation</a> of Swift.org (<a href="https://swiftlang.tw">here</a>). This week, Ted Kremenek <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160118/000856.html">continued the thread</a> noting that Swift.org is a Jekyll site, currently hosted on GitHub in a private repository, and that team is planning to eventually make it open source! 🎉</p>
<p>Also from last week (😁), Matthew Johnson’s <em>“Flexible Memberwise Initialization”</em> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md">proposal</a> has been “rejected”, though it is really more like “deferred until after Swift 3”. As Chris Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006469.html">explains</a>, <em>“the core team really doesn’t want to discuss this right now, given that this is purely a sugar proposal and we need to stay focused on the primary Swift 3 goals.”</em></p>
<p>Swift currently has no way to specify if subclasses are required to call <code class="language-plaintext highlighter-rouge">super</code> for overridden methods. I started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006878.html">discussion</a> to present some ideas for a solution to this by extending the use of <code class="language-plaintext highlighter-rouge">required</code> to class methods other than <code class="language-plaintext highlighter-rouge">init</code>. (Technically, it began on <a href="https://twitter.com/jesse_squires/status/686960179435323392">Twitter</a>, and <a href="https://twitter.com/nbirkholz">Nate Birkholz</a> kindly <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006667.html">started the thread</a> on the mailing list.) Matthew Johnson has since <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160118/006912.html">pointed out</a> additional deficiencies in this area. Of course, you could always make all your methods be initailizers — <a href="https://twitter.com/jckarter/status/686958750335279108">problem solved</a>. 😂</p>
<p>Davide Italiano <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20160118/000911.html">announced</a> that Swift is now functional on FreeBSD.</p>
<p>The second review of the <em>“Swift Testing (Package Manager)”</em> proposal <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20160111/000243.html">has begun</a>! (Revised proposal <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md">here</a>). 🎉</p>
<h3 id="finally">Finally</h3>
<p>And finally, in case you missed the fun:</p>
<blockquote>
<p>Q: As an Objective-C programmer, I’m not very good at dieting. Why?</p>
<p>A: <a href="https://twitter.com/modocache/status/689669646497255424">weak self</a></p>
</blockquote>
Issue #5
https://swiftweeklybrief.com/issue-5
2016-01-14T00:00:00-08:00
2016-01-14T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>As you can see, the <em>weekly brief</em> has a new home! It feels much nicer to have a dedicated site rather than my <a href="http://www.jessesquires.com/new-weekly-brief/">personal blog</a>. I’m sure there are still some bugs lurking around, so if you find any or have suggestions for improvements to the site, please <a href="https://github.com/SwiftWeekly/swiftweekly.github.io/issues/new">open an issue</a> on GitHub!</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p>Erik Little, Jesse Rusak, and Mike Ash discovered a <a href="https://bugs.swift.org/browse/SR-510">really cool bug</a>. This compiles:</p>
<figure class="highlight"><pre><code class="language-swift" data-lang="swift"><span class="kd">enum</span> <span class="kt">Testing</span><span class="p">:</span> <span class="kt">String</span> <span class="p">{</span>
<span class="k">case</span> <span class="kt">Thing</span> <span class="o">=</span> <span class="s">"thing"</span>
<span class="k">case</span> <span class="kt">Bob</span> <span class="o">=</span> <span class="p">{</span><span class="o">!</span><span class="err">@#$</span><span class="o">!</span><span class="err">@#</span><span class="o">%!</span><span class="err">@</span><span class="p">}</span> <span class="c1">// lolwut</span>
<span class="p">}</span></code></pre></figure>
<p><a href="https://github.com/apple/swift/pull/931">Daniel Duan</a> and <a href="https://github.com/apple/swift/pull/934">Jesse Rusak</a> both attempted fixes. Perhaps Daniel’s <a href="https://github.com/apple/swift/pull/955">currently open</a> pull request will get merged?</p>
<p>Jacob Bandes-Storch <a href="https://github.com/apple/swift/pull/910">fixed 4 compiler crashers</a> thanks to <a href="https://github.com/practicalswift">@practicalswift</a>’s fuzzer. And then <a href="https://github.com/apple/swift/pull/926">8 more crashers, plus an IDE crasher</a>. 😂</p>
<p><a href="https://github.com/atrick">@Atrick</a> fixed a <a href="https://github.com/apple/swift/commit/9cf84c24ca860c64b6858d61d271476d5575592a">leak</a> when interpolating optional references. (<a href="https://bugs.swift.org/browse/SR-459">SR-459</a>)</p>
<p>Brian Gesiak’s “testing the tests” <a href="https://github.com/apple/swift-corelibs-xctest/pull/20">pull request</a> finally merged! He is now the <a href="https://github.com/apple/swift-corelibs-xctest/graphs/contributors">#1 contributor</a> to corelibs-xctest according to GitHub. 😦</p>
<h3 id="proposals">Proposals</h3>
<p>Loïc Lecrenier’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md">proposal</a>, <em>“Replace <code class="language-plaintext highlighter-rouge">typealias</code> keyword with <code class="language-plaintext highlighter-rouge">associatedtype</code> for associated type declarations”</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000014.html">accepted</a> for Swift 2.2! Using <code class="language-plaintext highlighter-rouge">typealias</code> in protocols will be deprecated in 2.2 and removed from 3.0 entirely. It should be easy to migrate your existing code.</p>
<p>Doug Gregor <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md">submitted a proposal</a>, <em>“Referencing the Objective-C selector of a method”</em>. It’s a dream come true. This has been a glaring issue from the beginning for interoperability with Objective-C. It looks like this feature can be added in Swift 2.2 and deprecate the use of string literals, after which 3.0 would remove the old syntax entirely.</p>
<blockquote>
<p><em>“In Swift 2, Objective-C selectors are written as string literals (e.g., <code class="language-plaintext highlighter-rouge">"insertSubview:aboveSubview:"</code>) in the type context of a Selector. This proposal seeks to replace this error-prone approach with Selector initialization syntax that refers to a specific method via its Swift name.”</em> 👏</p>
</blockquote>
<p>David Farler’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0020-if-swift-version.md">proposal</a>, <em>“Swift Language Version Build Configuration”</em> is under review. <em>“Over time, Swift syntax may change but library and package authors will want their code to work with multiple versions of the language.”</em> This proposal would allow programmatically checking the Swift version number, for example <code class="language-plaintext highlighter-rouge">#if swift(>=2.2)</code>. As a library author, I would welcome this feature!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>After a ton of <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160111/006466.html">discussion</a> on the mailing list (and <a href="https://github.com/apple/swift-evolution/pull/51">github</a> 😳), the <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0019-package-manager-testing.md">proposal</a> for testing support in the Swift Package Manager is moving back to “under revision” to incorporate even more feedback from the community.</p>
<p>Chris Hanson <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/006091.html">started a thread</a> discussing adding XCTest support for Swift error handling. This would make <code class="language-plaintext highlighter-rouge">throws</code> a first-class citizen within XCTest, where it is currently a bit cumbersome and awkward to use. Remember <a href="https://www.natashatherobot.com/unit-testing-optionals-in-swift-xctassertnotnil/">that time</a> when XCTest didn’t really work with optionals? 😄</p>
<p>Drew Crawford <a href="https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20151228/000125.html">started a thread</a> discussing how the Swift Package Manager could support third-party testing frameworks. I know a lot of developers in the community would love this, as it would allow using frameworks other than XCTest for testing.</p>
Issue #4
https://swiftweeklybrief.com/issue-4
2016-01-07T00:00:00-08:00
2016-01-07T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>Now that the holidays are over, things have started to pick up again on Swift.org. If you are following any of the repos on GitHub, you have probably noticed. I’m not sure how I missed this before, but this week I just discovered <a href="https://github.com/apple/swift/blob/master/stdlib/internal/SwiftExperimental/SwiftExperimental.swift">SwiftExperimental.swift</a>. For now, it defines a bunch of custom unicode operators for <code class="language-plaintext highlighter-rouge">Set</code>. It’s really cool. I would love to see more APIs like this in the standard library. Anyway, here’s the weekly brief!</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/austinzheng">Austin Zheng</a> submitted a <a href="https://github.com/apple/swift/pull/838">pull request</a> to remove to old mirror API.</p>
<p><a href="https://github.com/argon">Andrew Naylor</a> merged <a href="https://github.com/apple/swift-corelibs-foundation/pull/181">changes</a> to speed up JSON parsing in corelibs-foundation. We all know how much the Swift community loves JSON parsing. 😉</p>
<p><a href="https://github.com/keith">Keith Smiley</a> submitted a <a href="https://github.com/apple/swift-corelibs-xctest/pull/25">pull request</a> to that adds support for the Swift package manager to corelibs-xctest. 👏</p>
<p>Chris Lattner completely <a href="https://github.com/apple/swift/commit/7daaa22d936393f37176ba03975a0eec7277e1fb">redesigned</a> the AST representation of parameters.</p>
<h3 id="proposals">Proposals</h3>
<p>Matthew Johnson’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0018-flexible-memberwise-initialization.md">proposal</a> to improve memberwise initializers is now <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000010.html">under review</a>. As Lattner <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151130/000518.html">pointed out</a>, there are a number of deficiencies with the current memeberwise initializer behavior in Swift. I have a good feeling this will be accepted.</p>
<p>The proposal to “require self for accessing instance members” has been (thankfully) <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2016-January/000009.html">rejected</a>. Some of the main reasons for this decision were that it (1) introduces verbosity rather than clarity, (2) diminishes the use of <code class="language-plaintext highlighter-rouge">self.</code> as an indicator for possible retain cycles, and (3) teams wishing to adopt this usage could simply enforce it with a linter.</p>
<p>Doug Gregor has submitted a <a href="https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md">proposal</a> for <em>Generalized Naming for Any Function</em>. From the introduction: <em>“Swift includes support for first-class functions, such that any function (or method) can be placed into a value of function type. However, it is not possible to specifically name every function that is part of a Swift program — one cannot provide the argument labels when naming a function.”</em> The lack of this feature is definitely a pain point in Swift, especially when working with Cocoa and Objective-C selectors. It’s a short read!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Doug Gregor <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160104/005312.html">notes</a> some surprising behavior when extending an <code class="language-plaintext highlighter-rouge">@objc</code> protocol — the members of the <code class="language-plaintext highlighter-rouge">extension</code> are not exposed to the Objective-C runtime. 😳 Luckily, I haven’t run into this bug myself.</p>
<h3 id="finally">Finally</h3>
<p>And finally — is <code class="language-plaintext highlighter-rouge">?.</code> the <a href="https://twitter.com/uint_min/status/683532142677114880">“call-me-maybe” operator</a> in Swift? <strong>That’s it for this week!</strong></p>
<!-- Note, this is a legacy include -->
<div class="alert alert-info">
<p><strong>Note:</strong> This issue was originally published at <a href="http://www.jessesquires.com/open-source-swift-weekly-4/" class="alert-link" target="_blank">jessesquires.com</a></p>
</div>
Issue #3
https://swiftweeklybrief.com/issue-3
2015-12-24T00:00:00-08:00
2015-12-24T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>As expected with the holiday season, <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/Week-of-Mon-20151214/000179.html">things are</a> <a href="https://lists.swift.org/pipermail/swift-dev/Week-of-Mon-20151221/000540.html">slowing down</a> for a bit on Swift.org. I have been traveling for the holidays as well, so this issue will be shorter than usual. If you haven’t already, be sure you take some time away from coding to enjoy the holidays and <a href="https://twitter.com/chriseidhof/status/679213894343200768">avoid burnout</a>. 😄 Now, the weekly brief!</p>
<!--excerpt-->
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/tienex">@tienex</a> submitted a <a href="https://github.com/apple/swift/pull/608">pull request</a> for Linux/armv7 support.</p>
<p><a href="https://github.com/practicalswift">@practicalswift</a> added a ton of <a href="https://github.com/apple/swift/pulls?utf8=✓&q=is%3Apr+author%3Apracticalswift+is%3Aclosed+test+case">test cases</a>. And as of this writing, there are still a few waiting to be merged.</p>
<p><a href="https://github.com/masters3d">@masters3d</a> merged a <a href="https://github.com/apple/swift-evolution/pull/72/files">pull request</a> to swift-evolution that documents commonly proposed changes to Swift. This is a great idea to help reduce duplicate proposals. Don’t forget to <a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md">check this list</a> before suggesting a change on the mailing list! 👏</p>
<p>Doug Gregor <a href="https://github.com/apple/swift/commit/c8dd8d066132683aa32c2a5740b291d057937367">implemented SE-0001</a>, which <em>“allows (most) keywords as argument labels”</em>. This is a great change. When Swift was initially released, one of my Objective-C libraries used <code class="language-plaintext highlighter-rouge">extension:</code> as a <a href="https://github.com/jessesquires/JSQSystemSoundPlayer/issues/8">parameter name</a> (for a file extension string) and bridging to Swift caused all kinds of problems, thus I ended up having to rename it to <code class="language-plaintext highlighter-rouge">fileExtension:</code>. Glad to see I can revert this change in Swift 2.2! Note that the keywords <code class="language-plaintext highlighter-rouge">var</code>, <code class="language-plaintext highlighter-rouge">let</code>, and <code class="language-plaintext highlighter-rouge">inout</code> are excluded from this.</p>
<h3 id="proposals">Proposals</h3>
<p>Oisin Kidney’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0008-lazy-flatmap-for-optionals.md">proposal (SE-0008)</a>, <em>Add a Lazy flatMap for Sequences of Optionals</em>, has been <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2015-December/000006.html">accepted</a> for Swift 2.2! 🎉</p>
<p>Kevin Ballard’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0015-tuple-comparison-operators.md">proposal (SE-0015)</a>, <em>Tuple comparison operators</em> has also been <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004423.html">accepted</a>! As of this writing, the status of the proposal on GitHub has not been updated to reflect this. Since this proposal should not affect existing code, I assume it will be included for Swift 2.2. 🎉</p>
<p>Joe Groff submitted <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003148.html">a proposal</a> to add property behaviors to Swift. You can find <a href="https://gist.github.com/jckarter/f3d392cf183c6b2b2ac3">draft</a> on GitHub. Or if you prefer to receive information via <a href="https://twitter.com/jckarter/status/677554831003791360">tweet</a>, there’s that too. 😄 In short, the proposal outlines an extensible framework for applying various behaviors to properties, similar to <code class="language-plaintext highlighter-rouge">atomic</code> or <code class="language-plaintext highlighter-rouge">copy</code> in Objective-C. Currently, Swift has some special-purpose hardcoded behaviors, for example,<code class="language-plaintext highlighter-rouge">lazy</code>, <code class="language-plaintext highlighter-rouge">@NSCopying</code>, and <code class="language-plaintext highlighter-rouge">willSet</code>/<code class="language-plaintext highlighter-rouge">didSet</code>. This proposal aims to generalize and unify these concepts such that they are implemented via the same underlying framework and can be easily extended. Clients could even implement their own behaviors. It sounds awesome. Some example behaviors include: lazy, memoization, delayed initialization, resettable, and synchronized. Definitely worth the read!</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>Andyy Hope started <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/003819.html">a discussion</a> around adding an <code class="language-plaintext highlighter-rouge">.allValues</code> static variable to enums, which would return an array of all cases in the enum. Looks like there is a lot of support for the idea so far. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001233.html">Jacob Bandes-Storch</a> also brought up this idea up a couple of weeks ago. I would definitely be in favor of this, as I’ve found myself writing this boilerplate multiple times. 👍</p>
<p>Kevin Ballard <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151221/004223.html">suggests</a> a more formal “This Week In Swift” newsletter. 😁 Maybe I should go ahead and setup swiftweekly.org?</p>
<p><strong>That’s it for this week!</strong> Cheers.</p>
<!-- Note, this is a legacy include -->
<div class="alert alert-info">
<p><strong>Note:</strong> This issue was originally published at <a href="http://www.jessesquires.com/open-source-swift-weekly-3/" class="alert-link" target="_blank">jessesquires.com</a></p>
</div>
Issue #2
https://swiftweeklybrief.com/issue-2
2015-12-17T00:00:00-08:00
2015-12-17T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>The Swift.org community is finishing up its second full week of open source development. If you were hoping for a quiet week, you will definitely be disappointed. There is still a ton of activity with no signs of slowing down. The Swift team <a href="https://twitter.com/uint_min/status/675022507527684096">continues</a> to work openly and to be <a href="https://github.com/apple/swift/pull/389#issuecomment-163851653">encouraging</a> to contributors. This week brought more crash fixes and more Swift Evolution proposals. Let’s get to it — the weekly brief!</p>
<!--excerpt-->
<h3 id="community">Community</h3>
<p>Craig Federighi reflects on Swift’s first week out in the open with John Gruber on <a href="http://daringfireball.net/thetalkshow/2015/12/07/ep-139">The Talk Show</a>. I really enjoyed listening to this episode and continue to be surprised by Apple’s openness! The interview is only about 30 minutes. There is also a <a href="http://daringfireball.net/thetalkshow/139/federighi-gruber-transcript">transcript</a> on Daring Fireball.</p>
<p>It looks like <a href="https://github.com/zhuowei">@zhuowei</a> started a port for <a href="https://github.com/SwiftAndroid">Android</a>. I really hope this project takes off. Writing Android apps in Swift could be a huge win for mobile developers.</p>
<p>One clarification from last week — currying will not removed completely, <a href="https://github.com/apple/swift-evolution/pull/43#issuecomment-163849233">just the syntax</a>.</p>
<h3 id="commits-and-pull-requests">Commits and pull requests</h3>
<p><a href="https://github.com/slavapestov">Slava Pestov</a> pushed <a href="https://github.com/apple/swift/commit/c258f991f64a431da57fc79b66e879e5062fba3b">a commit</a> that <em>fixed <a href="https://github.com/apple/swift/commit/c258f991f64a431da57fc79b66e879e5062fba3b#commitcomment-14971959">91 percent</a> of the outstanding compiler crashers.</em> 😲</p>
<p><a href="https://github.com/nubbel">Dominique d’Argent</a> introduced the first <a href="https://github.com/apple/swift-corelibs-foundation/pull/93#discussion_r47160608">unicode variable name</a> in his implementation of <code class="language-plaintext highlighter-rouge">NSAffineTransform</code>. This is the only one that I’ve seen so far. I will happily buy a ☕️ or 🍺 for anyone who can successfully merge a pull request that uses 💩.</p>
<p><a href="https://github.com/apple/swift/pull/413">Bill Abt</a> and <a href="https://github.com/apple/swift-corelibs-libdispatch/pull/15">David Grove</a> from IBM made significant contributions to Swift and the core libraries! As Federighi mentioned on The Talk Show, IBM <em>really</em> wants to use Swift on the server.</p>
<p>Chris Lattner <a href="http://github.com/apple/swift/commit/a2d9b10b64c3115c2eed7b6baa8f641db9fc246e">fixed</a> <a href="https://github.com/apple/swift/commit/e28c2e2c6e4c7da665090f0acce4c68cbf4ebc15">a few</a> <a href="https://github.com/apple/swift/commit/7b323a8460540bbb9e9234ef3e3fb27f7cb117e3">more</a> <a href="https://github.com/apple/swift/commit/0bfacde2420937bfb6e0e1be6567b0e90ee2fb67">radars</a>.</p>
<p><a href="https://github.com/dduan">Daniel Duan</a> submitted a <a href="https://github.com/apple/swift/pull/419">pull request</a> to optimize the <code class="language-plaintext highlighter-rouge">Set</code> collection type. The result is roughly a 42 percent speed improvement. <a href="https://github.com/apple/swift/pull/419#issuecomment-164109613">Whoa!</a></p>
<p><a href="https://twitter.com/practicalswift">@PracticalSwift</a> fixed <a href="https://github.com/apple/swift/pull/561">a ton</a> of <a href="https://github.com/apple/swift/pull/526">typos</a>. 😂</p>
<p>William Dillon <a href="https://github.com/apple/swift/pull/439">began support</a> for ARMv7 hosts such as the Raspberry Pi, BeagleBone, and Nvidia Tegras.</p>
<p>Brian Gesiak <a href="https://github.com/apple/swift-corelibs-xctest/pull/14">continued to pursue</a> testing the XCTest framework, and in terms of number of commits, he is now the <a href="https://github.com/apple/swift-corelibs-xctest/graphs/contributors">#3 contributor</a> on corelibs-xctest. 👏</p>
<h3 id="proposals">Proposals</h3>
<p>The first independent Swift language evolution proposal has been <a href="https://twitter.com/clattner_llvm/status/676472122437271552">accepted</a>! You can say goodbye to <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md">C-style for-loops</a> and say thank you to <a href="https://twitter.com/ericasadun">Erica Sadun</a>. Beginning in Swift 2.2, you’ll see warning if you use a C-style for-loop and it will be removed in the 3.0 release. <em>“For the most part, there was agreement that C-style for loops are quite rare in Swift code, and most of the existing uses would be better written as for-in loops.”</em> Also be sure to note the two potential problems with this change as described in the <a href="https://lists.swift.org/pipermail/swift-evolution-announce/2015-December/000001.html">announcement</a>.</p>
<p><a href="https://github.com/mxcl">Max Howell</a>, <a href="https://github.com/ddunbar">Daniel Dunbar</a>, and <a href="https://github.com/mattt">Mattt Thompson</a> have prepared <a href="https://github.com/apple/swift-evolution/pull/51">a proposal</a> to add testing support to the <a href="https://github.com/apple/swift-package-manager">Swift package manager</a>! <em>“Testing is an essential part of modern software development. Tight integration of testing into the Swift Package Manager will help ensure a stable and reliable packaging ecosystem. We propose to extend our conventional package directory layout to accommodate test modules.”</em> 🎉</p>
<p>Max Moiseev’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0014-constrained-AnySequence.md">proposal</a> to constrain <code class="language-plaintext highlighter-rouge">AnySequence.init</code> is due for review this week. I don’t see any reason why this would not be accepted. <em>“These constraints, in fact, should be applied to <code class="language-plaintext highlighter-rouge">SequenceType</code> protocol itself (although, that is not currently possible), as we expect every <code class="language-plaintext highlighter-rouge">SequenceType</code> implementation to satisfy them already.”</em></p>
<p>David Hart’s <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0009-require-self-for-accessing-instance-members.md">proposal</a> to require <code class="language-plaintext highlighter-rouge">self</code> for accessing instance members is currently under review. If you haven’t been following along, this would make <code class="language-plaintext highlighter-rouge">self</code> <em>always required</em> even when it can be inferred implicitly. For example, using <code class="language-plaintext highlighter-rouge">self.view</code> versus simply <code class="language-plaintext highlighter-rouge">view</code>. There’s a ton of discussion on the <a href="(https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002407.html)">mailing list</a> and <a href="https://twitter.com/ashfurrow/status/676881928168017921">twitter</a>. I’m not a fan, but I can understand some of the arguments to do this.</p>
<p>Erica Sadun also has a <a href="http://ericasadun.com/2015/12/16/the-evolution-will-be-televised-current-and-upcoming-proposal-reviews/">great post</a> detailing some of the recent proposals.</p>
<h3 id="mailing-lists">Mailing lists</h3>
<p>There’s <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html">an interesting thread</a> on dynamic versus static method dispatch. From Chris Lattner: <em>“TL;DR: What I’m really getting at is that the old static vs dynamic trope is at the very least only half of the story. You really need to include the compilation model and thus the resultant programmer model into the story, and the programmer model is what really matters.”</em></p>
<p>Fabian Ehrentraud started a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001054.html">discussion</a> around improving crash-safety when importing Objective-C code without nullability attributes. Currently, un-annotated Objective-C members are bridged to Swift as implicitly unwrapped optionals (e.g., <code class="language-plaintext highlighter-rouge">view!</code>). This proposal suggests importing these members as optionals (<code class="language-plaintext highlighter-rouge">view?</code>) instead, which would encourage clients to handle possible <code class="language-plaintext highlighter-rouge">nil</code> values safely. Sounds great to me. Honestly, I’m not sure why implicitly unwrapped optionals exist to begin with, as they seem contrary to Swift’s safety goals.</p>
<p>Colin Cornaby <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002324.html">suggested</a> removing semi-colons completely from Swift following the trend of removing C-style language features. As noted on the mailing list, while semi-colons are often syntactic noise, they do serve a stylistic purpose for grouping similar statements on the same line. I could go either way on this, but it doesn’t seem like the idea is gaining enough traction to warrant a formal proposal.</p>
<blockquote>
<p>Stare long enough into the language design, and the language design stares back into you.</p>
<footer><a href="https://twitter.com/jckarter/status/676939142790569986" target="_blank">Joe Groff</a></footer>
</blockquote>
<p><strong>That’s it for this week!</strong> Stay tuned. And if you have suggestions for the next brief, <a href="https://twitter.com/jesse_squires">send me a link</a>.</p>
<!-- Note, this is a legacy include -->
<div class="alert alert-info">
<p><strong>Note:</strong> This issue was originally published at <a href="http://www.jessesquires.com/open-source-swift-weekly-2/" class="alert-link" target="_blank">jessesquires.com</a></p>
</div>
Issue #1
https://swiftweeklybrief.com/issue-1
2015-12-10T00:00:00-08:00
2015-12-10T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>It looks many developers in the community enjoyed my <a href="http://www.jessesquires.com/swift-open-source/">previous post</a> detailing my thoughts and observations on the activity around the <a href="https://swift.org">Swift open source project</a>. So, I’m going to try to do this weekly — every Thursday, since the open source announcement was on a Thursday. Each week I’ll provide a high-level summary of what’s been happening, updates on interesting statistics, and links to interesting content. If you have any suggestions, please <a href="https://twitter.com/jesse_squires">let me know</a>! And now, the weekly brief!</p>
<!--excerpt-->
<h3 id="this-week-on-swiftorg">This week on Swift.org</h3>
<ul>
<li>
<p><a href="https://twitter.com/ManavGabhawala">Manav Gabhawala</a> submitted an <a href="https://github.com/apple/swift-evolution/pull/37">interesting proposal</a> to add implicit initializers to Swift. In particular, this would address the verbosity of converting between number types. However, as pointed out on the <a href="https://lists.swift.org/pipermail/swift-evolution/2015-December/000352.html">mailing list discussion</a> there are safety and precision concerns.</p>
</li>
<li>
<p><a href="https://twitter.com/1101_debian">Alex Denisov</a> submitted a <a href="https://github.com/apple/swift/pull/295">pull request</a> that fixes 323 crashes. 😲</p>
</li>
<li>
<p>Not very good at <a href="https://github.com/apple/swift-evolution/pull/39">using git</a>? Worry not! Lots of <a href="https://github.com/apple/swift-evolution/pull/34#issuecomment-162693826">cool people</a> aren’t that great at using it either. The message here: do not let this deter you from contributing!</p>
</li>
<li>
<p>Chris Lattner tends to <a href="https://github.com/apple/swift/commit/4ebb461d634964f0399d63b3264d4090451c77fd">fix</a> <a href="https://github.com/apple/swift/commit/5dded3f3523e9bd6ea45d0b6ffe5068a59d03a3f">radars</a> late at night.</p>
</li>
<li>
<p><a href="https://twitter.com/modocache">Brian Gesiak</a>, creator of <a href="https://github.com/Quick/Quick">Quick</a>, asks <a href="https://lists.swift.org/pipermail/swift-corelibs-dev/2015-December/000018.html"><em>who tests the tests?</em></a> after noticing that the <a href="https://github.com/apple/swift-corelibs-xctest">xctest</a> framework isn’t itself tested. Testing a testing framework sounds funny, but some important <a href="https://github.com/apple/swift-corelibs-xctest/commit/ce4c98bc58763d49db474703d005ba9c479cac3a">bugs</a> have already been found. <a href="https://github.com/apple/swift/blob/b53ff3b58053407f380d09770d2e2069e02d6ff5/utils/build-script-impl#L1957">FIXME</a>. 😳</p>
</li>
<li>
<p>In case you missed it, currying <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0002-remove-currying.md">will be removed</a> from Swift 3.0. (<a href="https://robots.thoughtbot.com/introduction-to-function-currying-in-swift">What is currying</a>?)</p>
</li>
<li>
<p><a href="https://twitter.com/owensd">David Owens</a> submitted a <a href="https://github.com/apple/swift-evolution/pull/26">proposal</a> to add type annotations to <code class="language-plaintext highlighter-rouge">throws</code>. When Swift’s error-handling model was first announced, the lack of explicit error types was a common criticism. There’s a <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001117.html">good discussion</a> on the mailing list. You can also read the original <a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst">Error Handling Rationale and Proposal</a>.</p>
</li>
<li>
<p>Swift now has almost 200 <a href="https://github.com/apple/swift/graphs/contributors">contributors</a> and over 230 pull requests have been <a href="https://github.com/apple/swift/pulls?utf8=✓&q=is%3Apr+is%3Amerged+">merged</a>.</p>
</li>
<li>
<p>Last week I mentioned that <a href="https://github.com/apple/swift-corelibs-foundation">Foundation</a> was largely <a href="https://github.com/apple/swift-corelibs-foundation/search?utf8=✓&q=NSUnimplemented">unimplemented</a>. There’s also some <em>really</em> surprising <a href="https://github.com/apple/swift-corelibs-foundation/pull/89/files">bugs</a>.</p>
</li>
<li>
<p><a href="https://github.com/argon">Andrew Naylor</a> ambitiously implements <a href="https://github.com/apple/swift-corelibs-foundation/pull/54">NSJSONSerialization</a>. 👏</p>
</li>
<li>
<p><a href="https://twitter.com/jtbandes">Jacob Bandes-Storch</a> submitted a <a href="https://github.com/apple/swift-evolution/pull/44">proposal</a> that aims to greatly improve the bridging of C APIs.</p>
</li>
<li>
<p>There’s an <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000873.html">interesting discussion</a> on the mailing lists to make classes and methods <code class="language-plaintext highlighter-rouge">final</code> by default. Anything that discourages or prevents subclassing is <a href="https://twitter.com/jesse_squires/status/664588682997964800">fine by me</a>. 😊</p>
</li>
<li>
<p>The Swift Programming Language iBook (ePub) is available for <em>direct download</em> on Swift.org (instead of only the iBook Store) and is now under a <a href="https://swift.org/documentation/">Creative Commons Attribution 4.0 International (CC BY 4.0) License</a>! Translations <a href="https://twitter.com/clattner_llvm/status/674454905449373696">would be great</a>.</p>
</li>
<li>
<p>Programming is little more than a <a href="https://twitter.com/clattner_llvm/status/674254974629502976">“nights and weekends” hobby</a> for Chris Lattner. 😂</p>
</li>
</ul>
<p><strong>That’s it for this week!</strong> <a href="http://jessesquires.com/feed.xml">Subscribe</a> or <a href="https://twitter.com/jesse_squires">follow me</a> to stay up-to-date!</p>
<!-- Note, this is a legacy include -->
<div class="alert alert-info">
<p><strong>Note:</strong> This issue was originally published at <a href="http://www.jessesquires.com/open-source-swift-weekly-1/" class="alert-link" target="_blank">jessesquires.com</a></p>
</div>
Issue #0
https://swiftweeklybrief.com/issue-0
2015-12-06T00:00:00-08:00
2015-12-06T00:00:00-08:00
Jesse Squires
https://twitter.com/jesse_squires
https://github.com/jessesquires.png?size=100
jesse_squires
<p>It has only been a few days since the announcement of <a href="https://developer.apple.com/swift/blog/?id=34">Swift going open source</a> and the activity around the project has been incredible. When Apple revealed that Swift would be open source at <a href="https://developer.apple.com/wwdc/">WWDC</a> earlier this year, I do not think anyone anticipated a release like this.</p>
<!--excerpt-->
<p><img class="img-thumbnail img-responsive center" src="/img/swift-logo.png" title="Swift" alt="Swift" /></p>
<h3 id="expectations">Expectations</h3>
<p>No one really knew what to expect. Was Swift going to be dumped on <a href="http://www.opensource.apple.com">opensource.apple.com</a> and grow stale with the other projects? Would it be put on GitHub like <a href="https://github.com/ResearchKit">ResearchKit</a>? Not only is Swift on <a href="https://github.com/apple/">GitHub</a>, but the Swift team will be <a href="http://arstechnica.com/apple/2015/12/craig-federighi-talks-open-source-swift-and-whats-coming-in-version-3-0/">working completely in the open</a>. Apple did a spectacular job with the release. Not only do we have the source code, but we have the <a href="https://github.com/apple/swift/commits/master">entire commit history</a> for each project, a very detailed view into the Swift team’s development process, and access to the <a href="https://github.com/apple/swift-evolution">Swift evolution process</a>. Everything you need to know is on <a href="http://swift.org">Swift.org</a>.</p>
<h3 id="swift-in-the-open">Swift in the open</h3>
<p>For the past few days I have been watching the repositories on <a href="https://github.com/apple/">GitHub</a> and the Swift <a href="https://swift.org/community/#mailing-lists">mailing lists</a>. It is fascinating. The question is, what will Swift development look like moving forward? Here are some of the interesting things I have seen so far.</p>
<ul>
<li>
<p>Chris Lattner’s <a href="https://github.com/apple/swift/commit/18844bc65229786b96b89a9fc7739c0fc897905e">first commit</a> was on July 17, 2010.</p>
</li>
<li>
<p>The main <a href="https://github.com/apple/swift">Swift repo</a> surpassed 10,000 stars in the first 24 hours. It now has more than 19,000 stars along with over 2,000 forks. As of this writing, it is still in the #1 spot on GitHub’s <a href="https://github.com/trending">trending</a> page.</p>
</li>
<li>
<p>There has been close to ~400 pull requests across all of the repos. Many of them accepted and merged.</p>
</li>
<li>
<p>After the initial Swift announcement at <a href="https://developer.apple.com/videos/play/wwdc2014-402/">WWDC 2014</a>, I think we all noticed how active the Swift team was on twitter, answering questions and more — <a href="https://twitter.com/clattner_llvm">Chris Lattner</a>, <a href="https://twitter.com/jckarter">Joe Groff</a>, and <a href="https://twitter.com/UINT_MIN">Jordan Rose</a> to name a few. Turns out some tweets <a href="https://github.com/apple/swift/commit/666646fee95bc75ca81e1dc5131989d56bfb0742">resulted</a> in <em>immediate</em> bug fixes! 😄</p>
</li>
<li>
<p>Remember that <a href="https://www.apple.com/pr/library/2014/07/15Apple-and-IBM-Forge-Global-Partnership-to-Transform-Enterprise-Mobility.html">partnership</a> with <a href="http://www.apple.com/business/mobile-enterprise-apps/">Apple and IBM</a>? Then it should not be a surprise that IBM seems to be <a href="https://developer.ibm.com/swift/2015/12/03/introducing-the-ibm-swift-sandbox/">very invested</a> in server-side Swift. It looks like there is growing momentum behind using Swift on the server.</p>
</li>
<li>
<p>Chris Lattner is <a href="https://github.com/apple/swift/pull/166">merging pull requests</a> at 10pm on Saturday. 😆</p>
</li>
<li>
<p>We know exactly <a href="https://github.com/apple/swift-evolution">what to expect</a> for Swift 3.0! No more keynote surprises.</p>
</li>
<li>
<p>The <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0004-remove-pre-post-inc-decrement.md">++ and – operators will be removed</a> from Swift 3.0. And thanks to <a href="https://twitter.com/ericasadun">Erica Sadun</a>, so will <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0007-remove-c-style-for-loops.md">C-style for-loops</a>. She submitted this proposal on day two! 👏</p>
</li>
<li>
<p>Chris Lattner <a href="https://github.com/apple/swift/commit/22c3aa0588d2df1a207dcbad85946bab7976894c">commits</a> <em>“Pull some ancient history off an internal wiki page for possible historical interest.”</em> What?! Yes please! Nerd alert.</p>
</li>
<li>
<p>The collection of <a href="https://github.com/practicalswift/swift-compiler-crashes">swift-compiler-crashes</a> from <a href="https://twitter.com/practicalswift">@practicalswift</a> has been <a href="https://github.com/apple/swift/commit/e5ca8be1a090335d401cd1d7dfcf9b2104674d5b">part of the repo</a> since September 2014.</p>
</li>
<li>
<p>It looks like there’s a <a href="https://github.com/apple/swift-evolution/pull/33/files">good chance</a> that <code class="language-plaintext highlighter-rouge">typealias</code> will be replaced with <code class="language-plaintext highlighter-rouge">associated</code> for associated type declarations.</p>
</li>
<li>
<p><a href="https://twitter.com/jtbandes">Jacob Bandes-Storch</a> has <a href="https://github.com/apple/swift/pull/253">submitted</a> <a href="https://github.com/apple/swift/pull/272">two</a> pull requests that fix a total of over 400 crashes. 😲</p>
</li>
<li>
<p>The Swift team seems <a href="https://twitter.com/clattner_llvm/status/673162286127714304">very keen</a> on getting the community involved. No contribution is too small!</p>
</li>
<li>
<p>Much of the <a href="https://github.com/apple/swift-corelibs-foundation">swift-corelibs-foundation</a> framework is currently <a href="https://github.com/apple/swift-corelibs-foundation/search?utf8=✓&q=NSUnimplemented">unimplemented</a>. There seems to be a lot of low hanging fruit. I wonder if this is intentional to encourage contributions, or if it is the result of a tight deadline?</p>
</li>
<li>
<p>The <a href="https://github.com/apple/swift/commit/afc81c1855bf711315b8e5de02db138d3d487eeb">initial checkin</a> from 2010 was actually revision 4 and imported from an internal SVN repo. “Swift SVN r4”. You will notice the following in the header comments: <em>“This source file is part of the Swift.org open source project. Copyright (c) 2014 - 2015 Apple Inc.”</em> I have three theories:
1. Commit history was edited and cleaned up before being published on GitHub.
2. In 2010, the Swift team’s deadline was “2014-2015”, <em>no matter what</em>. This seems like a very Apple thing to do and explains Swift’s “rough around the edges” arrival.
3. Chris Lattner is a wizard.</p>
</li>
</ul>
<p>I think we’re definitely off to a good start. The community is strong and excited, and Swift is <em>already</em> greatly improved in <strong>only three days</strong>. As Lattner says, <em>the revolution will be Swift!</em></p>
<p>That’s all I’ve got for now! If you enjoyed this article, <a href="https://twitter.com/jesse_squires">let me know</a>. Maybe I’ll keep creeping and sharing what I find.</p>
<!-- Note, this is a legacy include -->
<div class="alert alert-info">
<p><strong>Note:</strong> This issue was originally published at <a href="http://www.jessesquires.com/swift-open-source/" class="alert-link" target="_blank">jessesquires.com</a></p>
</div>