# Compiler issue: Escaping closure captures non-escaping parameter 'block'

**URL:** <https://forums.swift.org/t/compiler-issue-escaping-closure-captures-non-escaping-parameter-block/83578>\
**Category:** Using Swift\
**Tags:** closure, escapingclosure\
**Created:** [December 5, 2025, 11:33am UTC](https://forums.swift.org/t/compiler-issue-escaping-closure-captures-non-escaping-parameter-block/83578 "2025-12-05T11:33:48Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![jamieQ](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/jamieq/32/5117_2.png) [@jamieQ](https://forums.swift.org/u/jamieQ)\
**Post date:** [December 5, 2025, 2:32pm UTC](https://forums.swift.org/t/compiler-issue-escaping-closure-captures-non-escaping-parameter-block/83578/5 "2025-12-05T14:32:34Z")

</div>

> [@blazej.sleboda](#):
>
> The result is that it crashes immediately, at the moment the closure is passed as an argument.

IIRC from looking into this in the [past](https://forums.swift.org/t/question-about-using-withoutactuallyescaping-and-withcheckedcontinuation-together/81974/2), i think there is a runtime check/assert of the refcount of the closure argument at exit of the `withoutActuallyEscaping` function, so i would guess that's the point at which you'd generally expect to see a runtime error (though with optimizations on, idk maybe it moves around or isn't 100% reliable).

> [@blazej.sleboda](#):
>
> why do we need withoutActuallyEscaping?

as i understand it, it's just a tradeoff. in your initial example, the compiler's analysis is conservative and it won't let you express in-actuality-safe code. rather than that just being the end of the story, Swift gives you an out, but it's a 'Spider Man' sort of deal – you take on the responsibility of ensuring things don't escape (well, the runtime tries to 'help' you too, by crashing if you've failed to uphold your end of the bargain).

i would expect as the ownership model and stuff like `~Escapable` types becomes more fully built-out, we will get more precise control over this sort of thing. e.g. if you could just declare that your local variable is `~Escapable` in some manner, then i think your initial example would work as desired without need for 'opting out' of the static safety checks. mabye this is possible today and i'm just unaware of the syntax you'd need to do it? sounds like an somewhat entertaining exercise for the reader 🙂

---

_[View the full topic](https://forums.swift.org/t/compiler-issue-escaping-closure-captures-non-escaping-parameter-block/83578)._