Protocol-oriented programming is strongly recommended in the Swift community, and Apple has given a lot of guidance on how to use it in your everyday code. However, there has not been a lot of attention on when it is not appropriate, and what to do in that case. We will explore this idea, and show that there is a completely straightforward and mechanical way to translate any protocol into a concrete datatype. Once you do this you can still write your code much like you would with protocols, but all of the complexity inherit in protocols go away. Even more amazing, a new type of composition appears that is difficult to see when dealing with only protocols. We will also demo a real life, open source library that was originally written in the protocol-oriented way, but after running into many problems with the protocols, it was rewritten entirely in this witness-oriented way. The outcome was really surprising, and really powerful. https://twitter.com/mbrandonw https://appbuilders.ch

And in Swift 5, `Error` conforms to itself so that you can have “untyped error”

In the beginning, Crusty In 2015, at WWDC, Dave Abrahams gave what I believe is still the greatest Swift talk ever given, and certainly the most …

Existentials and universals are [logical] “duals,” which means that one can be transformed into the other without losing its structure. So `AnySequence` is a universal type (generic) that’s equivalent to an explicit existential of `Sequence` (protocol). That’s why when you run into problems with protocols, your solution may be to convert it into generic structs (or vice versa). They solve the same problems in different ways with different trade-offs. And when you see “can only be used as a generic constraint,” what the compiler is really telling you is that protocols with associated types (PATs) don’t have an existential.

We could think of type-level-abstracted return types as doing the same thing but at the type level; you give a function generic arguments as inputs, and it gives a certain return type back. ​ This roughly follows the progression of `impl Trait` in Rust, where it was first introduced only for return types, then was generalized to be able to appear structurally in both argument and return types. We think this is a reasonable first step because it directly addresses the biggest functionality gap in the generics model. After that first step, there are a few fairly orthogonal language change discussions we can have, some of which are already underway

Whenever I mentally parse `protocol SomeProtocol: SomeOtherProtocol`, it’s meant to imply `SomeProtocol` adds additional requirements onto another protocol, namely `SomeOtherProtocol`’s. What’s odd about class-constraining protocols is that it’s been a weird historical inconsistency in Swift where the term to the right of the `:` _isn’t_ a protocol and instead a reserved word. All reference types implicitly conform to `AnyObject`, which, being a protocol, makes it a more consistent way of class constraining than remembering the special `: class` trick. This merging of concepts was lightly mentioned in [SE-0156](https://github.com/apple/swift-evolution/blame/93abb54833e2d9ee7ee842882f6104a867de3069/proposals/0156-subclass-existentials.md#L134) (link to specific line).

Defining an addition and multiplication doesn’t make the thing a Ring—there are axioms that need to be satisfied. Protocols are not just bags of syntax. https://t.co/pLdUxdnxR3— 🎃 Spooky ABI Stability 🎃 (@stephentyrone) March 5, 2019