SE-0446: Nonescapable Types

I'm sorry if this was discussed before but why are we making "escapability" a property of a type rather than a property of a binding (with the @nonescaping attribute or some other type qualifier)?
The escapability property makes sense when we pass a value into a function, so the caller can reason about the lifetime of the passed value and this reasoning doesn't depend on the type itself.
Once we have explicit lifetime dependencies, couldn't we model the Span type as the existing UnsafeBufferPointer<T> type with an additional qualifier restricting its lifetime (aka dependsOn(xxx))?
By specifying the escapability next to the function argument, we can use it for any ref-types, allowing the optimizer to allocate such objects on the stack in cross-module calls(without @inlinable). We could also use the familiar withoutActuallyEscaping to pass such values into functions that don't support non-escaping arguments yet but don't escape them actually. And also this will allow us to generalize the @escaping attribute over all types, solving some issues with macros.

I'm not against ~Escapable, I'm just wondering if the generalized @nonescaping attribute would be better.

3 Likes