Lifetime Dependency Annotations for Non-escapable Types by tbkka · Pull Request #2305 · swiftlang/swift-evolution

tbkka · 2024-02-05T22:14:10Z

This is a companion proposal to "Non-Escapable Types".

It proposes a set of annotations that can be used to relate the lifetimes of two objects. For example, this can be used to ensure that a "slice" or "iterator" object that holds a pointer into some container does not outlive the container.

…rences

tbkka · 2024-03-21T15:52:35Z

Overhauled to reflect a fundamentally different syntax. We now have a single @dependsOn(arg) marker that simply states the fact of the dependency rather than a set of borrow/mutate/consume/copy markers that state the type. This follows from conversation about the previous proposal: Since there is almost always only one type of dependency possible for any given function signature, we can simplify the syntax. This should also help users of libraries that expose nonescapable types: those users only need to know what values have dependencies; they generally do not need to be aware of the precise semantics underlying that dependency.

We need to separate description of the dependency itself -- which places a bound on when particular objects can be destroyed -- from the syntax. In particular, the syntax specifies a relationship between two objects, but that relationship is not always a lifetime dependency itself (because of "copied" dependencies).

… pitch Pitch - swiftlang/swift-evolution#2305 Changes highlights: dependsOn(paramName) and dependsOn(scoped argName) syntax dependsOn(paramName) -> copy lifetime dependence for all parameters/self except when we have Escapable parameters/self, we assign scope lifetime dependence. Allow lifetime dependence on parameters without ownership modifier. Always infer copy lifetime dependence except when we have Escapable parameters/self, we infer scope lifetime dependence. Allow lifetime dependence inference on parameters without ownership modifier.

to disable lifetime dependence checking

The examples all refer to a `span()` function. This is unimplementable for `Array` because it might not have contiguous storage. An `Array` span requires a `_read` accessor because we need to create a temporary copy of the Array when it is discontiguous. But we can't talk about `_read` here because it hasn't been proposed yet.

Lifetime dependency

Fix a grammar typo.

vsapsai · 2024-06-20T04:53:58Z

+If a function takes a nonescapable 'inout' argument, it may only reassign that argument if it is marked dependent on another function argument that provies the source of the dependence.
+
+```swift
+func reassignWithArgDependence(_ span: dependsOn(arg) inout ContiguousArray<Int>, _ arg: ContiguousArray<Int>) {


Suggested change

func reassignWithArgDependence(_ span: dependsOn(arg) inout ContiguousArray<Int>, _ arg: ContiguousArray<Int>) {

func reassignWithArgDependence(_ span: dependsOn(arg) inout Span<Int>, _ arg: ContiguousArray<Int>) {

Update the free-standing function inference rules.

Added future directions: Function type syntax and closures

Add an alternative spelling: `lifetime` vs. `dependsOn`.

This section was a distraction. Changing the position of `dependsOn` for initializers is not something we need to consider initially.

Added the same-type inference rule.

@Lifetime

@Lifetime annotation + simplified implicit lifetime dependencies

To clarify that the annotation refers to the parameter name, not the label.

Fix inference rules to be sequenced.

Update Future Direction: Lifetime dependence for closures

lorentey · 2024-07-23T01:13:04Z

+Here's one way such a value might be produced:
+
+```swift
+func mutatingSpan(to: inout ContiguousArray, count: Int) -> dependsOn(to) MutatingSpan<Element> {


Nit: to is not a good name for a parameter in Swift; this greatly interferes with readability.

Suggested change

func mutatingSpan(to: inout ContiguousArray, count: Int) -> dependsOn(to) MutatingSpan<Element> {

func mutatingSpan(to target: inout ContiguousArray, count: Int) -> dependsOn(target) MutatingSpan<Element> {

lorentey · 2024-07-23T01:13:21Z

+```
+
+We’ve written this example as a free function rather than as a method to show how this annotation syntax can be used to express constraints that apply to a particular argument.
+The `dependsOn(to)` annotation indicates that the returned value depends on the argument named `to`.


Suggested change

The `dependsOn(to)` annotation indicates that the returned value depends on the argument named `to`.

The `dependsOn(target)` annotation indicates that the returned value depends on the argument named `target`.

clintonpi · 2026-03-18T16:00:24Z

Canonical: #3145

tbkka added 4 commits January 24, 2024 18:16

First full draft.

7e767dc

Whitespace cleanup

243e33b

Fix formatting

b30308d

Future direction: Lifetime dependencies between arguments

ccc54d9

tbkka changed the title ~~Tbkka lifetime dependency~~ Lifetime Dependency Annotations for Non-escapable Types Feb 5, 2024

tbkka mentioned this pull request Feb 5, 2024

Non-Escapable Types #2304

Merged

Link to pitch thread

2992389

glessard mentioned this pull request Feb 6, 2024

Safe Access to Contiguous Storage #2307

Merged

tbkka added 5 commits February 7, 2024 15:41

New examples for Future Directions

ba3946c

Match the implementation: Use local parameter names for argument refe…

0aab19d

…rences

Clarify some Alternatives and Future Directions

f9b06b7

methods are mutating, not inout

84521ca

Expand alternative syntaxes

3055bec

meg-gupta reviewed Mar 20, 2024

View reviewed changes

Overhaul to adopt the new @dependsOn() syntax

78d07f2