<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 30, 2015, at 10:10 AM, Ollie Wagner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">func doAnimations() {</font></div><div class=""><font face="Menlo" class=""> AnimationContext(speed: 1.0, bounciness: 1.0)</font></div><div class=""><font face="Menlo" class=""> // do some animations using these options</font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">But today, the value returned by <font face="Menlo" class="">AnimationContext(speed:bounciness:)</font> gets deinitted immediately.</div><div class=""><br class=""></div><div class="">I've come to desire using such a pattern after living with this for a while:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">AnimationContext(speed: 1.0, bounciness: 1.0) {</font></div><div class=""><font face="Menlo" class=""> // do some animations using these options<span class="Apple-tab-span" style="white-space: pre;"> </span></font></div><div class=""><font face="Menlo" class="">}</font></div><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><div><br class=""></div><div><div>There's a standard function withExtendedLifetime which you can use for this already:</div><div><br class=""></div><blockquote style="margin: 0px 0px 0px 40px; border: none; padding: 0px;" class=""><div>withExtendedLifetime(AnimationContext(...)) {</div><div> // AnimationContext is guaranteed to be alive in this block</div><div>}</div></blockquote><div><br class=""></div><div>though that doesn't solve the rightward drift problem. You can alternately defer { } an artificial use of the object:</div><div><br class=""></div><div>@inline(never) func use(x: Any) { }</div><div><br class=""></div><div>let x = AnimationContext(...); defer { use(x) }</div></div><div><br class=""></div><div>As discussed in the "scoped resources" thread, we might also benefit from something like ObjC ARC's scoped lifetime attribute.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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!</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>-Joe</div></body></html>