[swift-users] Is '_ = x' guaranteed to hold a reference to x?

Mike Ferenduros mike.ferenduros at gmail.com
Fri Jun 30 14:37:33 CDT 2017


Awesome, thanks :)

> On 30 Jun 2017, at 22:27, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Jun 30, 2017, at 12:25 PM, Mike Ferenduros <mike.ferenduros at gmail.com> wrote:
>> 
>> Ah, I think I was unclear - I want to extend the lifetime into an escaping closure, not just within a scope, and I was wondering what the minimal way is to do that.
> 
> I see. Using `withExtendedLifetime` inside the closure still ought to guarantee that the closure captures the variable, and will have the effect of keeping it alive till the closure dies.
> 
> -Joe
> 
>>> On 30 Jun 2017, at 22:15, Joe Groff <jgroff at apple.com> wrote:
>>> 
>>> 
>>>> On Jun 30, 2017, at 12:13 PM, Mike Ferenduros <mike.ferenduros at gmail.com> wrote:
>>>> 
>>>> With an empty body, you mean?
>>> 
>>> I'd say it's probably more readable to nest the code that's dependent on the lifetime of the object in the block body, though you can just put `withExtendedLifetime(x) { }` at the end of the region (or `defer { withExtendedLifetime... }` at the beginning) if you can't have the nesting for whatever reason.
>>> 
>>> -Joe
>>> 
>>>>> On 30 Jun 2017, at 22:00, Joe Groff <jgroff at apple.com> wrote:
>>>>> 
>>>>> 
>>>>>> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users <swift-users at swift.org> wrote:
>>>>>> 
>>>>>> I'm doing a RAII sort of thing with an object, and would like to keep it alive until an completion-block is called (asynchronously).
>>>>>> 
>>>>>> Is it sufficient to say '_ = x' in the completion-block to keep a live reference to the object?
>>>>>> 
>>>>>> I was told that the optimiser is free to discard this line, and thus the object could be freed prematurely depending on how the code is compiled. If so, is there an idiomatic way to do this? Or should I just avoid RAII in Swift?
>>>>> 
>>>>> `withExtendedLifetime(x) { ... }` is the supported way of extending the lifetime of an object.
>>>>> 
>>>>> -Joe
>>> 
> 


More information about the swift-users mailing list