atrick

~Escapable (~E) lifetime dependency compatibility with lifetime types

Today, ~E lifetimes are built on on a value dependency model. We want to migrate to a type-restricted model. A type-restricted model is essentially a generic type system for lifetimes, which I'll call "lifetime types".

Dependencies

@_lifetime(source)
func operation(source: Source) -> Dest

atrick

Lifetime Requirements

Adding a @lifetime annotation to a struct or enum declaration adds a lifetime requirement to the type:

@lifetime
struct A: ~Escapable {...}

A type declared with a lifetime requirement cannot conform to Escapable:

atrick

OSSA borrowed return values

return_borrow

Insert a return_borrow instruction for each nested borrow scope that continues past the function return:

%l = load_borrow
%b = begin_borrow %l
%e = struct_extract %l

atrick

UnsafePointer borrow semantics

Problem Statement

The most common use-case for non-Escapable adoption is to wrap an unsafe pointer in an non-Escapable and/or non-Copyable type:

@safe
struct MutRef: ~Escapable & ~Copyable {
 let _pointer: UnsafeRawPointer

atrick

Lifetime Members

Introduction

Building generic collections of non-Escapable values requires tracking multiple lifetime dependencies per value. To support this, we propose a language feature: lifetime members.

The syntax described here is provisional. The goal is to show that a simple syntax for declaring lifetime members provides sufficient information for the type checker to infer and enforce lifetime dependencies.

Proposal

atrick

Borrow accessor semantics: @dependentBorrow and C++ interop

Copyable property read semantics

We start with a container whose element may be either Copyable or Escapable, which will be determined by the calling context:

struct Container<Element: ~Escapable, ~Copyable>: ~Escapable, ~Copyable {
  let _element: Element
}

atrick

Preview of Lifetime Definitions

Preface

Lifetime definitions are an indisputably complicated feature. At least three aspects of the Swift language make the semantics challenging to express syntactically:

1. Swift lacks first-class references. This leads to a dichotomy between concrete vs. generic lifetimes. Concrete lifetimes imply a required lifetime dependence. Generic lifetimes represent potential lifetime dependence.

2. Unconditionally nonescapable types have fundamentally different lifetime constraints than conditionally escapable types, but the difference between these two flavors of lifetime dependent types is not syntactically apparent.

atrick

Property lifetimes

With ~Copyable and ~Escapable types, Swift properties can, in theory, be accessed in different ways that affect where the property value can be used. Here we describe four kinds of property access that each have different lifetime semantics. These lifetime semantics generalize to function results and coroutine yields; in this respect, there's no need to distinguish between "properties" and functions. Each kind of lifetime does, however, describe a relationship between the result and some outer value that the result is derived from. For this reason, property access is a helpful conceptual framing. This document suggests possible ways that the semantics could be expressed in the language. Our goal is not for programmers to think in terms of these four kinds of access lifetimes; natural usage of ~Copyable and ~Escapable types should lead to common-sense behavior. Instead, this formalization is meant to guide future Swift evolution proposals, which may propose some useful subsets of

atrick

Abstract Projection

Aug 2024

Concrete projection

Swift member access has projection semantics. Consider this Project wrapper, which stores its wrapped value inline as a stored property.

struct Project<T: ~Copyable>: ~Copyable {
  let value: T
}

atrick

Update to Compile-time Lifetime Dependency Annotations

The following additional sections have been added to the original pitch.

Additions to Proposed solutions

Dependent parameters

Normally, lifetime dependence is required when a nonescapable function result depends on an argument to that function. In some rare cases, however, a nonescapable function parameter may depend on another argument to that function. Consider a function with an inout parameter. The function body may reassign that parameter to a value that depends on another parameter. This is similar in principle to a result dependence.