-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-Escapable Types #2304
base: main
Are you sure you want to change the base?
Non-Escapable Types #2304
Conversation
Briefly, non-escapable types are types that cannot "escape" the local execution context. These types can also participate in extended lifetime dependency constraints. This enables compile-time lifetime enforcement for values that contain pointers into other values. This makes it possible to implement containers that require no runtime lifetime management of their iterators or slice objects. In particular, this is a foundational technology for BufferView.
// Example: Local variable with non-escapable type | ||
func borrowingFunc(_: borrowing NotEscapable) { ... } | ||
func consumingFunc(_: consuming NotEscapable) { ... } | ||
func inoutFunc(_: inout NotEscapable) { ... } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be good to add a case for async functions and async let here, it's barely mentioned in the proposal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll see what I can do about including async examples.
Until then, note that the comments about functions apply to all functions, regardless of whether they are async or not, throwing or not.
Similarly, async let
guarantees that the called function will return before the current function completes, so it's safe to pass a ~Escapable
value to a function called with async let
.
This is the first of two proposals covering this new feature:
It propose an
Escapable
type marker to indicate that a value of this type can escape the local scope -- by being stored in a global or returned, for example.This new marker would be implicitly satisfied by all current Swift types to avoid breaking existing code and to reflect the expectation that most types can in fact be freely copied and assigned without limit.
We then add a new
~Escapable
type requirement that can be used to selectively remove this capability.We explain the motivation for such types and the basic capabilities and restrictions on their use.
The companion proposal "Lifetime Dependency Constraints for ~Escapable Values" proposes a set of annotations that selectively modify the constraints of
~Escapable
types so they can be used to provide accurate compile-time tracking of values that are inherently subsidiary to some other value (for example, iterators over collections or slices that must not outlive the container to which they refer).These are part of the BufferView roadmap and are prerequisites for that type.