# \[Pitch\] ~SyncConsumable **URL:** \ **Category:** Pitches\ **Tags:** asyncawait\ **Created:** [September 1, 2024, 2:32pm UTC](https://forums.swift.org/t/pitch-syncconsumable/74310 "2024-09-01T14:32:59Z")\ **Posts on this page:** 1\ **Showing post:** 5
**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:** [September 4, 2024, 5:22pm UTC](https://forums.swift.org/t/pitch-syncconsumable/74310/5 "2024-09-04T17:22:19Z")
While capturing `self` in the unstructured task is a soundness problem. Spawning any unstructured work in deinits can open up remote denial of service attacks in applications. During the [second review](https://forums.swift.org/t/second-review-se-0371-isolated-synchronous-deinit/73406) of [SE-0371: Isolated synchronous deinit](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0371-isolated-synchronous-deinit.md) @johannesweiss and I brought up our concerns with how implicit spawning of such unstructured work in deinits is dangerous. The same arguments apply for explicit spawning. In general, I would love to see us explore `~SyncConsumable` as a language feature. `~Copyable` already brings us pretty close except that we cannot model asynchronous clean up. Types such as file descriptors, sockets or other resources that need async cleanup need to resort to using `with-style` methods instead. One area to explore more is if a hypothetical `deinit() async` should really be implicitly awaited or if they need to be explicitly awaited. In similar veins, what about throwing deinits? My experience is that most `async` methods also want to become `throws` at some point. The Rust project has an [async drop initiative](https://rust-lang.github.io/async-fundamentals-initiative/roadmap/async_drop.html) where they went through a similar exploration. --- _[View the full topic](https://forums.swift.org/t/pitch-syncconsumable/74310)._