Publish 154

Closes #500

Author: BasThomas

_drafts/2020-02-27-issue-154.md

@@ -0,0 +1,231 @@
+---
+layout: post
+title: ! 'Issue #154'
+author: btb
+sponsor:
+    link: https://nativeconnect.app
+    heading: NativeConnect is a beautiful desktop client for App Store Connect
+    body: '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 ❤️'
+    displaylink: nativeconnect.app
+---
+
+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.
+
+All in all, cool stuff going on!
+
+That said, here's what kept some other people busy these past two weeks...
+
+<!--excerpt-->
+
+{% include sponsor.html %}
+
+### Starter tasks
+
+- [SR-12247](https://bugs.swift.org/browse/SR-12247) [Compiler] Replace the
+type alias `ModuleDecl::ImportedModule` with a dedicated struct
+- [SR-12248](https://bugs.swift.org/browse/SR-12248) [TypeChecker] `<unknown>`
+diagnostic location regarding `Codable` derived conformances
+
+### News and community
+
+[Dmitri Gribenko](https://github.com/gribozavr) shared [the Swift and C++ interoperability manifesto](https://github.com/apple/swift/blob/master/docs/CppInteroperabilityManifesto.md), summarized
+possible design options of this goal.
+
+[Nate Cook](https://twitter.com/nnnnnnnn) wrote [a blog post](https://swift.org/blog/preview-package/)
+on the Swift.org blog, on the newly released Standard Library Preview Package.
+
+[Slava Pestov](https://twitter.com/slava_pestov) wrote [a blog post](https://swift.org/blog/library-evolution/)
+on the Swift.org blog, on Swift's library evolution capabilities.
+
+[Will Lisac](https://twitter.com/wlisac) open sourced [a project](https://github.com/wlisac/swift-log-slack)
+on top of `swift-log` that allows you to send logging messages to Slack.
+
+### Commits and pull requests
+
+[Max Desiatov](https://github.com/MaxDesiatov) merged [a pull request](https://github.com/apple/swift/pull/29530),
+upstreaming almost a quarter of the huge patch from the [SwiftWasm](https://github.com/swiftwasm)
+team, which brings us closer to enabling WebAssembly/[WASI](https://wasi.dev/)
+target in the compiler and running Swift code in browsers.
+
+[David Smith](https://twitter.com/Catfish_Man) merged [a pull request](https://github.com/apple/swift/pull/24303)
+that adds the new uninitialized buffer String initializer privately, improving
+its performance.
+
+[Pavel Yaskevich](https://github.com/xedin) merged [a pull request](https://github.com/apple/swift/pull/29906)
+mostly finishing the diagnostics engine rewrite, and the people working on the
+expression checker are now ready to rip out the old implementation completely!
+
+[Doug Gregor](https://twitter.com/dgregor79) merged [a pull request](https://github.com/apple/swift/pull/30045)
+to add support for patterns in "if" statements for function builders, so one
+can use `if-let`, `if-case`, etcetera.
+
+### Accepted proposals
+
+[SE-0277](https://github.com/apple/swift-evolution/blob/master/proposals/0277-float16.md): *Float16* was [accepted](https://forums.swift.org/t/accepted-se-0277-float16/34121).
+
+> The review has concluded and the proposal is accepted.
+
+[SE-0274](https://github.com/apple/swift-evolution/blob/master/proposals/0274-magic-file.md): *Concise magic file names* was [accepted](https://forums.swift.org/t/accepted-se-0274-concise-magic-file-names/34115).
+
+> The second review has concluded and the proposal has been accepted.
+>
+> - `#file` will be altered to only report the module and filename
+> - `#filePath` will be introduced to replicate the previous full file+path for
+use cases that relied on the path previously.
+- 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.
+>
+> During the second review, the format of the new `#file` 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.
+
+### Proposals in review
+
+[SE-0278](https://github.com/apple/swift-evolution/blob/master/proposals/0278-package-manager-localized-resources.md): *Package Manager Localized Resources* is [under review](https://forums.swift.org/t/se-0278-package-manager-localized-resources/33950).
+
+> This proposal builds on top of the [Package Manager Resources](0271-package-manager-resources.md) proposal to allow defining localized versions of resources in the SwiftPM manifest and have them automatically accessible at runtime using the same APIs.
+
+## Motivation
+
+> The recently accepted [Package Manager Resources](https://github.com/apple/swift-evolution/blob/master/proposals/0271-package-manager-resources.md)
+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 `Bundle` 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.
+>
+> While it is technically possible to benefit from localization today by
+setting up a resource directory structure that the `Bundle` API expects and
+specifying it with a `.copy` rule in the manifest (to have SwiftPM retain the
+structure), this comes at a cost: it bypasses any platform-custom processing
+that comes with `.process`, and doesn't allow SwiftPM to provide diagnostics
+when localized resources are mis-configured.
+>
+> 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.
+
+### Swift Forums
+
+[Saleem Abdulrasool](https://twitter.com/compnerd) shared [that Foundation's full test suite passes on Windows](https://forums.swift.org/t/swift-soars-ever-higher/34036)!
+
+> 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.
+
+[Yuta Saito](https://twitter.com/kateinoigakukun) shared [an update](https://forums.swift.org/t/wasm-support/16087/14)
+on the progress of the WebAssembly compiler target.
+
+> 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.
+>
+> Before sending them, I want to confirm and clarify the direction of
+supporting WebAssembly.
+
+[Sergej Jaskiewicz](https://twitter.com/broadway_lamb) shared [an idea](https://forums.swift.org/t/support-building-rust-targets-in-spm/33898)
+to add support for Rust targets to the Swift Package Manager.
+
+> I've just come up with this crazy idea: what if we allow SPM to build Rust
+targets?
+>
+>For now I have the following in mind:
+>
+> - Obviously, for building Rust targets the rust toolchain has to be installed.
+> - We don't use Cargo for building Rust targets, but rather invoke `rustc`
+directly. We could allow Swift packages to depend on Cargo packages in the
+future, but that seems nontrivial.
+> - 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).
+
+[Gwynne Raskind](https://twitter.com/_AngeloidBeta) pitched [a proposal](https://forums.swift.org/t/property-wrapper-requirements-in-protocols/33953)
+to add property wrapper requirements in protocols.
+
+> 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.
+>
+> We propose allowing a subset of property wrapper syntax to appear in protocol
+declarations.
+
+[Joe Groff](https://twitter.com/jckarter) shared [an update](https://forums.swift.org/t/update-on-se-0110-and-se-0155/33948)
+on SE-0110 and SE-0155.
+
+> 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:
+>
+> - [SE-0110](https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md), Distinguish between single-tuple and multiple-argument function types
+> - [SE-0155](https://github.com/apple/swift-evolution/blob/master/proposals/0155-normalize-enum-case-representation.md), Normalize Enum Case Representation
+>
+> **SE-0110**
+>
+> 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 [original proposal as reviewed](https://github.com/apple/swift-evolution/blob/9e44932452e1daead98f2bc2e58711eb489e9751/proposals/0110-distingish-single-tuple-arg.md)
+did not include the special-case conversion from `(T, U, ...) -> V` to
+`((T, U, ...)) -> V` 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.
+>
+> **SE-0155**
+>
+> 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.
+
+[Reda Lemeden](https://twitter.com/kaishin) asked [a question](https://forums.swift.org/t/swift-package-naming-conventions/33931)
+about Swift Package naming conventions.
+
+> - Some packages use dash-case (aka kebab-case). Notable examples:
+`swift-driver`, `swift-numerics`, `swift-log`, `swift-crypto`, and `swift-nio`.
+Other that fall into this group are SSWG packages and the new standard library
+preview packages.
+> - Some packages use CamelCase. Notable examples: `SwiftPM` itself,
+`SourceKitLSP`, and `SwiftSyntax`. Almost all iOS/macOS packages follow this
+convention.
+>
+> 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 `snake_cased` and
+`dash-cased` crate names are both widely used (although the latter is gaining
+more momentum).
+>
+> 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.
+>
+> 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?
+
+### Finally
+
+[~~`// FIXME`~~, oops I mean `// FORGIVE ME`](https://twitter.com/danielpunkass/status/1232650866949316608)