# \[Pitch\] Task Priority Escalation APIs

**URL:** <https://forums.swift.org/t/pitch-task-priority-escalation-apis/77702>\
**Category:** Pitches\
**Tags:** concurrency\
**Created:** [February 6, 2025, 11:26pm UTC](https://forums.swift.org/t/pitch-task-priority-escalation-apis/77702 "2025-02-06T23:26:14Z")\
**Posts on this page:** 1\
**Showing post:** 23

<div class="post-metadata">

**Author:** ![SlugFiller](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/slugfiller/32/33973_2.png) [@SlugFiller](https://forums.swift.org/u/SlugFiller)\
**Post date:** [February 20, 2025, 6:09pm UTC](https://forums.swift.org/t/pitch-task-priority-escalation-apis/77702/23 "2025-02-20T18:09:55Z")

</div>

Am I the only one who feels this is just a huge XY problem?

The example issue is `merge` from `swift-async-algorithms` in which you can't create a structured task which has a lifetime which matches the `merge` operation.

Using current tools, this could be solved by having `merge` receive a `TaskGroup` parameter, which would determine the lifetime of the contained tasks (and hence, the `merge`d stream). If you read a bit about structured tasks/nurseries, you'd realize that's how it's _supposed_ to be used. However, this originates from garbage-collected languages, in which lifetimes must be made explicit.

A correct solution to the problem would be structured tasks of which lifetime is associated with a parent structure/class, relying on ARC. This would require [asynchronous deinitializers](https://forums.swift.org/t/pitch-syncconsumable/74310).

In other words, this entire pitch is basically trying to get structured concurrency without using structured concurrency. In use cases where it's entirely appropriate to use structured concurrency. Instead of trying to figure out how to make structured concurrency work.

---

_[View the full topic](https://forums.swift.org/t/pitch-task-priority-escalation-apis/77702)._