# Pitch: Single-yield functions

**URL:** <https://forums.swift.org/t/pitch-single-yield-functions/90319>\
**Category:** Pitches\
**Created:** [October 28, 2026, 5:30pm UTC](https://forums.swift.org/t/pitch-single-yield-functions/90319 "2026-10-28T17:30:36Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![allevato](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/allevato/32/385_2.png) [@allevato](https://forums.swift.org/u/allevato)\
**Post date:** [October 28, 2026, 11:20pm UTC](https://forums.swift.org/t/pitch-single-yield-functions/90319/8 "2026-10-28T23:20:57Z")

</div>

> [@jrose](#):
>
> I'd be hesitant to pursue this because it depends on the body—there are several criteria ("yields exactly once", "does not throw after yielding") that aren't visible just from the declaration signature. It would be nice™ and maybe we can make it easier in the future, but the "auto" part is probably not going to fly.

I _did_ call the idea crazy 😁 I don't think it's something that this proposal has to address immediately, but I'd love to see an audit of, say, the standard library and Foundation to see how close we could get with good heuristics.

Regarding called-exactly-once, I would argue that we didn't let that stop us for bridged Obj-C completion handlers; if a closure is called more than once in a yielding overload, we could just trap at runtime, I think? (And then if `@called(exactlyOnce)` or something like it ever happens, we can eliminate that trap door. Or we just wait a bit and see if `@called(exactlyOnce)` gets proposed/added, since its [sibling](https://forums.swift.org/t/pitch-introduce-a-way-to-annotate-functions-that-are-called-at-most-once/89088) is already in pitch and there's been some discussion about it.)

For potentially tricky error-throwing paths, I would wager that the function either being `rethrows` or generic with the same typed `throws(E)` clause would be enough to guarantee that errors could only be thrown before/during the `yield` (unlikely that an implementation would generically get an arbitrary `E` to throw after the fact). And then maybe a runtime trap for the misbehaving ones again.

But all that would depend on whether the audit shows it makes sense. Maybe I'll tilt at this sometime (depending on how this pitch evolves); if we had evidence that the heuristics could be good enough that the default could be opt-_out_ (annotate the functions that would match the heuristic but shouldn't) instead of opt-in, then that would be a pretty powerful feature.

---

_[View the full topic](https://forums.swift.org/t/pitch-single-yield-functions/90319)._