# SE-0465: Standard Library Primitives for Nonescapable Types

**URL:** <https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310>\
**Category:** Proposal Reviews\
**Created:** [March 5, 2025, 7:34pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310 "2025-03-05T19:34:40Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 5, 2025, 7:34pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/1 "2025-03-05T19:34:40Z")

</div>

Hi everyone,

The review of [SE-0465 "Standard Library Primitives for Nonescapable Types"](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0465-nonescapable-stdlib-primitives.md) begins now and runs through **March 18, 2025**.

[_Coming soon_: toolchains with these changes]

Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager via the forum messaging feature. When contacting the review manager directly, please keep the proposal link at the top of the message.

#### What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

- What is your evaluation of the proposal?
- Is the problem being addressed significant enough to warrant a change to Swift?
- Does this proposal fit well with the feel and direction of Swift?
- If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
- How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at [https://github.com/swiftlang/swift-evolution/blob/main/process.md](https://github.com/swiftlang/swift-evolution/blob/main/process.md).

Thanks for contributing to Swift!

Doug Gregor  
Review Manager

---

<div class="post-metadata">

**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\
**Post date:** [March 5, 2025, 9:24pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/2 "2025-03-05T21:24:22Z")

</div>

+1. Swift Testing would very much like to see these changes.

Have you considered `ManagedBuffer` supporting move-only values? I realize this proposal is primarily focused on `~Escapable`, but since it does cover changes that affect move-only types, that seems to be in scope.

---

<div class="post-metadata">

**Author:** ![lorentey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lorentey/32/1299_2.png) [@lorentey](https://forums.swift.org/u/lorentey)\
**Post date:** [March 5, 2025, 10:03pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/3 "2025-03-05T22:03:28Z")

</div>

> Have you considered `ManagedBuffer` supporting move-only values?

Yes. [SE-0437](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0437-noncopyable-stdlib-primitives.md#managed-buffers) has already added support for noncopyable elements to `ManagedBuffer`. The proposal has left a copyability requirement on `Header` to avoid bincompat trouble; please let me know if that's blocking you.

(As for nonescapable elements: that too would be very much desirable, but unfortunately we generally aren't ready to propose containers of nonescapable types yet. The expectation is that the lifetime dependencies of the elements contained therein would be tracked separately from the container itself. Sadly, we have no way to express that at this time.)

---

<div class="post-metadata">

**Author:** ![grynspan](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/grynspan/32/15315_2.png) [@grynspan](https://forums.swift.org/u/grynspan)\
**Post date:** [March 5, 2025, 10:30pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/4 "2025-03-05T22:30:12Z")

</div>

Oh, that's probably the trouble I was running into, then. I'll message you privately. 🙂 Sorry to distract from the PR—I look forward to it landing!

---

<div class="post-metadata">

**Author:** ![benrimmington](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/benrimmington/32/695_2.png) [@benrimmington](https://forums.swift.org/u/benrimmington)\
**Post date:** [March 10, 2025, 5:01am UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/5 "2025-03-10T05:01:08Z")

</div>

> We postpone generalizing most of the higher-order functions that make `Result` convenient to use, as we currently lack the means to reason about lifetime dependencies for such functions. But we are already able to generalize the two functions that do not have complicated lifetime semantics: `mapError` and `flatMapError`.

The `transform` closure of the `flatMapError` method can return a new `Success` value:

```swift
let f: Result<Int, any Error> = .failure(CancellationError())
let s: Result<Int, any Error> = f.flatMapError { _ in .success(42) }

```

Therefore `flatMapError` might have the same issue as `flatMap` and `map`.

---

<div class="post-metadata">

**Author:** ![lorentey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lorentey/32/1299_2.png) [@lorentey](https://forums.swift.org/u/lorentey)\
**Post date:** [March 10, 2025, 5:56pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/6 "2025-03-10T17:56:13Z")

</div>

Well spotted! `@_lifetime(copying self)` works for the overall result, but the function argument's result value needs to match that, and we have no way to describe that.

I think we'll need to put off the `flatMapError` generalization, too. The lack of a diagnosed error is an additional problem.

---

<div class="post-metadata">

**Author:** ![Douglas\_Gregor](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/douglas_gregor/32/1362_2.png) [@Douglas\_Gregor](https://forums.swift.org/u/Douglas_Gregor)\
**Post date:** [March 18, 2025, 10:01pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/7 "2025-03-18T22:01:29Z")

</div>

Thank you everyone for the discussion. This proposal has been [accepted](https://forums.swift.org/t/accepted-se-0465-standard-library-primitives-for-nonescapable-type/78637) with one modification removing `flatMapError`.

Doug

---

<div class="post-metadata">

**Author:** ![John\_McCall](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/john_mccall/32/1351_2.png) [@John\_McCall](https://forums.swift.org/u/John_McCall)\
**Post date:** [April 11, 2025, 11:01pm UTC](https://forums.swift.org/t/se-0465-standard-library-primitives-for-nonescapable-types/78310/8 "2025-04-11T23:01:02Z")

</div>

Closed on April 11, 2025, 11:01pm UTC


