Hi everyone. As recently announced, we would like to support the use of lifetime dependencies as an experimental feature. Since our initial pitch for this feature, we have reviewed several proposals that implement parts of the overall functionality:
We have revised the proposal based on this experience:
This revised proposal should serve both to document the state of the experimental feature for early adopters, and as a place to continue discussion about its use and design.
The @lifetime attribute is available as described in the main branch of the compiler, using the LifetimeDependence experimental feature flag, with the following exceptions:
@lifetime(inout t) is not yet supported for declaring scoped dependencies on mutable parameters.
Neither dependencies on BitwiseCopyable values nor the _overrideLifetime standard library function are yet required to be annotated as unsafe under strict memory safety mode as proposed.
However, we plan to make these changes imminently, so the proposal describes the functionality this way. I will update this post to reflect the state of the implementation vs. proposal as it evolves.
In order for Swift Testing to support move-only and non-escaping types in various places (including as arguments to #expect()), we need the ability to consume a value in a function, then immediately return it. Something like:
#expect(moveOnly.isFoo)
// expands to:
__check(__look(at: moveOnly).isFoo, otherArgs: ...)
Where __look(at:) is defined as something like:
@lifetime(borrow value)
public func __look<T>(at value: borrowing T) -> T where T: ~Copyable, ~Escapable {
// some poking and prodding happens here
return value
}
Is that sort of pass-through functionality possible with this proposal (and did I spell it right), or would the compiler be unable to reason about this sort of pattern?
As someone less experienced with the kind of programming being defined here, I found the use of the term "copy" when discussing lifetime dependencies to be pretty confusing. I initially thought it meant that it essentially erased the dependency, but I think it just means that, if b is dependent on a, and c copies the lifetime dependency of b, then c is dependent on a; is that correct? If so, I'm not sure "copy" is the best term to use here, as it's easy to confuse it as having some relation to the Copyable protocol, but it doesn't seem like it actually does.
Thanks, I think this is a really important step for very performance-sensitive Swift code. I have some feedback; starting with the minor things:
Bikeshed alert: the lifetime type identifier is somewhat inconsistent with whether it uses the keyword that goes with the type in a parameter declaration or whether it uses the keyword that goes with the binding at the call site. For instance, it's @lifetime(borrow x) func ..., which matches the call syntax foo(borrow x), but it's @lifetime(inout x) func ..., which matches the declaration syntax func foo(_ x: inout X). Should it be borrowing/consuming/copying/etc?
I imagine the answer is "no" since Error is Copyable, but do we think it could eventually be necessary to find a syntax to put lifetime constraints on errors thrown?
How does this syntax interact with generic parameter packs? How would I express that a returned value's lifetime depends on all the values passed in a pack?
The pitch doesn't have any example of returning a value whose lifetime depends on two parameters. Is it because it's not supported?
What happens if I try to specify that an argument depends on itself on output, like @lifetime(x: inout x)?
What interplay is there, if any, with @escapable closures? Are there plans to fold @escapable into this model?
With this out of the way, I have some bigger questions on the model itself, @lifetime(immortal), and how it works with value types.
To start, the proposal calls out that self.value = Object() would not correct with @lifetime(immortal). How would you violate that lifetime? How is it different from the unsafeLifetime example for the init that uses getGlobalConstant()?
The āDepending on an escapable BitwiseCopyable valueā section implies that a lifetime depending on any BitwiseCopyable value, like an Int value, would have to be @unsafe. What memory safety concern do we have here? For unsafe pointers, the answer is obvious, but such a function would already be implicitly @unsafe since it has an unsafe type in its signature.
Relatedly, I donāt fully understand why @unsafe @lifetime(immortal) init(pointer: UnsafePointer<T>) is incorrect; or rather, I donāt understand what a safe lifetime would be. Depending on a pointer doesnāt guarantee that the memory is live (vs. freed), or that the memory it points to is initialized. At the same time, if we decided that āsuppressingā lifetimes using @lifetime(immortal) for things that have to depend on pointers was OK, it falls out that since lifetimes combine additively, you can implement Span.dropFirst without using unsafeLifetime:
I made some revisions to try to answer a few of your points:
Depends on if we ever think Error would be generalized to allow for nonescapable errors in the future.
I added an explicit example for this: if you specify multiple constraints on the same target, then the target is dependent on both.
I also added some text to work through this. This would specify that the value of x after the function returns has a scoped dependency on exclusive access the variable x, which would in effect make x inaccessible. Thus it should probably just be disallowed. (@lifetime(x: copy x) could also be possible, but would have no effect, meaning that the value of x after the function runs copies its lifetime from the value of x before, leading to no net change.)
I made some notes about functions and lifetimes in future directions, but this proposal by itself does not try to change the status quo.
I'll try to answer your questions about @lifetime(immortal) and BitwiseCopyable types later on, if nobody beats me to it.
_overrideLifetime "drops" all dependencies on it first argument (self) and creates a new value with a dependence on its second argument. Depending on Void here is equivalent to having no dependence.
Presumably, a non-Escapable value depends on some externally managed resource, and whatever value it depends on represents that resource. Accessing that dependent value after the resource has been freed might be memory unsafe. If the source of the dependence has its own lifetime, then the compiler can enforce the dependence of one lifetime on another. If the source of the dependence is BitwiseCopyable, then the scope is user-defined (by definition, BitwiseCopyable values aren't destroyed at a well-defined point). The compiler diagnostics assume that the BitwiseCopyable value is valid until the end of its lexical scope, but that's a guarantee the programmer needs to uphold, and therefore the creation of the dependence must be marked unsafe:
The compiler doesn't see any problem with this code.
struct Handle { var i: Int; ... }
let handle = Handle(...)
let span = unsafe handle.span
handle.release()
return span[index]
This example seems silly, because Handle should obviously be non-Copyable, but it's hard to come up with a dependence on a BitwiseCopyable value that isn't silly.
APIs that expose pointers guarantee safety within a local scope. Creating an immortal value from a pointer instantly violates that contract and completely defeats the purpose of non-Escapable types.
Dependening on a pointer does provide safety guarantees as long as the conditions for memory safety are met at the point where you create that dependence. That's the point at which the programmer needs to write unsafe. All subsequent uses of the dependent value are statically enforced. This reduces the problem of memory safety to a single point, which is a very big deal.
Thank you for clarifying. It sounds like the proposal wording should be adjusted, because currently, this is how the example is introduced:
We could run into the same problem with any transient value, like a file descriptor, or even a class object:
Also: it falls naturally from the current model that a parameterless initializer for a ~Escapable type must produce an immortal value, because it is syntactically impossible to impose any other constraint. (I imagine that we could also choose to require @lifetime(immortal) to be explicit. This would mildly interfere with the free memberwise initializer that it would "normally" get, so unless we spell out a benefit to this an exception, my opinion is that we should let it slide.)
In any case, if there's a diagnostic to have, I think it wouldn't end up at the self.value = Object() assignment.
For what it's worth, I don't really have a problem with it either. Are you able to complete the example without using more unsafe code? I'm not coming up with anything. The fact it's so hard to contrive an example where this BitwiseCopyable exception provides benefits over the @unsafe rule should be signal that it might not be needed at all.
I wanted to separately address the pointer talk because we seem to have divergent views. I don't understand the unsafe pointer pattern that you are proposing to bless. My understanding is that you're saying this needs to work:
array.withUnsafeBufferPointer {
let span = unsafe Span($0) // pointer is scoped, this is actually safe!
// do stuff
}
But it's already accepted that you create a Span out of an array with the span property. I don't think that it can be implemented using withUnsafeBufferPointer since the property has to return a Span, and that would escape the pointer from its scope.
At the same time, another important use of ~Escapable types is to safely wrap C pointers. C pointers are also almost never vended from a scoping API, so they don't benefit either.
If the pointer pattern isn't especially for the standard library, and it's not especially for people using C APIs, who is it for? People using withUnsafePointer(to: myLocal)? Won't that use case be served better by borrowing/mutating fields?
The crux of this issue is whether dependence on Void creates an immortal value. In the past, I've said these two things have distinct semantics. That way, we never accidentally create immortal non-escapable values, which is likely an error. It also gives us a way to return values without a dependence but still prevent that value from escaping the local scope surrounding the call site.
On the other hand, more recently we decided that a dependency on a generic argument should lower to @lifetime(immortal) when we substitute Void as the argument. Also, as mentioned in the proposal, it's convenient to create an immortal value with _overrideLifetime(dependent: self, dependsOn: ())
I think it will be difficult to formalize and explain the semantic difference between these concepts, so we should probably erase the difference. I think that eliminates the source of confusion here.
The only accidental immortal type that people will create will be the empty ~Escapable type:
I'm really impressed with the clear and concise syntax for this functionality. The examples like @lifetime(borrow self), @lifetime(inout to), and @lifetime(copy self) are all a really nice mix of being clear and concise, without new specific jargon. Great work!
One questions that I don't see mentioned in the text (may have missed it) -- for parameters with both an internal and external label, like to destination: ContiguousArray<Element>, would you use the internal or external label, or are both permitted (e.g. @lifetime(borrow to) vs @lifetime(borrow destination)). I like the sound of supporting / preferring the internal labels. To me "borrow destination" sounds more fluent than "borrow to".
I don't want to promote APIs that depend on BitwiseCopyable values, but that capability was immediately demanded by folks working with the prototype. We need to decide what it means in principle and how it works in practice.
In principle, when you depend on a BitwiseCopyable value, you create a local borrow of that value. If the borrowed value is a variable, then that borrow scope can extend to the end of the variable's declaration scope.
In practice, the programmer needs to decide what scope that BitwiseCopyable value actually has and be able to explicitly communicate that. "Defaulting" to the local borrow scope is correct both in principle and practice. If the span is valid outside that local scope, then it must depend on some other managed value, and that needs to be explicitly declared using _overrideLifetime.
withUnafePointer-style APIs do need to work with other language features, and they should be safe within clear and obvious rules. Once you create a Span from that unsafe pointer, the expectation is that it can be used safely. Treating a Span as immortal when it actually depends on any non-immortal value is incorrect in principle and maximally unsafe in practice.
Marking BitwiseCopyable dependence as an unsafe operation accomplishes two things:
signals that the compiler cannot enforce the lifetime dependence and that the programmer needs to separately reason about the scope in which their BitwiseCopyable thing is valid
signal this style of API is not encouraged for safely working with non-Escapable types and should instead be limited to a data structure's implementation details.
@lifetime always names the (internal) parameter name, not the (external) argument label. It reads better and means that the annotation is not tied to the external function name.
I missed a lot of discussions on the topic, and I'm trying to catch up now. But I don't quite understand from the proposals what the status of non-escaping closures is. SE-0446 has a brief note about them:
We add a new suppressible protocol Escapable to the standard library and implicitly apply it to all current Swift types (with the sole exception of nonescapable closures).
But in practice, I see the following:
func allowNonEscapable(_ x: some ~Escapable) {}
func onlyEscapable(_ x: some Escapable) {}
func test(_ x: () -> Void) {
x is Escapable // 'is' test is always true
allowNonEscapable(x) // Converting non-escaping parameter 'x' to generic parameter 'some ~Escapable' may allow it to escape
onlyEscapable(x) // Converting non-escaping parameter 'x' to generic parameter 'some Escapable' may allow it to escape
}
The same thing seems to happen with lifetime dependencies:
@lifetime(copy x) // Invalid lifetime dependence on a source of Escapable type, use borrow dependence instead
func identity(_ x: () -> Void) -> () -> Void {
x
}
So how do non-escaping closures and ~Escaping interact?
In my view, the main use for depending on a copyable type is that speculatively, one day, we could have borrowing/mutating as a "storage classes" for fields in ~Escapable types. For instance, you could imagine that HasARef's init and deinit don't touch ref's reference count because the caller guarantees it will hold a reference that outlives it:
My experience is that it's currently impossible to get a struct to safely hold a reference without causing refcount traffic, which has been a performance bottleneck before.
Or you could have a mutating field:
struct HasAnInout: ~Escapable {
mutating ref: SomeStruct
init(ref: inout SomeStruct) {
&self.ref = ref /* strawman syntax to distinguish binding from assignment */
}
mutating func bump() {
ref.counter += 1 /* modifies the &ref passed to the initializer */
}
}
It makes sense to me that you could want to depend on copyable values to implement these use cases, and this is meaningful for BitwiseCopyable values and non-trivially copyable values equally. (More related to the previous point, none of these uses should be unsafe.)
I think it's fine to accommodate people who want to depend on UnsafePointer bindings to the extent that it wouldn't interfere with a vision for the above (which is useful for UnsafePointer too!). But fundamentally, people depending on pointer cannot expect that it guarantees pointer.pointee stays valid the entire time. It's a useful tool to verify you didn't make one class of clear mistakes, but I don't think that it should be the guiding star for what depending on a BitwiseCopyable value means.
Oh, absolutely. Thank you for pointing that out. Your example is safe. The implementation of lifetime dependence tracks and enforces the lifetime of every non-Escapable type. That's why the proposal explicitly discusses the semantics of "escapable BitwiseCopyable" as requiring an extension to the existing lifetime model (the extension is simply the ability to locally borrow a BitwiseCopyable value). I mistakenly dropped the "escapable" qualifier in the previous reply.
I don't think the model for BitwiseCopyable & Escapable dependence is specific to pointers. Anytime we talk about pointer safety we can apply that to a program that uses an integer to index into a table of pointers or any other resource that is explicitly managed. What's important is that we don't confuse this case with immortal dependence. Depending on an actual immortal value is an important safe feature that the compiler can fully diagnose. We shouldn't hide unsafe features behind it.
Those are good examples of what probably should be supported but are not currently.
nonescaping functions types are still separate from ~Escapable in the type system. They should probably be considered as suppressing Escapable--that would make sense and would be extremely useful--but we haven't handled that yet.
So, the only interaction between them is that you can capture a non-Escapable value in a nonescaping closure, but you cannot capture a non-Escapable value in a @escaping closure.
I still don't understand where the memory safety implication fits in this. From what I understand, you say that if a ~Escapable type has a dependency on Int, we are almost certain that it means to take a dependency on something else, and we will require the use unsafe as a diagnostic suppression mechanism. Is that correct?
I added some text to the proposal to clarify that we aren't changing anything about function types right away. This generalization isn't quite as straightforward as we like, since nonescaping functions' closure contexts are currently always lifetime-dependent on their caller's stack frame. It would be useful to be able to specify more interesting lifetime constraints, though doing so would require a representation more like an escaping closure for cases where the lifetime constraint is more general than the immediate stack frame.
Nonescaping closures also have an ability that is not yet captured by this lifetime proposal: it is possible for multiple nonescaping closure values to exist that capture exclusive access to the same inout parameters or mutable variables, so long as it isn't possible for both closures to be executing at the same time (by passing one as a parameter to the other).