atrick

UniqueSpan

This pitch is an active brainstorm. It may eventually be converted into an SE proposal.

Introduction

This proposal introduces a nonescapable, noncopyable UniqueSpan<T> type. Like Span<T>, which is also nonescapable, it does not manage the underlying storage. But unlike Span<T>, it is noncopyable and takes ownership of all the elements within the span, allowing them to be moved, consumed, or replaced.

Motivation

atrick

Indefinite lifetimes

Immortal lifetimes

In some cases, a nonescapable value must be constructed without any object that can stand in as the source of a dependence. Consider extending the standard library Optional or Result types to be conditionally escapable:

enum Optional<Wrapped: ~Escapable>: ~Escapable {
  case none, some(Wrapped)
}

atrick

Using the @_unsafeNonescapableResult function attribute

Indeterminate lifetimes

In some cases, a nonescapable value must be constructed without any object that can stand in as the source of a dependence. Consider extending the standard library Optional or Result types to be conditionally escapable:

enum Optional<Wrapped: ~Escapable>: ~Escapable {
  case none, some(Wrapped)
}

atrick

Lifetime dependence with generic types

Conditionally nonescapable types

The current design of lifetimes relies on "value lifetimes" and "conditionally non-escapable types". Values of Escapable type have no lifetime scope. Values of ~Escapable type have a single lifetime scope. A nonescapable value cannot live beyond the current scope unless the scope's function interface provides value-based lifetime propagation via @dependsOn annotations.

E ≡ some T
NE ≡ some T: ~Escapable

Without a lifetime annotation, functions cannot return nonescapable values:

atrick

Language support for BufferView

Table of Contents

• Introduction
• Motivation
• Solution
• Basic (Unsafe) BufferView Implementation
• Non-copyable BufferView
• Non-copyable BufferView with 'borrowing' and 'mutating' properties

atrick

Constrain implicit raw pointer conversion to bitwise-copyable values

Introduction

This proposal adds restrictions on implicit casts to unsafe pointers. It allows implicit casts only when the source value is either "bitwise copyable" or has custom support for unsafe pointer casts. A type is bitwise copyable if copying a value of that type requires nothing more than copying each bit in its representation (i.e. memcpy). Bitwise copyable types do not require deinitialization. Notably, bitwise copyable types cannot contain object references. Raw pointers are primarily intended for use with bitwise-copyable types because it is extremely difficult and dangerous to work with raw bytes in the presence of object references.

The implicit raw pointer casts that we want to prohibit commonly happen accidentally, without any source-level indication of unsafety. They nonetheless pose a serious safety and security concern. They are a common source of programming mistakes leading to runtime crashes but have no discer

atrick

Lifetime-dependent properties

Introduction

A lifetime-dependent property (or "dependent property") is a struct or class property whose value can only be accessed within an enclosing scope, during which the parent object cannot be deinitialized. A dependent property can provide a lightweight "view" of its parent object's underlying storage through an alternate type. This proposal focuses on the problem of returning the view object as a property of its "container". The author of the view type still bears responsibility for other aspects of safety. The Future Directions sections cover additional features needed to support development of safe view types.

Motivation

A container data type often needs to provide limited access to its underlying storage to a more general purpose API that consumes the data but is otherwise independent of the data type. In Swift, this is typically done by having the container provide a "slice" that conforms to the Collection protocol. Since slices depend on their container's

atrick

Non-escaping view proposal

Introduction

A data type often needs to provide limited access to its underlying data without copying the data. That is typically done either with a "slice" that retains a reference to the original storage, or with an unsafe pointer into the storage.

Consider slicing: return array[range]

This approach is limited because slices only work safely with reference counted storage. Slices may arbitrarily extend the original lifetime, which is sometimes unacceptable. And, finally, by retaining a reference, they prevent mutation of copy-on-write containers. So slices can't be used to mutate collection types that have value semantics.

atrick

Constrain implicit raw pointer conversion to trivial values

Introduction

Swift supports implicit inout conversion to unsafe pointers. A mutable variable can be passed inout to a function that receives an unsafe pointer to the value. According to the normal rules for pointer conversion, this naturally extends to raw pointers. Raw pointers allow the pointer-taking function to operate directly on the value's bytes.

func readBytes(_ pointer: UnsafeRawPointer) {
  assert(pointer.load(as: UInt16.self) == 0xaaaa)
}

atrick

BorrowedValue pitch

Introduction

Adding control over value ownership to Swift requires the coordination of multiple language features. This proposal focuses on the specific problem of composing aggregates from "shared" values. A "shared borrow" provides read-only access to a value within a designated scope. This allows APIs to view the contents of a value without taking ownership of it.

Let's define "shared borrowing" as initializing a non-owned variable with the value from another variable without making a copy. To be concise, we'll just call this "borrowing" from here on. Consider passing an argument to a non-consuming parameter (this is the default ownership convention):

func nonConsuming<T>(t: T)