Is it a bug at <Animatable.kt#173> since `clampedValue` is the actual result but never being used

# compose

[Tlaster]

Is it a bug at Animatable.kt#173 since clampedValue is the actual result but never being used

[Andrey Kulikov]

@Doris Liu

[Doris Liu]

It would seem so. Thanks for bringing it up. Please feel free to file a bug. 🙂

[Tlaster]

Got one🎉 https://issuetracker.google.com/issues/180031493

[Vsevolod Ganin]

Seems like this broke almost all my animations in weird ways. Hope this will be fixed soon 🤞🏻

[Doris Liu]

@Vsevolod Ganin could you share more on how they behave now? Do you use bounds in almost all your animations? I wouldn't expect this to have any impact on unbounded animations.

[Vsevolod Ganin]

Yes I use them pretty frequently, they are very convenient. For example, in my implementation of NumberPicker I use bounds to restrict user to go beyond supplied range of numbers. Another example is canvas which user zooms and pans. Again I restrict user to go beyound bounds of the canvas on values that comprise “a camera”. Also I use updateBounds in my swipe-to-delete implementation and a couple of other draggable composables

[Vsevolod Ganin]

So what I see now is that bounds are not respected if use snapTo which is main instrument to implement drags. I think it still works with animateTo and animateDecay which I use to implement flings

[Doris Liu]

Could you add that to the issue linked above? I considered having snapTo supercede bounds as it's a deliberate function call. One can always check bounds before calling snapTo. But perhaps that doesn't map well with the mental model of bounds. 🙂