Advanced Swift: Generics and Protocols · Generic Constraints | raywenderlich.com

rayfix · April 9, 2019, 4:41pm

This is a companion discussion topic for the original entry at https://www.raywenderlich.com/1940187-advanced-swift-generics-and-protocols/lessons/3

chizcake · April 10, 2019, 11:08pm

Doesn’t Swift compiler inline + function in compile time automatically if it’s possible? Do we have to use the keyword @inlinable explicitly to make the + function inlined in our method block?

rayfix · April 12, 2019, 9:03pm

Good point! Yes it does if it is within the module and you are using whole module optimization. If you are outside the module it will hide the implementation. If you want to build a framework that can ship separately, and performance is critical, you will want to use the @inlinable attribute.

This might be interesting to you for more background:

github.com

apple/swift-evolution/blob/main/proposals/0193-cross-module-inlining-and-specialization.md

# Cross-module inlining and specialization

* Proposal: [SE-0193](0193-cross-module-inlining-and-specialization.md)
* Author: [Slava Pestov](https://github.com/slavapestov)
* Review Manager: [Ted Kremenek](https://github.com/tkremenek)
* Status:  **Implemented (Swift 4.2)**
* Evolution review thread: [https://forums.swift.org/t/se-0193-cross-module-inlining-and-specialization/7310](https://forums.swift.org/t/se-0193-cross-module-inlining-and-specialization/7310)
* Implementation: [apple/swift#15787](https://github.com/apple/swift/pull/15787)

## Introduction

We propose introducing a pair of new attributes, `@inlinable` and `@usableFromInline`. The `@inlinable` 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 `@usableFromInline` attribute marks an internal declaration as being part of the binary interface of a module, allowing it to be used from `@inlinable` code without exposing it as part of the module's source interface.

## Motivation

One of the top priorities of the Swift 5 release is a design and implementation of _the Swift ABI_. This effort consists of three major tasks:

* Finalizing the low-level function calling convention, layout of data types, and various runtime data structures. The goal here is to maintain compatibility across compiler versions, ensuring that we can continue to make improvements to the Swift compiler without breaking binaries built with an older version of the compiler.

* Implementing support for _library evolution_, or the ability to make certain source-compatible changes, without breaking binary compatibility. Examples of source-compatible changes we are considering include adding new stored properties to structs and classes, removing private stored properties from structs and classes, adding new public methods to a class, or adding new protocol requirements that have a default implementation. The goal here is to maintain compatibility across framework versions, ensuring that framework authors can evolve their API without breaking binaries built against an older version of the framework. For more information about the resilience model, see the

This file has been truncated. show original

rodurtschark · June 16, 2019, 8:52pm

What is a “witness table”. I heard you mention it around 2:04.
“It can use this witness table to call the plus operation.”

rayfix · June 17, 2019, 2:12pm

Great question. There was some last minute reorganization and this explanation sort of got lost. You can check out the protocol oriented program course for some info on witness tables but let me go ahead and explain it here. You might be familiar with virtual tables for classes. These are like a table of function pointers that get passed around with an object. This virtual table is used to call the right overridden method for an object. When you create a protocol, a “witness table” is created which has the functions for the conforming type. When you pass a type with a constraint, the “witness” for this constraint is passed behind the scenes. Each constraint corresponds to a behind the scenes witness table being passed so that the compiler can write a version of the function that knows nothing about the type. The compiler can also write specialized versions that don’t use witness table dispatch but statically bake in the call for speed.