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

Kevin Wooten kdubb at me.com
Wed Dec 30 20:31:19 CST 2015


> On Dec 30, 2015, at 5:38 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I strongly recommend either making the context get explicitly used in the subsequent animations (e.g. `context.animation(...)` instead of just `animation(...)`) or giving it an explicit scope (e.g. `withAnimationContext(speed: 1.0, bounciness: 1.0) { ... }`). Having the presence of a stack value influence behavior is a great way to cause maintenance issues later on.
>  
> -Kevin Ballard
>  
> On Wed, Dec 30, 2015, at 10:10 AM, Ollie Wagner via swift-evolution 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.

Not sure how contrived your code example is but in the given example wouldn’t just chaining off of AnimationContext solve rightward drift?

AnimationContext(speed: 1, bounciness: 1) {
  ...
}.changeSpeed(to: 2) {
  ...
}


>>  
>> 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!
>>  
>> - Ollie
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>  
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151230/780cca48/attachment-0001.html>


More information about the swift-evolution mailing list