[swift-evolution] Keeping unused values around until containing scope exits?

[Joe Groff]

> On Dec 30, 2015, at 10:10 AM, Ollie Wagner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I'm using the lifetime of a variable to push and pop a context in an animation system that I'm writing. I'm interested in using a pattern like:
> 
> func doAnimations() {
>     AnimationContext(speed: 1.0, bounciness: 1.0)
>     // do some animations using these options
> }
> 
> But today, the value returned by AnimationContext(speed:bounciness:) gets deinitted immediately.
> 
> I've come to desire using such a pattern after living with this for a while:
> 
> AnimationContext(speed: 1.0, bounciness: 1.0) {
>     // do some animations using these options	
> }
> 
> But I don't like it because it contributes heavily to rightward drift (a user of this API might want to change the options multiple times), and gets hard to parse when nested in the many other language constructs that create a scope using brackets.

There's a standard function withExtendedLifetime which you can use for this already:

withExtendedLifetime(AnimationContext(...)) {
   // AnimationContext is guaranteed to be alive in this block
}

though that doesn't solve the rightward drift problem. You can alternately defer { } an artificial use of the object:

@inline(never) func use(x: Any) { }

let x = AnimationContext(...); defer { use(x) }

As discussed in the "scoped resources" thread, we might also benefit from something like ObjC ARC's scoped lifetime attribute.

> So — would it be reasonable to suggest that we have some keyword(s) preceeding an initializer that allows a value to stay alive and/or not warn if it winds up going unused? The current behavior in Swift has obviously been considered, so please feel free to tell me if this is a Very Bad Idea. I'm still learning!

The vast majority of objects only own resources that are only necessary for that object's own operation, and most of Swift's target platforms are resource-constrained, so it's a valuable optimization to be able to deallocate objects ASAP. We think it's a reasonable tradeoff for objects which do require fixed scopes to require a bit of additional annotation.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151230/24d09a36/attachment.html>