ickshonpe
commented
2 days ago Does it matter that much that the functions should be const indefinitely? All the Val helper functions are begging to be made const but we really want to be able to implement some sort of Val::Calc support in support in the future. But Val::Calc can't be implemented in Bevy without support being implemented in Taffy first, so I can't see it being introduced until Bevy 18 at the earliest.
Otherwise all the ComputedNode methods use resolved values after layout and that shouldn't ever be changed, so they can be safely made const. Same should be true of the functions that use resolved values for text and texture slice layouts.
alice-i-cecile
What problem does this solve or what need does it fill?
As seen in #16091, floating point arithmetic can now be used in constant functions! This is a valuable API improvement, as it allows users to define their own derived constants using our handy math operations.
What solution would you like?
We should constify our APIs, one crate at a time. The critical ones are:
This should be kept to relatively simple functions and methods: only things that we can commit to being const indefinitely.
What alternative(s) have you considered?
Do let me know if I've missed a crate that needs this treatment!
Additional context
glamis open to making much of their API const which will unblock a ton of improvements in Bevy itself, although it's harder than one might expect there, due to SIMD support.