Tuple of two or more instances to withExtendedLifetime

There are no restrictions on the type of the first argument to
withExtendedLiftetime, even though it makes sense only for reference types.

So both the below variants will compile, and my question is if the first
one will work as expected (extending the lifetime of both a and b) or if
the second variant must be used instead.

1:
withExtendedLifetime((a, b)) {
    ...
}

2:
withExtendedLifetime(a) {
    withExtendedLifetime(b) {
        ...
    }
}

/Jens

Good question and good thought! I believe the answer is yes, this will work as intended, but I'd like to get someone more versed in SIL than me to verify that. Andy?

Jordan

···

On Dec 13, 2017, at 01:28, Jens Persson via swift-users <swift-users@swift.org> wrote:

There are no restrictions on the type of the first argument to withExtendedLiftetime, even though it makes sense only for reference types.

So both the below variants will compile, and my question is if the first one will work as expected (extending the lifetime of both a and b) or if the second variant must be used instead.

1:
withExtendedLifetime((a, b)) {
    ...
}

2:
withExtendedLifetime(a) {
    withExtendedLifetime(b) {
        ...
    }
}

/Jens

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Yes, withExtendedLifetime is a generic API that guarantees the lifetime of any non-trivial value. i.e. if the tuple contains a reference, the lifetime of that reference will be extended.

That said, there is a theoretical bug in the optimizer that you will be much more likely to hit in practice if you pass a tuple to this API. I still think it’s extremely unlikely that the code will be miscompiled though, and I’m sure it will be fixed shortly ;)

[SR-6608] DeadCodeElimination removes fix_lifetime instructions. - Swift DeadCodeElimination removes fix_lifetime

-Andy

···

On Dec 13, 2017, at 10:05 AM, Jordan Rose <jordan_rose@apple.com> wrote:

Good question and good thought! I believe the answer is yes, this will work as intended, but I'd like to get someone more versed in SIL than me to verify that. Andy?

Jordan

On Dec 13, 2017, at 01:28, Jens Persson via swift-users <swift-users@swift.org> wrote:

There are no restrictions on the type of the first argument to withExtendedLiftetime, even though it makes sense only for reference types.

So both the below variants will compile, and my question is if the first one will work as expected (extending the lifetime of both a and b) or if the second variant must be used instead.

1:
withExtendedLifetime((a, b)) {
   ...
}

2:
withExtendedLifetime(a) {
   withExtendedLifetime(b) {
       ...
   }
}

/Jens

_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Ok, thanks!

···

On Wed, Dec 13, 2017 at 10:20 PM, Andrew Trick <atrick@apple.com> wrote:

Yes, withExtendedLifetime is a generic API that guarantees the lifetime of
any non-trivial value. i.e. if the tuple contains a reference, the lifetime
of that reference will be extended.

That said, there is a theoretical bug in the optimizer that you will be
much more likely to hit in practice if you pass a tuple to this API. I
still think it’s extremely unlikely that the code will be miscompiled
though, and I’m sure it will be fixed shortly :wink:

https://bugs.swift.org/browse/SR-6608: DeadCodeElimination removes
fix_lifetime

-Andy

> On Dec 13, 2017, at 10:05 AM, Jordan Rose <jordan_rose@apple.com> wrote:
>
> Good question and good thought! I believe the answer is yes, this will
work as intended, but I'd like to get someone more versed in SIL than me to
verify that. Andy?
>
> Jordan
>
>
>> On Dec 13, 2017, at 01:28, Jens Persson via swift-users < > swift-users@swift.org> wrote:
>>
>> There are no restrictions on the type of the first argument to
withExtendedLiftetime, even though it makes sense only for reference types.
>>
>> So both the below variants will compile, and my question is if the
first one will work as expected (extending the lifetime of both a and b) or
if the second variant must be used instead.
>>
>> 1:
>> withExtendedLifetime((a, b)) {
>> ...
>> }
>>
>> 2:
>> withExtendedLifetime(a) {
>> withExtendedLifetime(b) {
>> ...
>> }
>> }
>>
>> /Jens
>>
>> _______________________________________________
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>