[swift-evolution] [Proposal] Add an API to Unmanaged to get the instance it holds "@guaranteed"

[Andrew Trick]

> On Mar 14, 2016, at 1:29 PM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> We have the withFixedLifetime API in the standard library today.
>> 
>> withFixedLifetime(ownningReference) {
>> }
>> 
>> Users can rely on that a stored reference in a class is not ultimately released during a method call on that class instance if they can guaranteed that nobody stores to that reference.
>> 
>> The compiler honor withFixedLifetime today (if not that is a bug).
>> 
>> Your point is that this needs to be made clear.
> 
> Yeah, I think withFixedLifetime is probably not a good enough tool; at the very least, you need to reason about indirect references.  (e.g. if the object is held by an array element or a class property, then the array/instance itself needs to be held precisely, etc.)  It’s probably better for local values than a precise-lifetime attribute on local variables, though, assuming withFixedLifetime works for value types, and assuming it doesn’t actually cause reference-counting traffic itself.


The compiler should not be allowed to extend any object lifetimes past a fixed-lifetime marker.

I think it is necessary for the user of the proposed unsafe API to provide a fixed lifetime scope on an owning object, which may have levels of indirection. It’s also necessary for the user to avoid mutating any references that participate in that ownership chain within the fixed lifetime scope.

I don’t think this is an API that we want to promote. In the long run, I imagine a safe/automatic approach (a stored property can be obtained @guaranteed if it’s parent is transitively @guaranteed and is immutable). But that requires some language support and meanwhile we need a backdoor for bypassing ARC in special circumstances.

Andy


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160314/9b08735f/attachment.html>