[swift-evolution] Keeping unused values around until containing scope exits?
Kevin Ballard
kevin at sb.org
Wed Dec 30 18:38:28 CST 2015
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.
>
> 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
> 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/d012af7a/attachment.html>
More information about the swift-evolution
mailing list