Swiftweekly.github.io: [154] Issue #154 - February 27, 2020

Created on 13 Feb 2020  ·  33Comments  ·  Source: SwiftWeekly/swiftweekly.github.io

To contribute to this issue, simply leave a comment here. Please also review our contributing guidelines.

The current draft for this issue in _drafts/. If you want to contribute directly, feel free to open a pull request.

full issue notes

Most helpful comment

https://twitter.com/tkremenek/status/1229882956971294720

Swift now has Swift Package Manager packages to try out forthcoming Standard Library changes! https://swift.org/blog/preview-package/

All 33 comments

https://twitter.com/tkremenek/status/1227980480026312704

A great writeup from @slava_pestov on Swift's library evolution capabilities: https://swift.org/blog/library-evolution/

apple/swift#29530 was merged to Swift master that upstreams almost a quarter of the huge patch apple/swift#24684 from the SwiftWasm team, which brings us closer to enabling WebAssembly/WASI target in the compiler and running Swift code in browsers.

Lifting the 1 variadic param per function restriction

I've got a quick pitch here on lifting the restriction that each function can only have a single variadic param, inspired by a conversation started by @anandabits on twitter. It turns out this restriction is now easy to lift, so without further ado:

Functions with Multiple Variadic Parameters
Implementation: apple/swift#29735

Introduction
Currently, variadic function parameters in Swift have two main restrictions:

  • Only one variadic parameter is allowed per function
  • If present, the parameter which follows a variadic parameter must be labeled
    This proposal seeks to remove the first restriction while leaving the second in place, allowing a function to have multiple variadic parameters so long as every parameter which follows a variadic one has a label.

https://forums.swift.org/t/lifting-the-1-variadic-param-per-function-restriction/33787

I released a new logging backend for SwiftLog that could make a fun / lightweight addition to this week's newsletter 😊

https://twitter.com/wlisac/status/1229108200131031040

[Manifesto] Interoperability between Swift and C++

Interoperability between Swift and C++ has been previously discussed on the forums ([1], [2], [3]). The Swift for Tensorflow project has already started to build it out under the hidden -enable-cxx-interop flag. I have been trying to understand what interop will look like across all C++ features. I have summarized possible design options in a manifesto: Interoperability between Swift and C++.

It is not a fully finalized design: many sections list multiple alternative options that we should discuss and evaluate their pros and cons. Some sections are missing, notably, calling Swift from C++. Nevertheless, this manifesto covers enough ground to show what Swift/C++ interop could look like, what will work well, and where the rough edges are.

https://forums.swift.org/t/manifesto-interoperability-between-swift-and-c/33874

And Survey:

https://forums.swift.org/t/swift-c-user-survey-how-would-you-use-c-interoperability/33875

CVE-2019-15605: SwiftNIO: HTTP request smuggling using malformed Transfer-Encoding header

SwiftNIO before 2.13.1 (and SwiftNIO 1 before 1.14.2) are vulnerable to CVE-2019-15605: HTTP request smuggling using malformed Transfer-Encoding header.

Please make sure you immediately upgrade to SwiftNIO >= 2.13.1 (or >= 1.14.2 for SwiftNIO 1)

https://forums.swift.org/t/cve-2019-15605-swiftnio-http-request-smuggling-using-malformed-transfer-encoding-header/33876

@kateinoigakukun has posted here a quite detailed update on the progress of the WebAssembly compiler target:

https://forums.swift.org/t/wasm-support/16087/14

Support building Rust targets in SPM?

Swift Package Manager already supports building Swift, C, C++ and assembly code.

I've just come up with this crazy idea: what if we allow SPM to build Rust targets?

https://forums.swift.org/t/support-building-rust-targets-in-spm/33898

https://twitter.com/slava_pestov/status/1229863852411629568

This is incredible. The diagnostics engine rewrite is in a sense now “done”, and the expression checker folks are now ready to rip out the old implementation completely: https://github.com/apple/swift/pull/29906

https://twitter.com/tkremenek/status/1229882956971294720

Swift now has Swift Package Manager packages to try out forthcoming Standard Library changes! https://swift.org/blog/preview-package/

Introducing HypertextLiteral: a Swift package for generating HTML, XML, and other web content using string literal interpolation.

https://github.com/NSHipster/HypertextLiteral

🧵⬇️ https://twitter.com/mattt/status/1230203404066013184/photo/1

https://twitter.com/mattt/status/1230203404066013184

Property wrapper requirements in protocols

Introduction
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.

https://forums.swift.org/t/property-wrapper-requirements-in-protocols/33953

Improve nested functions’ visibility or order-dependency

There is a similar pitch from 2017, but it was only about nested functions calling each other.

https://forums.swift.org/t/improve-nested-functions-visibility-or-order-dependency/33935

SE-0278: Package Manager Localized Resources

The review of SE-0278 “Package Manager Localized Resources" begins now and runs through February 26, 2020.

https://forums.swift.org/t/se-0278-package-manager-localized-resources/33950

Update on SE-0110 and SE-0155

Hi everyone. 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, Distinguish between single-tuple and multiple-argument function types
  • SE-0155, Normalize Enum Case Representation
    SE-0110 Distinguish between single-tuple

https://forums.swift.org/t/update-on-se-0110-and-se-0155/33948

StrideTo/Through public properties

Introduction
The StrideTo and StrideThrough types in the standard library have non-public properties _start, _end, and _stride. This proposal introduces public read-only computed properties for them, without the underscores.

Motivation
When working with Stride* instances, it can be useful to access their bounds and stride.

Proposed solution
Add public read-only properties start, end, and stride to the StrideTo and StrideThrough types.

https://forums.swift.org/t/strideto-through-public-properties/33942

Swift Package Naming Conventions

_I spent some time asking package maintainers and searching these forums, but I didn't find a satisfactory answer to my question: are there any package naming conventions/guidelines for SPM packages?_

Some background:

As someone who values consistency, I've been paying closer attention to how package authors name their packages in the manifest. I've looked at official packages, SSWG packages, iOS/macOS packages, etc. To clarify, I am referring to the name property of the Package, not products or targets.

https://forums.swift.org/t/swift-package-naming-conventions/33931

Should weak be a type?

I don't see any of the above as a problem when that's what you want, and you can already accomplish this with a trivial wrapper struct. But what the current design of weak accomplishes, as a declaration modifier, is what I believe most people want most of the time with with a weak reference: store it weak in a given place, but convert it to a strong reference any time you want to use it.

https://forums.swift.org/t/should-weak-be-a-type/34032

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.

Adding defaultValue method to Optional

This is a quick pitch without a formal proposal yet. We can always flesh that out later depending on the feedback.

I'm wondering if the Swift community would like to add such a convenience method to Optional or discard the idea.

I personally do not have many strong motivation cases and therefore encourage you to share if your code base contains a similar extension.

https://forums.swift.org/t/adding-defaultvalue-method-to-optional/34048/3

Add support for Encoding and Decoding nested JSON keys

Introduction
Today, decoding JSON using JSONDecoder with a synthesized Codable implemenation requires that your object graph has a one-to-one mapping to the object graph of the source JSON. This decreases the control that authors have over their Codable models, and can require the creation of unnecessary boilerplate objects.

I propose that we add support for Encoding and Decoding nested JSON keys using dot notation.

A previous Swift-evolution thread on this topic: Support nested custom CodingKeys for Codable types

https://forums.swift.org/t/add-support-for-encoding-and-decoding-nested-json-keys/34039

https://twitter.com/johannesweiss/status/1232330831760437248

Major milestone for AsyncHTTPClient: The HTTP/1.1 connection pool got merged 🎉. Thanks so much for all the hard work @adtrevor ! All users, you may want to give it a spin before we'll release it in 1.2.0 fairly soon. If you see any issues, please file 🚀 https://github.com/swift-server/async-http-client/pull/105

https://twitter.com/dgregor79/status/1232362285009600512

SwiftLang function builders get support for patterns in "if" statements, so on can use if-let/if-case/etc: https://github.com/apple/swift/pull/30045

[Accepted] SE-0277: Float16

The review of SE-0277 — Float16 has concluded and the proposal is accepted

https://forums.swift.org/t/accepted-se-0277-float16/34121

Accepted] SE-0274: Concise Magic File Names

The second review of SE-0274 has concluded and the proposal has been accepted

https://forums.swift.org/t/accepted-se-0274-concise-magic-file-names/34115

https://twitter.com/Catfish_Man/status/1233089913546895360

Performance at the level I work on it is mostly about removing work (laziness, fast paths, removing allocations, copies, refcounting, and stack frames), but beyond that things get weird and interesting. @stephentyrone has a fun analysis of one case here https://forums.swift.org/t/two-questions-about-pointers-and-performance/34133/6?u=david_smith

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jessesquires picture jessesquires  ·  4Comments

jonniedarko picture jonniedarko  ·  3Comments

BasThomas picture BasThomas  ·  4Comments

jessesquires picture jessesquires  ·  8Comments

jessesquires picture jessesquires  ·  9Comments