# \[Pitch\] Non-Escapable Types and Lifetime Dependency

**URL:** <https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865>\
**Category:** Pitches\
**Created:** [February 6, 2024, 12:52am UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865 "2024-02-06T00:52:52Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 6, 2024, 12:52am UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/1 "2024-02-06T00:52:52Z")

</div>

We would like to propose [adding a new type constraint `~Escapable`](https://github.com/apple/swift-evolution/pull/2304) for types that can be locally copied but cannot be assigned or transferred outside of the immediate context. This complements the `~Copyable` types added with [SE-0390](https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md) by introducing another set of compile-time-enforced lifetime controls that can be used for safe, highly-performant APIs.

In addition, these types will support [lifetime-dependency constraints](https://github.com/apple/swift-evolution/pull/2305) that allow them to safely hold pointers referring to data stored in other objects.

### Motivation

The design was motivated by ongoing work to provide a safe version of Swift's current `UnsafeBufferPointer`. This would take the form of a new type that we are currently referring to as `StorageView`. This new type would store a pointer and size to contiguously stored data, providing the same high performance and universal applicability as `UnsafeBufferPointer`. For example, it could be used to write concrete implementations of parsing and other services that work well regardless of whether the underlying data was being stored in a Foundation `Data` value, a Swift Standard Library `Array<T>`, or some other data structure.

However, unlike `UnsafeBufferPointer`, this new type would be entirely safe to use. This requires a number of properties:

- It should allow copying. For example, a common scenario might involve shrinking the view as data is consumed, and making copies at key points in order to easily revert to an earlier state. In particular, this new "non-escapable" concept is fundamentally different from the "non-copyable" concept that was added to Swift last year (and which is still being expanded and developed).
- It should not escape the local context. We want to forbid storing this in a global or static variable, for instance. This restriction also helps improve performance: "escape analysis" can be done entirely at compile time, avoiding any need for runtime checks.
- It should be possible to link the lifetime of this "view object" to the lifetime of the container that provided it.

We believe this `~Escapable` (non-escapable) concept will prove to be useful in many other contexts, so we're proposing it as a general addition to the core Swift language.

### Our Proposal

The full details are in the two linked proposals, so I'll just provide a couple of quick examples here.

The recently-proposed `StorageView<T>` type will provide a non-escapable reference to contiguously-stored typed data. In simplified form, it looks like this:

```swift
// A non-escapable reference to contiguously-stored typed data
struct StorageView<T>: ~Escapable {
  private base: UnsafePointer<T>
  private count: Int
}

```

We can then extend the `Array` type (among others) to provide a `StorageView` of its contents. The `borrow(self)` notation here indicates that the return value has logically "borrowed" the contents of the array. The `StorageView` value will maintain read access to those contents until it is destroyed. As a result, the compiler will ensure that the `StorageView` value cannot outlive the `Array`, and that the `Array` is not mutated during that period of time:

```swift
extension Array {
  borrowing func storageView() -> borrow(self) StorageView<Element> {
    ... construct a StorageView ...
  }
}

```

Since any data type that stores contiguous data can provide this view, it forms a universal "currency type" for working with contiguous data. In particular, this enables the following idiom, which uses a very thin inlineable generic adapter to provide a flexible API while maintaining an efficient concrete ABI to the core logic.

```swift
@inlineable
func parse<T: StorageViewable>(_ store: T) {
  return parse(storageView: store.storageView())
}

// A fully concrete implementation of the core parsing logic
func parse(storageView: StorageView<UInt8>) {
   ... fast concrete implementation ...
}

```

We've split the non-escapable types proposal into two parts:

[**Non-Escapable Types**](https://github.com/apple/swift-evolution/pull/2304) provides the basic definition of the proposed `~Escapable` type constraint.

[**Lifetime Dependency Annotations for Non-escapable Types**](https://github.com/apple/swift-evolution/pull/2305) describes a set of lifetime annotations that can be used to link the lifetime of a particular `~Escapable` value to some other value.

In addition, the [`StorageView` pitch](https://forums.swift.org/t/pitch-safe-access-to-contiguous-storage/69888) describes how this can be used to provide safe, performant access to a wide variety of containers.

### Related Discussions

- [SE-0390: Non-copyable types](https://github.com/apple/swift-evolution/blob/main/proposals/0390-noncopyable-structs-and-enums.md)
- [Vision: Language Support for BufferView](https://forums.swift.org/t/roadmap-language-support-for-bufferview/66211)
- [Roadmap for improving Swift Performance Predictability](https://forums.swift.org/t/a-roadmap-for-improving-swift-performance-predictability-arc-improvements-and-ownership-control/54206)

**Edited:** Changed `BufferView` to `StorageView` to match the [recently-posted pitch](https://forums.swift.org/t/pitch-safe-access-to-contiguous-storage/69888).

---

<div class="post-metadata">

**Author:** ![kabiroberai](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/kabiroberai/32/28072_2.png) [@kabiroberai](https://forums.swift.org/u/kabiroberai)\
**Post date:** [February 6, 2024, 7:50am UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/2 "2024-02-06T07:50:43Z")

</div>

This is pretty exciting! It's great to see Swift getting as expressive as Rust (or even Objective-C, cf `NS_RETURNS_INNER_POINTER` 😄) with lifetimes, without compromising on progressive disclosure (in that copying/escaping/etc are still the default.) My one bit of feedback is about usability. I'm a big fan of Rust's diagnostics — it feels like a language designed for _humans_, which makes working with lifetimes so much less frustrating given I'm not an expert at Rust.

Anecdotally, it feels like so many SE proposals (such as those related to result builders and Sendability) have created incredibly powerful features, but at the cost of rather opaque errors when they don't work. I really hope that if/when this pitch turns into a full-fledged proposal and ultimately gets implemented, it comes with some great fix-its and easily understandable diagnostics. So long as that's the case, it's a +1 from me.

---

<div class="post-metadata">

**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\
**Post date:** [February 6, 2024, 8:20am UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/3 "2024-02-06T08:20:34Z")

</div>

Really excited to see this being pitched! Overall the proposal looks great. I personally would like to see the future direction around `TaskGroup`s to be considered as part of this proposal since those are the primary tools of structured concurrency and `async let`s are a used less frequently. Especially since this pitch is proposing to make `async let`s work out of the box. If we only implement `async let`s to work this will create an unfortunate situation where only the simplistic use cases can use `~Escapable` types with structured concurrency.

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [February 6, 2024, 3:40pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/4 "2024-02-06T15:40:42Z")

</div>

Glad to see this. Hopefully we'd be able to get rid of ugly and unsafe:

```swift
var data = Data()
var value: Int = 0

```

```swift
func foo() {
    data.withUnsafeBytes { a in
        withUnsafeBytes(of: &value) { b in
            bar(a, b.assumingMemoryBound(to: Int.self).baseAddress!)
        }
    }
}
func bar(_ a: UnsafePointer<UInt8>, _ b: UnsafePointer<Int>) {
    ....
    global = a // Ho-ho-ho
    global2 = b // Ho-ho-ho
}

```

and replace it with something like this which is both safe and concise:

```swift
func foo() {
    bar(data.bufferView(), value.bufferView())
}
func bar(_ a: BufferView<UInt8>, _ b: BufferView<Int>) {
    ....
    global = a // 🛑 can't do this
    global2 = b // 🛑 can't do this
}

```

---

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 6, 2024, 6:04pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/5 "2024-02-06T18:04:44Z")

</div>

> [@kabiroberai](#):
>
> Anecdotally, it feels like so many SE proposals (such as those related to result builders and Sendability) have created incredibly powerful features, but at the cost of rather opaque errors when they don't work.

Hopefully, that's only a problem initially. We work hard to improve error messages over time, as I hope you've noticed with the steady improvement in Concurrency diagnostics over the last few years.

Please file bug reports whenever you see a confusing and/or misleading error message. We really do take those very seriously.

---

<div class="post-metadata">

**Author:** ![tim1724](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tim1724/32/450_2.png) [@tim1724](https://forums.swift.org/u/tim1724)\
**Post date:** [February 6, 2024, 9:39pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/6 "2024-02-06T21:39:43Z")

</div>

I like the spelling of the lifetime constraints. It fits in well with other recently added features.

Similarly, `~Escapable` works well given the existence of `~Copyable` and feels pretty natural. It's also nice that newbies can ignore `Escapable` until they need it.

---

<div class="post-metadata">

**Author:** ![tera](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tera/32/38201_2.png) [@tera](https://forums.swift.org/u/tera)\
**Post date:** [February 6, 2024, 9:55pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/7 "2024-02-06T21:55:36Z")

</div>

Will this hold?

```swift
func foo(normalClosure: () -> Void, escapingClosure: @escaping () -> Void) {
    print(normalClosure is ~Escaping) // true
    print(escapingClosure is ~Escaping) // false
}

```

---

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 6, 2024, 10:03pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/8 "2024-02-06T22:03:30Z")

</div>

Our first goal is to make these work well for very performance-critical code. So I don't think we'll get support for dynamic type-checks (`is`, `as?`, `as!`) right away.

---

<div class="post-metadata">

**Author:** ![dmt](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/dmt/32/30830_2.png) [@dmt](https://forums.swift.org/u/dmt)\
**Post date:** [February 7, 2024, 12:32am UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/9 "2024-02-07T00:32:29Z")

</div>

Great pitch! A couple notes on the details:

1. In Lifetime Dependency Annotations there's a syntax:

2. I think this might be too complex, but I have two examples in mind that's not covered with the proposed syntax:

3. It would be nice to have a notion of non-escapeness of an escapable type. Let's say we have a class and a function:

---

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 7, 2024, 6:01pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/10 "2024-02-07T18:01:37Z")

</div>

Thanks for the thoughtful feedback! As it happens, we had already thought of most of these but I somehow failed to mention them in the proposal. Here's where I think we are today:

> [@dmt](#):
>
> As arguments can be positional and/or named the proposed syntax doesn't cover all possible cases, e.g. when two arguments have the same label

The draft proposal already supports `<lifetime-type>(number)` as a way to refer to an argument by index rather than name for precisely this reason.

> [@dmt](#):
>
> Return type is a tuple. One element is lifetime dependent from an arg, the other ones aren't. `func f(a: consume A, b: B) -> (consume(a) C, B)`

We definitely want to support this. It might not be in the initial implementation, but I suspect we'll add it fairly soon. I'll add this idea as a Future Direction so it doesn't get lost.

> [@dmt](#):
>
> Return type is a container. Let's say we want to process a big buffer in parallel, so we split it to chunks, and we don't know how many of them will be at compile time.
> 
> ```swift
> borrowing func chunks(n: Int) -> borrow(self) SomeList<borrow(self) BufferView<UInt8>>
> 
> ```

This is a more complex case that the team working on this is still debating. We have some ideas, but they will take a bit longer to work out.

> [@dmt](#):
>
> 1. It would be nice to have a notion of non-escapeness of an escapable type. ...
> 
> ```swift
> func inspect(foo: Foo) { 
> print(foo.bar)
> }
> 
> func test() {
> let foo = Foo()
> inspect(foo: foo)
> }
> 
> ```
> 
> `foo` doesn't escape from `inspect`. In some circumstances the compiler can take advantage from the fact and allocate Foo on stack.

Marking individual arguments or values as non-escaping is certainly desirable, but it's unrelated to this particular proposal. I'll add that as a Future Direction also.

---

<div class="post-metadata">

**Author:** ![rauhul](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/rauhul/32/35207_2.png) [@rauhul](https://forums.swift.org/u/rauhul)\
**Post date:** [February 7, 2024, 6:28pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/11 "2024-02-07T18:28:23Z")

</div>

I may have missed it, but do any of the proposals explain why not to use rust-style lifetime parameters? I dont necessarily think rust's model is a perfect fit, but it certainly has a _ton_ of literature that makes the model easier to learn and diverging from that model comes with an additional learning burden.

---

<div class="post-metadata">

**Author:** ![ksluder](https://avatars.discourse-cdn.com/v4/letter/k/eada6e/32.png) [@ksluder](https://forums.swift.org/u/ksluder)\
**Post date:** [February 7, 2024, 7:10pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/12 "2024-02-07T19:10:01Z")

</div>

This question seems particularly relevant since [named lifetimes have already been effectively pitched](https://forums.swift.org/t/pitch-inheriting-the-callers-actor-isolation/68391) in the form of `#isolation` default arguments.

---

<div class="post-metadata">

**Author:** ![fclout](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/fclout/32/36155_2.png) [@fclout](https://forums.swift.org/u/fclout)\
**Post date:** [February 7, 2024, 7:39pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/13 "2024-02-07T19:39:05Z")

</div>

What does the `consume` lifetime modifier do? Is it instructing the compiler that the return value steals the lifetime constraints of the consumed value, rather than putting constraints on the lifetime of the consumed value (which ended at the call site)?

How do lifetimes interact with packs? Can I write something like `repeat mutate(each Foo)`?

Is an expected result of this proposal that `with*Pointer` methods, and several other methods/functions that currently take a closure to enforce a lifetime, should be overhauled to provide mutating/borrowing versions that don't use a closure?

When a lifetime constraint is provided with a plain old copyable return type (like UnsafePointer), what happens when the value is copied?

(Edit)

Do temporaries have lifetimes? For instance, can I write `[1, 2, 3].bufferReference()`?

Can global variables have constraints put on them? Is the answer different for `let` and `var` globals? Is the answer different for copyable globals?

(End edit)

Bikeshedding: I know that `consume` is already a keyword, but I haven't followed enough to remember if `borrow` and `mutate` are. If that's not the case, to avoid creating new keywords, would we consider `consuming(param)`, `mutating(param)` and `borrowing(param)` as the function modifiers?

Bikeshedding: is ~Escapable the right spelling for this feature? We've held in the past that the protocol conformance syntax is best when there's an analogous useful protocol requirement, but the proposal doesn't show ~Escapable as a protocol requirement.

---

<div class="post-metadata">

**Author:** ![hassila](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/hassila/32/22647_2.png) [@hassila](https://forums.swift.org/u/hassila)\
**Post date:** [February 7, 2024, 7:50pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/14 "2024-02-07T19:50:34Z")

</div>

+1 on that, in fact, I don’t believe we have a single use case of async let in our code base, but quite a few task groups - but I guess it depends on the domain one works in.

---

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 7, 2024, 10:31pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/15 "2024-02-07T22:31:12Z")

</div>

> [@fclout](#):
>
> What does the `consume` lifetime modifier do? Is it instructing the compiler that the return value steals the lifetime constraints of the consumed value, rather than putting constraints on the lifetime of the consumed value (which ended at the call site)?

Yes, precisely. The `copy` modifier is similar. The key use case here is a function that takes one `BufferView` and returns another one, for example, a `dropFirst` method on `BufferView` might work this way. That way, the new view object would continue to be dependent on the lifetime of the backing container.

> [@fclout](#):
>
> How do lifetimes interact with packs? Can I write something like `repeat mutate(each Foo)`?

Good question! I'll have to check on that one.

> [@fclout](#):
>
> Is an expected result of this proposal that `with*Pointer` methods, and several other methods/functions that currently take a closure to enforce a lifetime, should be overhauled to provide mutating/borrowing versions that don't use a closure?

One of our goals here is to provide a more ergonomic way to design such APIs. As for whether any particular existing use "should" be overhauled or not -- I'll leave that to the folks who own those respective libraries. ;-)

> [@fclout](#):
>
> When a lifetime constraint is provided with a plain old copyable return type (like UnsafePointer), what happens when the value is copied?

`UnsafePointer` is Escapable, so you can't have a lifetime constraint on it. (At least, not in this proposal.) But if you had some other type that was copyable and non-escapable, copies would inherit the same lifetime constraint. So if you had a non-escapable and copyable iterator, you could make local copies of it to record a point in the iteration but could not store the original iterator or any of its copies in a global var.

> [@fclout](#):
>
> Do temporaries have lifetimes? For instance, can I write `[1, 2, 3].bufferReference()`?

I believe so. @Andrew_Trick can verify that.

> [@fclout](#):
>
> Can global variables have constraints put on them? Is the answer different for `let` and `var` globals? Is the answer different for copyable globals?

Not in this proposal.

> [@fclout](#):
>
> Bikeshedding: is ~Escapable the right spelling for this feature? We've held in the past that the protocol conformance syntax is best when there's an analogous useful protocol requirement, but the proposal doesn't show ~Escapable as a protocol requirement.

The protocol requirement is `Escapable` and `~Escapable` is the syntax for expressing that this requirement is _not_ present. (All current Swift types are implicitly Escapable.)

To understand why it's modeled this way, consider what happens to `Any`. An `Any` existential container is naturally both Copyable and Escapable: You can make as many copies as you want, store them in global variables, etc., without restriction. We can't change that. Having a protocol that expressed non-escapability would mean that an escapable container (`Any`) could carry a non-escapable payload, which is clearly a problem.

An early prototype instead used a `@nonescapable` attribute on a type, but that doesn't allow generic types to cleanly support both escapable and non-escapable objects. We really do want to expand the standard library to support things like arrays of non-escapable elements someday, and generic support is crucial for that.

---

<div class="post-metadata">

**Author:** ![fclout](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/fclout/32/36155_2.png) [@fclout](https://forums.swift.org/u/fclout)\
**Post date:** [February 7, 2024, 10:40pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/16 "2024-02-07T22:40:39Z")

</div>

I realize there's uncertainty about temporaries here, but if they can have lifetimes, it's ambiguous to me whether `array.bufferReference()` would capture `array` itself or a copy of it, and whether this is an issue that we have any way of diagnosing. I think we landed on borrowing/consuming needing a keyword for arguments, so it's less a problem with those.

---

<div class="post-metadata">

**Author:** ![Andrew\_Trick](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrew_trick/32/323_2.png) [@Andrew\_Trick](https://forums.swift.org/u/Andrew_Trick)\
**Post date:** [February 7, 2024, 11:07pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/17 "2024-02-07T23:07:51Z")

</div>

> [@fclout](#):
>
> Do temporaries have lifetimes? For instance, can I write `[1, 2, 3].bufferReference()`?

Yes, the compiler tracks the lifetime of all values of non-BitwiseCopyable type. This works:

```swift
foo([1, 2, 3].bufferReference())

```

Naïve diagnostics will error on this:

```swift
let ref = [1, 2, 3].bufferReference()
foo(ref)

```

But the diagnostics can be improved to lengthen the lifetime of the temporary array.

---

<div class="post-metadata">

**Author:** ![Andrew\_Trick](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/andrew_trick/32/323_2.png) [@Andrew\_Trick](https://forums.swift.org/u/Andrew_Trick)\
**Post date:** [February 7, 2024, 11:21pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/18 "2024-02-07T23:21:08Z")

</div>

> [@fclout](#):
>
> Bikeshedding: I know that `consume` is already a keyword, but I haven't followed enough to remember if `borrow` and `mutate` are. If that's not the case, to avoid creating new keywords, would we consider `consuming(param)`, `mutating(param)` and `borrowing(param)` as the function modifiers?

We will almost certainly have a `borrow` operator to match `consume`. The lifetime modifiers are written as if those operators are being applied to the parameter to intentionally distinguish them from the `borrowing|consuming` parameter modifiers. We also want to support borrowing return values. We don't want to use the same keyword to mean very different things that are easy to confuse:

`foo(borrowing arg) -> borrow(arg) borrowing Result`

This means that the _caller_ will automatically apply the `borrow` operator to `arg` to create a scoped access for the duration of `Result`. The _callee_ will receive a borrowed instance of `arg`, which it does not need to destroy. And the callee will return a borrowed instance of Result, which the caller does not need to destroy. Three different but related kinds of borrowing.

Another way to avoid confusion is the alternate spelling shown in the proposal  
`foo(borrowing arg) -> @dependsOn(borrow arg) borrowing Result`

> <https://github.com/swiftlang/swift-evolution/blob/2992389fa8b1465930182111f0cc080664cff8c0/proposals/NNNN-lifetime-dependency.md#different-spellings>

---

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 7, 2024, 11:43pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/19 "2024-02-07T23:43:07Z")

</div>

@dmt. Thank you for those examples. I've added some of them to the Future Directions section of the proposal.

---

<div class="post-metadata">

**Author:** ![tbkka](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tbkka/32/7532_2.png) [@tbkka](https://forums.swift.org/u/tbkka)\
**Post date:** [February 7, 2024, 11:47pm UTC](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865/20 "2024-02-07T23:47:56Z")

</div>

> [@dmt](#):
>
> - As arguments can be positional and/or named the proposed syntax doesn't cover all possible cases, e.g. when two arguments have the same label. I guess there should be an explicit ban when such ambiguity takes place.

@meg-gupta corrected me on this point: The actual behavior being implemented uses the local parameter name, not the external argument label. This avoids the issues you raised here.

I'll update the proposal.

[Next page](https://forums.swift.org/t/pitch-non-escapable-types-and-lifetime-dependency/69865.md?page=2)