Const all the floating point arithmetic

[davidgraymi]

What problem does this solve or what need does it fill?

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.

Describe the solution you'd like

We should constify our APIs, one library at a time. This should be kept to relatively simple functions and methods: only things that we can commit to being const indefinitely.

Describe alternatives you've considered

Use a quick sweep of cargo clippy --fix --allow-dirty -- -W clippy::missing_const_for_fn to set all functions that allow it to const.

Additional context

I come from bevy and want to support bevyengine/bevy#16124.

[bitshifter]

I'm happy to make more things const where possible. I think the amount of floating point arithmetic that can be made const in glam is fairly limited because:

• a lot of the arithmetic is implemented inside std::ops traits, which are not yet const
• a lot of arithmetic in glam can used SIMD intrinsics which usually are not const - it's important that any function has the same signature no matter if the implementation uses SIMD or regular floating point arithmetic behind the scenes
• Many functions that aren't using SIMD directly still can't be made const because Deref is being used to access member data, which is not const on stable Rust

As long as those two constraints are not violated it's OK to make things const.

[davidgraymi]

How can that be tested? I started making changes on a fork and then realized glam is mostly autogenerated. Is there a trick to generating and testing? Or is the test mostly compiling?

[bitshifter]

To test you'd have to re-generate the code and see if it compiles. You can run cargo run -p ci to run common tests. That will only compile for your local machine but should exercise a scalar and SIMD path at least, depending on your hardware. I think there's very little, if any, float code that could be made const right now though. One other blocker for const is a lot of code that looks like it is normal arithmetic is actually using Deref to access .x, .y etc on SIMD types. Deref like other traits is also not const in stable Rust. If const traits do get stabilised at some point that should open up the possibility to use const in more places.

[bitshifter]

While I'm not sure that there's any more methods that could be made const for now, I'll leave this open as if const core::ops traits or const simd functions are stabilised there should be more in glam that can be made const.