> On Jun 30, 2017, at 12:25 PM, Mike Ferenduros <mike.ferendu...@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 <jgr...@apple.com> wrote:
>>
>>
>>> On Jun 30, 2017, at 12:13 PM, Mike Ferenduros <mike.ferendu...@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 <jgr...@apple.com> wrote:
>>>>
>>>>
>>>>> On Jun 30, 2017, at 11:47 AM, Mike Ferenduros via swift-users
>>>>> <swift-users@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
>>
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
