Issue 163 (#531)

Co-authored-by: Bas Broek <[email protected]>

Author: fassko

_drafts/2020-07-02-issue-163.md

@@ -0,0 +1,242 @@
+---
+layout: post
+title: ! 'Issue #163'
+author: fassko
+sponsor:
+    link: https://engineering.linecorp.com/en/
+    heading: LINE loves Swift!
+    body: 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.
+    displaylink: engineering.linecorp.com
+---
+
+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 [developer forums](https://developer.apple.com/forums/),
+as well as many community-organized side events that were not tied to any
+physical location, which is great.
+
+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.
+
+<!--excerpt-->
+
+{% include sponsor.html %}
+
+### Podcasts
+
+In the latest episode of Swift Unwrapped, [Jesse](https://twitter.com/jesse_squires)
+and [JP](https://twitter.com/simjp) talk [about](https://spec.fm/podcasts/swift-unwrapped/fxMk4ipF)
+tuples.
+
+In [episode 75](https://www.swiftbysundell.com/podcast/75/) of the Swift by
+Sundell podcast, [Dave Verwer](https://twitter.com/daveverwer) and
+[Sven A. Schmidt](https://twitter.com/_sa_s) join [John](https://twitter.com/johnsundell)
+to talk about their newly launched [Swift Package Index](https://swiftpackageindex.com/),
+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.
+
+### News and community
+
+In this year's WWDC 2020 Apple had two main sections of videos about the Swift
+language and relevant topics:
+
+* [Swift in Xcode 12](https://developer.apple.com/news/?id=4nh602ih)
+* [Swift deep dive](https://developer.apple.com/news/?id=tjv7v7k1)
+
+In addition to that, [Tom Doron](https://twitter.com/tomerdoron) presented [how
+to use Swift on AWS Lambda with Xcode](https://developer.apple.com/videos/play/wwdc2020/10644/).
+
+[Amy Tsai](https://twitter.com/mousiechika) shared awesome [sketch session notes](https://twitter.com/mousiechika/status/1275547535206166531)
+for the [Whats New In Swift](https://developer.apple.com/videos/play/wwdc2020/10170/)
+session.
+
+A great project by [Federico Zanatello](https://twitter.com/zntfdr): [WWDC Notes](https://www.wwdcnotes.com/)
+- The TL;DW for Apple's WWDC videos. You can read session notes written by the
+community.
+
+Apple released Xcode 12 and here are the [release notes](https://developer.apple.com/documentation/xcode-release-notes/xcode-12-beta-release-notes#Swift)
+of what has changed in Swift.
+
+[Cory Benfield](https://twitter.com/Lukasaoz) shared that the Swift Crypto 1.1.0
+RC1 is [available](https://github.com/apple/swift-crypto/releases/tag/1.1.0-rc.1).
+It brings the new CryptoKit APIs from Apple’s WWDC20 platforms to all other
+Swift platforms.
+
+The first release candidate of Swift for [TensorFlow v.0.10.0 is out](https://github.com/tensorflow/swift/blob/master/Installation.md#release-candidates).
+
+[Bruno Rocha](https://twitter.com/rockthebruno) wrote [a blog post](https://swiftrocks.com/benefits-of-throwing-functions-try-swift-underrated-feature)
+about the benefits of using throwing functions.
+
+[Moritz Lang](https://twitter.com/slashmodev) created [a repository](https://github.com/slashmo/awesome-swift-nio)
+listing all things SwiftNIO.
+
+[Ole Begemann](https://twitter.com/olebegemann) wrote [a blog post](https://oleb.net/2020/as/)
+explaining `as`, `as?`, and `as!`.
+
+### Commits and pull requests
+
+[Slava Pestov](https://twitter.com/slava_pestov) merged [a pull request](https://github.com/apple/swift/pull/32488)
+that fixes a bug in generic signature minimization. It [turned out](https://twitter.com/slava_pestov/status/1274914547728515072)
+that the fix didn't require a big redesign of the `GenericSignatureBuilder`
+after all. It's just a five line addition of a new `'if'` statement.
+
+[Michael Gottesman](https://github.com/gottesmm) merged [a pull request](https://github.com/apple/swift/pull/32627)
+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.
+
+Stephen Celis](https://twitter.com/stephencelis/) merged [a pull request](https://github.com/apple/swift/pull/32451)
+that improves performance of `Collection.removeFirst(_:) where Self == SubSequence`.
+You can read more about it [here](https://twitter.com/stephencelis/status/1278347623359971328).
+
+[Luciano Almeida](https://github.com/LucianoPAlmeida) merged [a pull request](https://github.com/apple/swift/pull/32376)
+that resolves [SR-5688](https://bugs.swift.org/browse/SR-5688): *Unhelpful
+diagnostic when missing a ? in a KeyPath expression*.
+
+[Mishal Shah](https://github.com/shahmishal) merged [a pull request](https://github.com/apple/swift/pull/32502) to update master branch for Xcode 12 beta.
+
+### Accepted proposals
+
+[SE-0282](https://forums.swift.org/t/se-0282-review-2-interoperability-with-the-c-atomic-operations-library/37360/12): *Interoperability with the C Atomic Operations Library* was [accepted](https://forums.swift.org/t/accepted-se-0282-interoperability-with-the-c-atomic-operations-library/38050).
+
+> This proposal does not specify whether/how dependency chains arising from the
+C/C++ `memory_order_consume` 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.
+
+### Swift Forums
+
+[Erica Sadun](https://twitter.com/ericasadun) pitched [a proposal](https://forums.swift.org/t/returning-to-an-old-hobbyhorse-migrating-higher-order-function-names-to-comply-with-api-guidelines/37728)
+to migrate higher order function names to comply with API guidelines.
+
+> 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.
+>
+> It would be simple to alias `map`, `filter`, etc with API compliant names
+(`apped`, `mapping`, `filtered`, `filtering`), 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.
+>
+> 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.
+
+[Erica Sadun](https://twitter.com/ericasadun) pitched [a proposal](https://forums.swift.org/t/extend-swiftpm-packagedescription-to-introduce-metadata/37722)
+to extend SwiftPM `PackageDescription` to introduce metadata.
+
+> A Swift Package defines the sources and dependencies for successful
+compilation. The [`PackageDescription`](https://docs.swift.org/package-manager/)
+specifies items like the supported Swift version, linker settings, and so forth.
+> 
+> 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.
+
+[Doug Gregor](https://twitter.com/dgregor79) starthed [a conversation](https://forums.swift.org/t/revisiting-the-source-compatibility-impact-of-se-0274-concise-magic-file-names/37720)
+about revisiting the source compatibility impact of [SE-0274](https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md):
+Concise magic file names.
+
+> In light of the discussion of [principles for (trailing closure) evolution
+proposals](https://forums.swift.org/t/principles-for-trailing-closure-evolution-proposals/37265)
+and based on feedback we've received from the [Swift 5.3 development snapshots](https://swift.org/download/#snapshots),
+I'd like to revisit [SE-0274: Concise magic file names](https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md).
+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.
+> 
+> SE-0247 includes an additive change (`#filePath` literal to provide the full
+path to the file), but then introduces three changes that affect existing
+sources:
+> 
+> 1. `#file` literals have a different form that does not include the full path
+name. Therefore, the spelling `#file` has changed meaning.
+> 2. The compiler provides a warning when a wrapper around a
+`#filePath`-defaulting function passes it `#file` instead, or vice versa.
+> 3. Standard library functions like `precondition` currently use `#file`, and
+therefore have had their behavior changed to no longer produce the full path
+name by default.
+
+[Tom Doron](https://forums.swift.org/u/tomerd) shared [meeting notes](https://forums.swift.org/t/june-10th-2020/37863)
+for the Swift on the Server Workgroup June 10th, 2020 meeting.
+
+[Frederick Kellison-Linn](https://twitter.com/jumhyn) shared [a proposal](https://forums.swift.org/t/compound-variable-names/37963)
+that introduces a syntax for defining function-typed variables which have
+compound names.
+
+> 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
+`func` declarations.
+
+[Shai Mishali](https://twitter.com/freak4pc) pitched [a proposal](https://forums.swift.org/t/introduce-anonymouskeypath/38080)
+to introduce `AnonymousKeyPath`.
+
+> In many challenges of API Designs, you want your consumer to provide a way to
+get/set a specific concrete type.
+> 
+> Today, a consumer can express this idea by a Key Path, a wonderful concept in
+Swift. My consumer can tell me:
+> 
+> * This is how you can get a String from MyObject (KeyPath)
+> * This is how you can mutate a String on MyObject (WritableKeyPath)
+> 
+> Commonly, though, you want to ask a consumer a different set of questions:
+> 
+> * Give me a way to retrieve a String on an arbitrary object
+> * Give me a way to mutate a String on an arbitrary object
+> 
+> While not caring what is the Root of that String, as long as you fulfil the
+concrete requirement.
+> 
+> Unfortunately, as of today there's no way to express a Key Path which isn't
+bound to a specific concrete Root.
+
+[Mattt](https://twitter.com/mattt) gave [an update](https://forums.swift.org/t/swift-package-registry-service-security/38088)
+on [a pitch](https://forums.swift.org/t/swift-package-registry-service/37219)
+for a Swift package registry service.
+
+> 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).
+> 
+> Modern information security relies on [public-key cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography)
+to verify claims of identity. Broadly speaking, there are two approaches to
+certificate trust:
+> 
+* A centralized, *hierarchical* [public-key infrastructure (PKI)](https://en.wikipedia.org/wiki/Public_key_infrastructure)
+scheme, in which [certificate authorities (CAs)](https://en.wikipedia.org/wiki/Certificate_authority)
+issue [certificates](https://en.wikipedia.org/wiki/Public_key_certificate)
+that prove the ownership of public keys. This is the approach taken by TLS,
+which is used by HTTPS.
+> * A decentralized, distributed [“web of trust”](https://en.wikipedia.org/wiki/Web_of_trust)
+whereby individuals vouch for the identity of one another by signing each
+others' keys directly. This is the approach taken by PGP.
+> 
+> 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".
+
+### Finally
+
+Finally, we [have](https://twitter.com/Valzevul/status/1275164878056103936)
+Nyan Cat in Swift. 🏳️‍🌈
+
+[Acronyms, acronyms everywhere...](https://twitter.com/jckarter/status/1275423569552400384)